Order First Payments: 6 Ecommerce Integration Checks for Merchants

For most online stores, hosted checkout or embedded hosted fields is the right starting point for ecommerce payment integration, since both cut your PCI compliance burden while keeping checkout on your domain. Direct API integration makes sense only when you need full control over the payment flow and have the engineering resources to carry the heavier compliance load that comes with it. Weigh three things before you choose: how much PCI scope you can absorb, how much developer time you have, and how much the checkout experience matters to your conversion rate.

TL;DR:

Hosted checkout remains the fastest and easiest option for small stores to launch, with minimal PCI scope and setup time.

Embedded hosted fields offer more branding control while still limiting PCI exposure, suited for growing merchants with development resources.

Direct API integration provides maximum control and customization but entails the highest PCI scope and development effort, ideal for enterprise teams.

Payment processing costs are more influenced by reconciliation, dispute handling, and downtime than by transaction rates alone.

Building a reliable integration requires sequencing order creation before payment sessions, handling webhooks securely, and thorough testing across failure scenarios.

How Does Ecommerce Payment Integration Actually Work?
Which Integration Type Fits Your Store?
What Do Payment Fees Actually Cost You?
How Does PCI DSS Apply to Your Integration Choice?
What Should a Production Integration Checklist Include?
How Do You Choose a Payment Integration Partner?
How Paysec Supports Your Payment Integration
Do You Need Code Examples to Get Started?
How Long Does a Payment Integration Actually Take?
What Goes Wrong During Integration, and How Do You Fix It?
Do Cards, Wallets, and BNPL Need Different Integration Work?
Should Mobile Checkout Work Differently Than Desktop?
What We've Learned Building Payment Integrations
Get Transparent Pricing Before You Rebuild Your Checkout
Sources
FAQ

How Does Ecommerce Payment Integration Actually Work?

Every ecommerce payment integration follows the same basic path, regardless of which processor or platform sits behind it. Understanding that path matters more than memorizing API documentation, because it tells you which signals you can trust and which ones will get you into trouble.

The transaction lifecycle runs through five stages:

The customer submits payment details on your checkout page, either through a redirect or an embedded field.
The gateway tokenizes the card data and opens a payment session, so raw card numbers never touch your servers.
The card network and issuing bank authorize or decline the charge, usually within one to three seconds.
The gateway fires a webhook to your server confirming the final transaction state.
Funds settle in batches and get paid out to your bank account on the processor's schedule.

The part developers get wrong most often is trusting the wrong signal. When a customer lands on your "success" page after a redirect, that's a UX cue, not proof the payment cleared. Browsers close, redirects fail, and networks drop packets. The webhook is the only authoritative record that money actually moved, which is why production-ready integrations create the order before initiating the payment session and treat the webhook, not the redirect, as the source of truth.

This distinction shows up constantly in reconciliation. A customer can see a decline message while your backend never receives confirmation either way, because network authorization and webhook delivery are separate events on separate timelines. Build your order state machine to expect a delay between the two, and check payment status against your gateway's dashboard or API before assuming a webhook that never arrived means a failed charge. Checkout friction itself carries real cost: payment-related friction is a leading driver of cart abandonment, so the integration method you choose affects revenue before it ever touches your compliance posture.

Which Integration Type Fits Your Store?

Three integration types cover nearly every ecommerce payment integration project, and each trades off developer effort against control and compliance exposure.

Hosted checkout redirects the customer to a payment page hosted entirely by your processor. You never see card data, your servers never touch it, and setup often takes a few hours of configuration rather than weeks of development. The tradeoff is limited branding control and a moment where the customer leaves your domain, which can dent trust for some shoppers.

Embedded components, also called hosted fields, let you build the checkout page yourself while the card input fields are actually iframes served by the payment provider. The customer never leaves your site, but the sensitive keystrokes still route directly to the processor. This is the middle path: more design freedom than hosted checkout, far less compliance exposure than handling raw card data yourself.

Direct API integration means your servers collect card details and pass them to the processor programmatically. It gives you complete control over the flow, including custom fraud rules, saved payment methods, and complex multi-step checkouts. It also means your infrastructure falls under the strictest PCI scope, since card data transits your own systems even briefly.

