Insights · 5 min read
Payment gateway integration looks simple until the first failed webhook. What integration really involves, what it costs, and the edge cases that bite.
By GGP Editorial
Most developers will tell you payment gateway integration is a two-day job. It is, if the only thing you need is a button that takes a card and shows a success page. A real business needs more than that button, and the missing pieces are where the pain hides.
I have watched teams ship a payment integration, celebrate, and then spend the next month untangling refunds, timeouts, and reconciliation gaps that were entirely avoidable. Here is what I tell clients before they write the first line.
A payment gateway sits between your product and the banks and card networks that move the money. On paper you send a request, read a response, and store it. In practice the work breaks into layers, and the checkout button is the smallest one:
The checkout is maybe twenty percent of the effort. The rest is the plumbing that keeps your books correct, and it is the part most teams skip.
The happy path is boring. The interesting cases are the ones that cost you money.
A customer pays and the gateway returns a timeout. You don't know whether the money moved. Treat it as failed and they retry, and now they've paid twice. Treat it as success and it wasn't, and you ship goods for free. The fix is idempotency keys and a clear status model, and a surprising number of integrations ship without either.
A webhook arrives twice, or out of order. If your handler isn't idempotent you double-count revenue. If it silently drops an event, your ledger is short and nobody notices until month-end close.
A refund is issued but the gateway keeps part of the fee, so your numbers and theirs drift apart. Reconciliation turns into a weekly manual chore instead of an automated one.
None of these are hard to handle up front. All of them are expensive to fix after launch.
For one gateway in one market, a clean integration runs from a few thousand dollars to around ten and takes two to four weeks. Add more gateways, currencies, subscriptions, or marketplace split payments and the effort climbs quickly.
| Scope | Typical effort | Rough cost |
|---|---|---|
| Single gateway, one currency | 2 to 4 weeks | $3k to $8k |
| Two to three gateways, multi-currency | 1 to 2 months | $8k to $20k |
| Marketplace with split payouts | 2 to 3 months | $20k to $40k |
The numbers assume a team that has done it before. The real cost driver is rarely the gateway API. It is the accounting and operations work wrapped around it, plus the security and compliance you have to carry.
If you touch card data you fall under PCI DSS scope, and the cheapest way to shrink that scope is to never store card numbers yourself. Use a gateway that tokenizes the card and hands you back a token. You still need to be careful with the data you do keep: names, amounts, and transaction history are sensitive enough on their own.
Also budget for the boring controls. Access logs, encrypted backups, and a documented refund policy are not features, they are the price of admission, and a payment system without them will fail an audit the first time anyone looks hard.
Pick the gateway by market, not by brand loyalty. What works well in the United States may not be available or cheap in Brazil, and South Africa has its own local options and banking rules. A gateway with no local acquiring partner means higher fees and more declined cards, and no amount of code fixes that.
One more thing worth deciding early: whether a gateway is enough at all. If you are just accepting payments, integration is all you need. If you plan to hold balances, split funds between parties, or run your own settlement schedule, you are drifting into building a payment system, which is a different project with different risks. It helps to know which one you are building before you commit.
On the team side, you want people who have moved real money before, because the failure modes are subtle. We have built payment and settlement flows for trading platforms running across Hong Kong, US, and China A-share markets, plus self-ordering and POS systems that take payments in store. That experience is mostly about knowing what breaks, which is the thing you can't learn from a docs page.
We work across time zones on overlapping hours with a dedicated group, in English or Portuguese, so a payment problem that appears in your afternoon gets eyes on it the same day. Payment work rewards careful, boring engineering, and that is exactly what you want holding up your revenue.
Tell us what you are building and where you are today. We typically reply within 24 hours.
