Payment gateway integration is the work of connecting your checkout to a service that collects card details, encrypts them, and passes them to the banks that approve the charge. That is the whole definition. The gateway is the front door the money walks through, and integrating it means wiring that door into your website, your app, or your order form.
Most guides to payment gateway integration are written for a software team building an online store where the customer buys a file or a subscription and the transaction ends the moment the card clears. If you bake, arrange, cater or wholesale, the transaction does not end there. Somebody paid at 9pm for a delivery that goes out at 6am, the order changed weight on the way to the van, and a tip got added at the door. The integration has to survive all of that.
This guide covers what the integration is, the three ways to build it, and the parts that behave differently when the goods leave hours after the card is charged. If you are still sorting out which piece of the stack does what, the companion piece on payment gateway vs payment processor separates the two before you start signing contracts.
The Bottom Line
- A gateway integration is one connection with three possible depths: a hosted page you redirect to, hosted fields you embed, or a direct API call from your own server. The depth you choose decides your compliance paperwork more than it decides your checkout design.
- For deliveries, the pattern that matters is authorize at checkout and capture at handoff. Stripe releases an uncaptured authorization after seven days by default, and incrementing the amount does not extend that clock (Stripe Documentation, retrieved September 2026).
- Letting the provider host the card fields can move you from SAQ D, with its 300-odd requirements, to SAQ A and roughly 20 (OneUptime, retrieved September 2026). It does not make you exempt.
- Budget two line items, not one: the gateway fee for the technology and the processing fee for moving money. Flat-rate online pricing in 2026 clusters around 2.9% plus $0.30 (Stripe, retrieved September 2026).
- Webhooks are not optional in a delivery operation. You need to hear about a failed capture before the van leaves, not when you reconcile on Friday.
Boost customer satisfaction with just a few clicks
Most-Loved Features:
- On-demand drivers
- Real-time GPS tracking
- Delivery confirmation photos
- Over 50% of customers report a smoother delivery experience
What payment gateway integration involves
Integration means three concrete things: the gateway gets to collect the card, your system gets an identifier it can use later, and the two stay in sync about what happened to the money.
The card details are the reason this is harder than connecting any other API. Raw card numbers carry compliance weight, so a good integration is built to never let them touch your server. The gateway hands you a token instead, a harmless string that stands in for the card, and your order record stores that. Every later action, from capturing the final amount to refunding a dropped delivery, works off the token and a transaction ID.
What integration does not mean is picking one vendor to do everything. You are connecting to a gateway, but behind it sits a processor, an acquiring bank and the card networks. Whether you contract with those separately or get them bundled into one flat-rate account is a commercial decision, not an integration one.
How a payment gateway works, step by step
A single approval is a round trip through five parties, and it finishes in about two seconds.
- The customer enters card details into a form the gateway controls.
- The gateway encrypts the details and swaps the card number for a token.
- The gateway sends an authorization request to the payment processor.
- The processor routes it through the card network to the customer’s issuing bank, which checks the balance, runs its own fraud scoring, and approves or declines.
- The answer travels back the same way, and your checkout shows approved or declined.
Approval is not payment. An approved authorization is a hold: the bank has set money aside and the customer sees a pending charge, but nothing has moved into your account. Money moves on capture, and settlement, when funds actually land, typically follows a day or two later. That lag is a property of the banking rails underneath, not of your integration, and shortening it is one of the stated goals of the longer-run work to rebuild financial infrastructure on open networks.
That gap between authorization and capture is a nuisance for a coffee shop and a useful tool for a business that delivers. It is where the substitutions, the weight differences and the tips get resolved.
The three ways to integrate a payment gateway
Every provider markets its integration options differently, but they reduce to three patterns, and they trade control against compliance burden in the same direction every time.
| Integration type | Where card data is entered | Your PCI burden | Control over checkout | Build effort |
|---|---|---|---|---|
| Hosted page (redirect) | On the provider’s page, on their domain | Lowest, usually SAQ A | Low: their layout, their branding options | Hours to days |
| Hosted fields (embedded form or drop-in) | In the provider’s iframe, inside your page | Low, usually SAQ A | High: your page, their input boxes | Days |
| Direct API (self-hosted) | In your own form, on your server | Highest, SAQ D territory | Total | Weeks, plus ongoing audit work |
The hosted page is the redirect you have seen a hundred times: the customer leaves your site, pays, and comes back. It is fast to stand up and it keeps card data entirely away from you. The cost is a visible seam in the checkout and less say over how the page looks on a phone.
Hosted fields are where most businesses that deliver should land. The card inputs are served by the provider inside an iframe, so the numbers never reach your server, but the rest of the page is yours: delivery date picker, route cutoff notice, tip line, substitution policy. You get a checkout that understands delivery without taking on the compliance load of touching cards.
Direct API integration means your own form collects the card and your server forwards it. It buys total control and it is how large operations build multi-provider routing, usually with a specialist firm doing the custom payment processing development rather than an in-house generalist. For most food, floral and wholesale businesses it is the wrong trade: you inherit the full weight of PCI DSS to solve a problem hosted fields already solve.
Why authorization and capture timing matters when orders leave hours later
Set your integration to authorize at checkout and capture at handoff, and most delivery payment problems disappear before they start.
Capturing the full amount at checkout is the default in nearly every integration guide, because it is correct for a business shipping a fixed item. It is wrong for an order whose final total is not knowable at checkout. A 15-pound case comes in at 14. Two of the six pastries are out, so you substitute. The customer adds a tip when the driver arrives. Capture first and every one of those becomes a partial refund, a second charge, or a phone call.
Authorize first and you have a hold you can adjust. Two constraints govern how long you have:
- The hold expires. By default a Stripe authorization expires in seven days, after which the funds are released and the payment is canceled (Stripe Documentation, retrieved September 2026).
- Raising the amount does not buy more time. Incremental authorizations let you increase an authorized amount before capture, but they do not extend the validity period, so the full amount still has to be captured before the original authorization lapses (Stripe Documentation, retrieved September 2026).
Each increment also shows up as its own pending line on the customer’s statement until you capture, at which point they collapse into a single final charge. Tell a wholesale customer that before they call about three pending amounts on one order.
For standing weekly orders or anything scheduled further out than a week, do not try to hold an authorization open. Save the card as a reusable token at signup and charge it per delivery instead.
What PCI compliance still requires after integration
Handing card entry to your gateway shrinks your compliance paperwork substantially, and it does not eliminate it.
The self-assessment questionnaire you qualify for is the practical measure. A merchant whose payment page is hosted by a compliant third party, with no cardholder data on their own systems, can typically attest with SAQ A and its roughly 20 requirements instead of SAQ D and its 300-plus (OneUptime, retrieved September 2026). That is the single largest benefit of not building your own card form.
The catch arrived with PCI DSS v4: the client-side script requirements, 6.4.3 and 11.6.1, reach merchants whose own pages surround or embed a third party’s payment form. In other words, the SAQ reduces what you attest to about your environment, but it does not clear you of responsibility for the scripts running on your checkout page (GuidePoint Security, retrieved September 2026). If your checkout loads a chat widget, an analytics tag and two marketing pixels, those are now your problem. Keep an inventory of what loads on that page and keep it short.
Two other things belong in the same bucket. Your checkout has to run over HTTPS before a gateway will work with it at all, and your provider’s compliance certification covers their systems, not yours.
What payment gateway integration costs
Expect two recurring charges and one or two one-off ones, and read every quote for which of the two it is actually describing.
Gateway fees pay for the technology that captures and transmits card data at checkout. Processing fees pay for moving money between the customer’s bank and yours, and they carry interchange set by the card networks (IXOPAY, retrieved September 2026). Bundled flat-rate providers quote you one blended number that contains both; unbundled setups bill them separately, which looks more expensive on the invoice and is often cheaper in total at volume.
The numbers to anchor on for 2026:
- Blended online rate. Flat-rate pricing clusters around 2.9% plus $0.30 per successful transaction, with no monthly fee on standard accounts (Stripe, retrieved September 2026).
- Card processing generally. Across processors, per-transaction rates run roughly 1.5% to 3.5% plus a fixed $0.10 to $0.30 (MyPayAdvisor, retrieved September 2026).
- Monthly platform fees. Subscription-tier gateways charge for dashboard access, support and reporting; pay-as-you-go providers do not.
- The extras that catch delivery businesses. Chargeback fees, refund fees, cross-border and currency conversion charges, and faster-settlement surcharges.
That last line matters more than the headline rate if you refund often. A business that occasionally re-runs a delivery and refunds the first attempt pays for those events individually.
How to integrate a payment gateway: the steps in order
The build itself is short. Integration timelines of roughly one to seven days are typical, depending on which of the three patterns you chose (ConnectPay, retrieved September 2026). The approval paperwork is usually the long pole, not the code.
- Open a merchant account. This is the account that receives your money. Underwriting asks for business documents and can take longer than the technical work, because payment service providers carry their own identity and compliance obligations when they onboard a merchant.
- Confirm HTTPS across checkout. A valid certificate on every page in the flow is a prerequisite, not a nice-to-have.
- Get your API credentials. You will receive publishable and secret keys, plus a separate pair for the sandbox. Secret keys belong in server-side environment variables and nowhere near your front end or your repository.
- Install the integration. On Shopify, WooCommerce or Squarespace this is a plugin and a paste of your keys. On a custom site, it is the provider’s drop-in component or a direct API call.
- Configure the behavior you need. Set capture to manual if you are authorizing at checkout. Add the currencies and card brands you accept, and set up your delivery-fee and tip line items so they report separately.
- Register webhook endpoints. Subscribe to the authorization, capture, failure, refund and dispute events at minimum.
- Test in the sandbox, then test small in production. Details below.
- Attach every charge to an order record. Store the transaction ID and token against the order, not in a payments table nobody reconciles.
Step 8 is the one that gets skipped and the one that costs you later. If a driver reports a refused delivery, whoever handles it needs to reach the right charge from the order screen in one click.
What to test before your first live delivery order
Run the unhappy paths, not just the sale. A gateway integration that only handles clean transactions will break during your first busy morning.
- A declined card at checkout. Confirm the customer sees a usable message and no order enters your route with an unpaid status.
- An authorization captured for less than the authorized amount. This is your substitution case.
- An authorization incremented upward, then captured. This is your tip and weight-adjustment case.
- An expired authorization. Let one lapse deliberately in the sandbox and watch what your system does when capture fails.
- A full refund and a partial refund. Check both land as one clean event against the original order.
- A webhook you did not receive. Providers retry, and duplicates happen. Send the same event twice and confirm you do not double-charge. That is what idempotency keys on write calls are for.
- A chargeback notification. Know where it lands and who reads it before one arrives.
Then run a real card for a small amount on a real delivery, and follow the money all the way to your bank statement. Sandbox success and settled funds are different claims.
Frequently asked questions
Do I need a payment gateway if I already have a POS system?
For in-person sales the terminal handles it. The moment you take an order over your website, by phone, or from a wholesale customer on invoice, you need a gateway to collect that card-not-present payment, which is why many delivery businesses end up with both, ideally reporting to one place.
Can I integrate more than one payment gateway?
Yes, and businesses do it for redundancy or to route different order types to different providers. It doubles your reconciliation work, so do it when one provider’s outage would stop your morning, not before.
How long does payment gateway integration take?
The technical work runs from a few hours for a hosted plugin to a few weeks for a direct API build, with one to seven days typical for a standard integration (ConnectPay, retrieved September 2026). Merchant account underwriting is the part that sets your real timeline.
Should I charge at checkout or at delivery?
Authorize at checkout and capture when the order is handed over, provided your delivery window sits inside the authorization’s validity period. For anything further out, or for recurring standing orders, store the card and charge per delivery instead.
What happens to the charge if a delivery fails?
That depends on what you have already done to the money. If you have only authorized, cancel the authorization and the hold is released. If you have captured, you are issuing a refund and paying whatever refund fee your provider charges. This is the practical argument for capturing at handoff rather than at checkout.
Getting the integration to fit how you actually sell
The integration decisions that matter for a delivery business are not the ones the standard guides emphasize. Hosted fields over a custom card form, manual capture over automatic, webhooks over polling, and one order record that holds both the charge and the delivery. Those four choices handle substitutions, tips, failed drops and reconciliation without a workaround.
Pick the shallowest integration that still gives you control of the page, wire the events you need, and test the failures before the morning rush finds them for you.