Pro Tip: If your team is under five developers and you're not already PCI Level 1 certified, start with embedded hosted fields. You get most of the design flexibility of direct API with a fraction of the audit burden.

Here's how the three map to typical merchant profiles:

No-code or small store: Hosted checkout, minimal engineering, fastest to launch.
Small to mid-size dev team: Embedded hosted fields, balances brand control and PCI scope.
Enterprise with dedicated payments engineering: Direct API, full control, requires SAQ D or equivalent.

Choosing an integration that keeps card data off merchant servers is one of the biggest levers for reducing PCI scope, which is exactly why hosted and embedded approaches dominate among merchants without a dedicated security team. A deeper breakdown of how these flows map to your existing payment stack is worth a read if you're deciding between platforms.

What Do Payment Fees Actually Cost You?

Interchange-plus pricing charges you the card network's actual interchange rate plus a fixed markup, which means your rate fluctuates with card type but stays transparent about what the processor keeps. Flat-rate pricing bundles everything into one number regardless of card type, which is simpler to predict but usually costs more for high-ticket or corporate card transactions. Monthly platform fees, gateway fees, and PCI compliance fees stack on top of either model, and they rarely show up in the headline rate a sales rep quotes you.

The bigger cost driver is almost never the rate itself. It's what happens around the transaction:

Reconciliation overhead, when settlement reports don't match your order records and someone has to manually chase discrepancies.
Dispute and chargeback handling, which consumes staff time regardless of win rate and often carries a fee per dispute filed.
Failed payment recovery, especially for subscription businesses where a declined card can silently kill recurring revenue.
Downtime during peak traffic, which costs far more in lost sales than any fee difference ever could.

Reliability, payment method coverage, and dispute management often affect total cost more than small differences in per-transaction rate. A processor charging 0.2% less that goes down during a flash sale, or that lacks reporting granular enough to catch a reconciliation gap, will cost you more over a year than the cheaper rate ever saved. A closer look at how ecommerce payment processing fees break down is useful before signing anything with a multi-year lock-in.

How Does PCI DSS Apply to Your Integration Choice?

The integration method you choose is the single biggest lever you have over your own PCI DSS compliance burden. Hosted checkout and embedded hosted fields keep card data out of your environment entirely, which typically qualifies you for the simplest Self-Assessment Questionnaire. Direct API integration puts card data through your servers, which pushes you toward a far more demanding SAQ and a heavier annual audit.

PCI DSS scope tracks directly with how much cardholder data your systems touch. Merchants using hosted checkout or embedded hosted fields typically qualify for SAQ A or SAQ A-EP, the lightest assessment tiers, because the card data never transits or resides on their own infrastructure. Merchants running direct API integration usually fall under SAQ D, which covers dozens of controls spanning network segmentation, encryption key management, and access logging.

Three technical practices reduce your real-world risk regardless of which SAQ applies:

Tokenization replaces card numbers with a reference token immediately at capture, so even a database breach exposes nothing usable.
Vaulting stores that token with your processor for recurring billing, letting you charge returning customers without ever storing a card number yourself.
Hosted fields isolate the input elements in an iframe the processor controls, so keystrokes never pass through your JavaScript context.

On the operational side, enforce TLS 1.2 or higher on every endpoint that touches payment data, rotate API keys on a schedule rather than leaving them static for years, and restrict access to production payment credentials to the smallest group of engineers who actually need them. Webhook signature verification deserves its own line item: an unverified webhook endpoint is an open door for anyone who guesses the URL. Paysec's security and encryption controls illustrate the kind of infrastructure-level protection merchants should expect from any processor handling this layer.

What Should a Production Integration Checklist Include?

Getting a payment integration working in a sandbox is the easy part. Getting it to survive real traffic, real network failures, and real customer behavior is what separates a demo from a production system. Six practices consistently separate reliable integrations from the ones that generate support tickets.

