For most businesses, the right approach to payment gateway integration is one provider wrapped properly behind your own small payments module. A full abstraction layer that routes across several gateways is usually the wrong choice. A multi-gateway layer pays off only under a few specific business conditions, and it costs far more to own than the whiteboard diagram suggests.
You may be a CTO or founder, and someone in a planning meeting just said "we can't be locked into one payment provider". If so, this is for you. The worry is fair. The fix people reach for first is usually the expensive one.
Why does a multi-gateway layer look cheap but cost so much to own?
Taking a card payment is the easy part. The diagram shows charge(), refund() and a dropdown of providers. The real work is everything after the charge: delayed events, partial refunds, disputes, saved cards, payouts, and the monthly question from finance, "does this match the bank?"
Each gateway handles those things in its own way. Your abstraction has two options. It can flatten the differences and lose features, or it can expose them and stop being an abstraction.
Here is where the differences actually bite.
Webhooks don't mean the same thing everywhere
One provider sends "authorised" and "captured" as separate events. Another sends a single success. Event names differ, signature schemes differ, retry schedules range from hours to days, and events can arrive out of order.
So your layer needs its own payment states (pending, authorised, captured, failed, refunded, disputed). It needs a map from each provider's events into those states. And it must handle each event only once, using the provider's event ID to spot repeats. If the map is slightly wrong, an order shows as paid when the money never arrived.
Refunds are pinned to the gateway that took the money
You can route a new payment anywhere. You cannot route a refund. It has to go back through the provider that took the original charge, under that provider's rules for partial refunds, refund windows and methods like bank transfers.
A refund can also be accepted and then fail later, as a separate event. Your support team needs to see that for every provider, in one place.
Stored cards can't simply move between providers
The card token a gateway gives you only works at that gateway. If a customer saved a card through provider A, you cannot charge it through provider B.
Moving saved cards means a formal data migration between two PCI-compliant providers. You request it through support, sign agreements, run test batches and coordinate for weeks. In some markets, recurring payment mandates are registered with one specific provider, and customers may need to approve them again after a move. For a subscription business, "fail over to the backup gateway" mostly helps new customers, not the ones already paying you.
Reconciliation becomes your job
Each provider settles money on its own schedule, takes fees out differently and exports reports in its own format. With one provider, its dashboard does most of the matching. With two, you need an internal ledger: a record of every money movement, tagged with the provider's reference and matched to the bank deposit it arrived in.
That ledger is a product in its own right. Someone has to own it.
What does it cost to get this decision wrong?
Build the layer too early and the problems pile up:
- double charges when a retry slips past the layer
- refunds that fail without anyone noticing
- a month-end close that drags on for days
- an engineer stuck full time keeping provider adapters up to date
New provider features like wallets or local payment methods also reach your customers late, because each one has to fit the shared interface first.
Skip the wrapping and you get the opposite failure: calls to the provider's code library (its SDK) spread across your whole codebase. The day you really do need a second provider, it becomes a rewrite under pressure, often while a market launch waits.
When is a multi-gateway layer worth building?
Build it only when at least one of these is true and you can state it in one sentence:
- You sell in markets no single provider covers well. If customers expect UPI in India, iDEAL in the Netherlands or Pix in Brazil and your main provider handles them poorly, add a second gateway for that market.
- Your volume makes approval rates a revenue question. At high volume, small differences in how often each provider approves cards start to matter. You also need someone who can tune the routing with real data.
- Checkout downtime would do serious damage. Ticket drops, flash sales and exam registrations can't wait out a provider outage. Failover only covers cards typed in fresh, not saved ones.
- You run a marketplace where merchants bring their own provider. Then supporting several gateways is the product, not overhead.
- A bank partner, regulator or enterprise client requires a second processor in the contract.
"What if we need to switch one day" is not on that list.
Who should commit to one provider?
You should commit if you sell mainly in one region, run mostly on subscriptions, have a small engineering team or are still finding product-market fit. Pick the provider that covers your markets and payment methods, then wrap it well. If your team has shipped a payments integration before, you can do this without outside help.
What does "one provider, well wrapped" look like?
The list is short, and each item has a reason:
- One payments module makes every call to the provider. The cost of leaving later grows with every file that talks to the provider directly.
- Your database holds your own IDs and statuses, with the provider's IDs kept as references. Your order history survives a switch.
- Your webhook handler checks the provider's signature, saves the raw event and safely ignores duplicates. You can replay, audit and debug any payment.
- You keep an internal ledger from day one. Month-end matching stays simple, and a second provider can feed into the same ledger later.
- Card details only go through the provider's hosted card fields or hosted checkout page. Fewer of your systems fall under PCI security rules.
- Your contract says the provider will export stored card data to another PCI-compliant processor on request. That clause is your real exit plan for saved cards.
Don't build general-purpose interfaces for features you don't use yet. Wrap what you have today.
What should you ask before deciding?
Put these questions to your team or development partner:
- Which condition from the list above justifies a second gateway?
- Will our provider export stored cards, how long does that take, and what do customers notice during the move?
- Which features we rely on, such as subscriptions, split payments or wallets, have no equivalent at the second provider?
- If the main gateway goes down, which payments can switch over: only cards typed in fresh, or saved cards too?
- Who owns reconciliation, and what does month-end look like with two settlement reports?
If nobody can answer the first question clearly, you don't need the layer yet.
In what order should you do this?
Start with one provider behind a clean payments module, plus a ledger. Add a second provider only where the business case is clear, such as one market or one payment method. Build automatic routing between providers last, and only when your own data shows it would raise approval rates or uptime enough to justify the work.
That order keeps every step reversible.
Payments are one of many build decisions for an online store, and our ecommerce development guide covers the rest, from catalogue to checkout to fulfilment. If you'd like a second opinion on your current payments setup or plan, Geminate Solutions offers a free review and replies within 24 hours.
Top comments (1)
The contract clause about exporting stored cards is the one most teams skip, and it is the only real exit plan once cards are on file, so putting it in writing before signing is the right order. I would add one item to the one-provider checklist: decide early where an asynchronously failed refund lands, because a refund that was accepted and then failed later is the reconciliation headache nobody puts on the whiteboard. The 'what if we need to switch one day' callout is fair; a thin payments module gives you the same optionality without the maintenance bill.