Insights · 5 min read

Payment gateway integration: what it really costs

Connecting a payment gateway looks like a one-day job until you add refunds, subscriptions, and local methods. Here is where the time and money actually go.

By GGP Editorial

Integrating a payment gateway sounds like a one-day job until you read the docs. Plug in an SDK, paste a few keys, and you are taking cards, right? That is true for a simple one-off charge. It stops being true the moment you add refunds, subscriptions, or a second currency.

This post is for founders and product owners trying to budget a payment integration without a developer in the room. It covers what actually takes time and what you should expect to pay.

The integration itself is the cheap part

A single gateway, one currency, one-off payments, and a basic webhook can be done in a few days by someone who has done it before. Most gateways, from Stripe and Adyen to Pix in Brazil and local Chinese channels, have decent SDKs and test sandboxes.

The work gets interesting when you go past that:

  • Subscriptions and recurring billing, which means handling card updates, retries on failed charges, and dunning emails.
  • Refunds and partial refunds, and keeping your own order state in sync with the gateway's.
  • Multiple payment methods. In Brazil you need Pix and boleto. In South Africa you might need card plus an instant EFT option. Each method is another integration and another reconciliation path.
  • Reconciliation. Matching the gateway's settlement report to your own ledger is where finance teams burn the most time.

A rough cost table

These are integration costs paid to a development team. The gateway's own per-transaction fees are separate and usually the bigger number over time.

ScopeWhat is includedTypical cost
BasicOne gateway, card payments, webhooks, test and live$2,000 to $5,000
StandardAdd refunds, subscriptions, receipt emails, admin view$5,000 to $12,000
Multi-methodCard plus Pix, boleto, or similar local methods, reconciliation$12,000 to $30,000

The jump from standard to multi-method is mostly testing and reconciliation, not code. Each method has its own status codes, timeouts, and edge cases around chargebacks and disputes.

The part people forget: compliance

If card data touches your server at all, PCI DSS applies. The cheapest way to stay out of scope is a hosted page or a tokenized flow where the card number never reaches your code. That is a design decision made early, and changing it later means rework.

For cross-border payments, add KYC and AML checks, currency conversion, and local tax handling. An integration that ignores these will pass testing and then fail a real audit or a real chargeback dispute.

The gateway's own fees add up

The integration cost is a one-time number. The gateway's fees are forever, and they deserve as much attention.

Card gateways typically charge a percentage plus a fixed amount per transaction, often 2.5 to 3.5 percent for cross-border cards. Local methods are cheaper: Pix in Brazil is often a flat fee per transaction, and boleto has its own schedule. Add a monthly fee for some gateways, a chargeback fee of $15 to $25 per dispute, and a currency conversion markup, and the real cost of taking payments can quietly reach 4 percent.

Before you pick a gateway, ask for the full fee schedule, not the headline rate. The headline rate is the best case, and your real volume will land somewhere worse.

Test it like a finance team

A payment integration is not done when the happy path works. Have your finance team run the odd cases in the sandbox before you go live: a card that expires mid-subscription, a refund on a partial order, a dispute that arrives a month later, a settlement file with a rounding difference. Each one you catch in testing saves a support ticket and a confused customer later.

Our team has built payment flows that include local methods like Pix, so the sandbox-to-live checklist is a routine part of the work rather than a discovery process.

What we have learned building these

We build payment and financial systems as part of our normal work, and the pattern is always the same. Clients budget for the "connect the gateway" part and get surprised by the "keep the ledger honest" part. It is not a bug in the estimate. It is a scope gap.

The fix is to write down the money flows before any code. Draw every state an order can be in: created, paid, partially refunded, refunded, failed, disputed, expired. Then decide who owns each transition. If you cannot draw it on a whiteboard, the integration will cost more than the estimate, whoever you hire.

We run a China-based team with overlap hours for clients in the Americas, Europe, and Africa, and we have delivered payment work across a few markets, so the timezone and the local-method questions are ones we have already worked through.

Talk to us about your project

Need help applying this?

Tell us what you are building and where you are today. We typically reply within 24 hours.