Create the order record before opening the payment session. If the payment session gets created first and something fails before your database write completes, you end up with a charge attached to no order. Sequencing the order first is the standard defensive pattern that developer guides converge on for exactly this reason.
Use idempotency keys on every payment request. A retried API call, whether from a flaky connection or a customer double-clicking "Pay," should never create a second charge. Generate a unique key per checkout attempt and pass it with the request.
Design for at-least-once webhook delivery. Processors resend webhooks when they don't get a fast acknowledgment, which means your endpoint will receive duplicates. Testing retry behavior and duplicate event handling before launch catches this before customers do.
Verify webhook signatures and respond with a 200 immediately. Validate the cryptographic signature to confirm the webhook came from your processor, then acknowledge receipt right away and process the business logic asynchronously in a queue. A slow synchronous handler is the most common cause of webhook timeout storms.
Test sandbox scenarios beyond the happy path. Simulate declined cards, expired sessions, and network timeouts before launch, not after your first real customer hits one.
Build reconciliation and orphaned-payment recovery into your workflow. Some transactions will always fall through the cracks between systems. A daily reconciliation job that flags mismatches between your order table and the processor's settlement report, plus a manual review queue for anything that doesn't reconcile automatically, keeps small gaps from becoming customer complaints.

Pro Tip: Keep an events table that records every incoming webhook ID before you process it. Check for that ID first, and skip processing if it's already there. This one pattern eliminates almost all duplicate-charge bugs.

Roll out in stages rather than flipping a switch: sandbox first, then a low-traffic production slice while you watch webhook delivery and reconciliation closely, then scale to full volume once the numbers hold steady. Track decline rates, webhook success percentage, and settlement variance from day one, since catching a drift in any of those early is far cheaper than discovering it during a Black Friday spike.

How Do You Choose a Payment Integration Partner?

Match the integration approach to what your team can actually support, not what looks most impressive on a feature list. A two-person store doesn't need direct API control any more than an enterprise checkout needs to route customers off-domain.

Run through this checklist before committing to a provider:

Which payment methods does it support natively (cards, wallets, bank transfers, buy now pay later)?
How fast does it settle, and does that timing match your cash flow needs?
What does the dispute and chargeback workflow actually look like, step by step?
How detailed is the transaction reporting, and can you export it for accounting reconciliation?
Are the developer docs current, with working code samples, or do they read like they haven't been touched in years?
Is pricing published, or does it require a sales call to find out what you'll actually pay?

Ask any provider directly what happens during a processor outage, whether there's a minimum monthly volume, and whether the contract locks you in beyond month one. Vague answers to any of those three questions are the clearest red flag in the entire evaluation.

Integration approach	Developer effort	PCI scope	Best fit
Hosted checkout	Low	Minimal (SAQ A)	Small stores, fast launch
Embedded hosted fields	Moderate	Low (SAQ A-EP)	Growing stores wanting brand control
Direct API	High	Full (SAQ D)	Enterprise teams with dedicated security staff

A detailed comparison of processor trade-offs covers seasonal scalability and uptime patterns worth reviewing before you sign anything long-term.

How Paysec Supports Your Payment Integration

Some processors offer pricing models that allow merchants to provide flexible payment options to customers while retaining full revenue on transactions, without hidden fees. That transparency extends across the account: no minimum volume requirements, no long-term contracts, and pricing that's stated plainly rather than negotiated behind a sales call.

Merchants across SaaS, restaurants, ecommerce, healthcare, and CBD retail often face processing costs with hidden markups that some generic processors do not disclose upfront. Paysec's ecommerce payment processing solutions are built around the same integration principles this guide covers: keeping card data scope tight, supporting the payment methods your customers actually use, and giving you reporting detailed enough to catch reconciliation gaps before they become disputes.

Operationally, a payment processor may provide detailed transaction reporting for reconciliation and financial visibility, assist with PCI compliance to reduce audit burden, offer features tailored to compliance and payment needs of specific industries, and provide dedicated merchant accounts rather than aggregated processing.

Additional case studies and industry-specific credentials are available directly through Paysec for merchants evaluating a switch.

Do You Need Code Examples to Get Started?

You don't need to write a custom payment engine to launch, but you do need a working reference implementation to test against. Most modern gateways ship SDKs for the common ecommerce stacks, and the setup pattern looks nearly identical across languages once you understand the sequence.

For a Node.js or Python backend, the pattern is: create the order in your database, call the gateway's API to generate a payment session or client token, return that token to your frontend, and let the embedded fields or hosted redirect handle the actual card capture. Your server never sees raw card data in this flow. The frontend then confirms the session client side, and your backend waits for the webhook to mark the order paid.

For platforms like Shopify, WooCommerce, or Magento, most of this scaffolding already exists as a plugin, and your integration work shrinks to configuring API keys, mapping webhook events to order status updates, and customizing the checkout UI within the platform's constraints. The core logic (order first, webhook as truth, idempotent processing) doesn't change. Only the amount of code you write yourself does.

A minimal webhook handler, regardless of language, needs four steps: verify the signature against your gateway's secret, check whether you've already processed this event ID, update the order status if not, and return a 200 response immediately so the gateway doesn't retry unnecessarily. Skipping any one of those four steps is where most integration bugs originate.

How Long Does a Payment Integration Actually Take?

A hosted checkout integration typically takes a short time for a small team, most of that spent on branding the redirect flow and testing sandbox transactions. Embedded hosted fields usually run several weeks, since you're building custom checkout UI around the provider's iframe fields and handling more edge cases in your own code.

Direct API integration is the outlier. Plan for at least a month if your team is building fraud rules, saved payment methods, or multi-currency support alongside the core integration, and longer if you're pursuing SAQ D certification for the first time. That timeline stretches further for teams new to payments engineering, since the learning curve around webhook idempotency and reconciliation logic tends to eat more calendar time than the actual API calls.

Regardless of integration type, budget real time for staged rollout. Sandbox testing, a low-traffic production trial, and 48 to 72 hours of close monitoring on webhook delivery and settlement matching before scaling to full volume adds a week or two beyond "the code works," but it's the difference between catching a reconciliation bug with ten transactions instead of ten thousand.

Rushing this phase is the most common reason integrations that tested fine in sandbox start failing quietly in production, usually around webhook timing or duplicate event handling that never surfaced under low sandbox traffic.

What Goes Wrong During Integration, and How Do You Fix It?

The most common failure mode isn't a broken API call. It's a webhook that never arrives, or arrives twice. Network partitions, server restarts during deploys, and processor-side retries all create scenarios where your order state and the processor's actual transaction state drift apart.

Duplicate charges happen when a customer's browser retries a submission and your backend treats it as a new payment attempt instead of recognizing the retry. Idempotency keys fix this at the source, but only if you actually check for an existing key before processing rather than after.

Orphaned payments, where the processor confirms a charge but your order record never gets created, usually trace back to sequencing: the payment session got created before the order write completed, and something failed in between. Reversing that order, order first, then payment session, eliminates most of this category.

Order-first payment sequencing illustration

Webhook timeout storms happen when your handler does too much synchronous work (database writes, email sends, inventory updates) before responding. The processor's timeout fires, it assumes delivery failed, and it resends the same event, sometimes several times. Acknowledge receipt first, queue the actual processing, and this problem disappears.

Reconciliation mismatches between your ledger and the processor's settlement report are often just timing differences, not errors: a payment can authorize on one calendar day and settle on the next. Build your daily reconciliation job to account for a rolling window rather than a hard cutoff, and flag only the transactions that stay unmatched after 48 hours for manual review.

Do Cards, Wallets, and BNPL Need Different Integration Work?

Credit and debit cards remain the baseline every gateway supports natively, and integrating them through hosted fields or a hosted redirect covers the majority of transaction volume for most stores without extra engineering work.

Digital wallets like Apple Pay and Google Pay require a bit more setup: domain verification, a merchant identifier, and a slightly different token exchange than raw card capture. The payoff is a meaningfully faster checkout, since wallet payments skip manual card entry entirely, which is part of why reducing checkout friction improves conversion as directly as it does.

Buy now, pay later options integrate more like a parallel payment method than a variation on card processing. The BNPL provider typically handles its own approval flow, sometimes with a redirect of its own, and settles with you on a different schedule than card transactions, often faster since the BNPL provider assumes the credit risk upfront. That means your reconciliation logic needs to treat BNPL settlements as a separate stream rather than lumping them into card settlement reports.

Bank transfers and region-specific methods add another layer, particularly for merchants selling across borders, where local payment preferences vary widely and are increasingly shaped by regulation like the Payment Services Directive governing how payment providers operate across the EU. Supporting more methods generally means more webhook event types to handle, not more core integration logic. The pattern of order first, webhook as truth, idempotent processing holds across every method you add.

Do Cards, Wallets, and BNPL Need Different Integration Work? — overview diagram

Should Mobile Checkout Work Differently Than Desktop?

Mobile checkout isn't a smaller version of desktop checkout. It's a different environment with different failure modes, and treating it as an afterthought is where a lot of otherwise solid integrations lose conversion.

Screen size is the obvious constraint, but the deeper issue is input friction. Typing a sixteen-digit card number on a mobile keyboard is slow and error-prone, which is exactly why digital wallets matter more on mobile than desktop. Apple Pay and Google Pay let a customer complete checkout with a fingerprint or face scan instead of typing anything, and that shortcut disproportionately helps mobile conversion since it eliminates the worst part of the mobile checkout experience entirely.

Network reliability also behaves differently on mobile. A customer on cellular data is far more likely to hit a dropped connection mid-checkout than someone on a stable home network, which makes your webhook-as-truth architecture even more important. A mobile customer might see a spinner freeze and back out of the app entirely, unaware their payment actually processed on the backend, so your order confirmation and email receipt logic need to work independent of whatever happened on their screen.

Embedded hosted fields generally render fine across mobile browsers, but test your actual checkout flow on real devices, not just a resized desktop browser window. Paysec's mobile payment processing options are built with this exact gap in mind, for merchants whose traffic increasingly skews toward phones rather than desktops.

What We've Learned Building Payment Integrations

Two things stand out after years of watching merchants integrate payments: reliability beats rate shopping, and the webhook is the whole ballgame. Merchants who chase the lowest advertised rate often end up paying more in reconciliation headaches and support tickets than they saved on the transaction fee. The integrations that hold up under real traffic are the ones where the team treated the webhook path as sacred from day one, not the ones with the most polished checkout UI.

The other lesson is simpler: most merchants don't need direct API control, and assuming you do is usually a costly guess. Hosted or embedded flows cover the vast majority of use cases with a fraction of the compliance overhead.

If you're weighing a switch or planning a first integration, Paysec's team can walk through your specific volume and vertical to identify where a tailored assessment makes sense. Start with Paysec's solutions overview to see what fits your stack.

— PaySec Marketing Team

Get Transparent Pricing Before You Rebuild Your Checkout

Every processor in this guide charges you something beyond the sticker rate: hidden interchange markups, reconciliation gaps, or contract terms that lock you in past the point where a better deal appears. Paysec's Network Offset Pricing works differently. Merchants keep full revenue on transactions while still offering customers flexible payment options, with no hidden fees, no minimum volume requirements, and no long-term contract standing between you and a better deal if your needs change.

Paysec also provides PCI compliance assistance to reduce the audit burden that comes with whichever integration method you choose, plus real-time reporting so reconciliation stops being a monthly guessing game. Visit Paysec's industries page to see how the pricing model applies to your specific vertical, and request a tailored cost assessment to see what you'd actually save on your current processing volume.

Sources

FAQ

What Are the Main Types of Payment Gateways for Ecommerce?

The main types are hosted checkout, embedded hosted fields, direct API integration, and vaulted or tokenized recurring billing setups, plus wallet-specific integrations for Apple Pay and Google Pay. Most stores combine two or three of these rather than relying on just one.

What Is a Payment Integration?

A payment integration is the technical connection between your ecommerce store and a payment gateway that authorizes, processes, and confirms transactions. It covers everything from the checkout UI to the webhook logic that marks an order as paid.

How Do I Integrate Online Payments Into a Website?

Choose an integration type based on your team's resources, connect your gateway's SDK or API, create the order record before starting the payment session, and build a webhook handler that verifies signatures and updates order status idempotently. Test extensively in sandbox before going live.

What Is the Best Payment Gateway for Ecommerce?

There's no single best gateway for every store, since the right fit depends on your payment method coverage needs, settlement timing, and reporting requirements. Paysec's Network Offset Pricing and transparent, contract-free structure make it a strong option for merchants prioritizing cost predictability alongside reliable ecommerce payment integration support.