Payment gateways for fintech startups: a technical guide

For a fintech startup, the payment gateway is not an infrastructure detail: it is one of the few pieces that touches margin, user experience and risk all at once. A rushed decision in the first weeks is paid for over years, both in per-transaction costs and in technical dependence on a single provider.

The good news is that the decision can be made with concrete criteria. The bad news is that almost no public comparison explains them, because the gateways' business model depends on the integration being easy to start and hard to leave.

What to check before signing with a gateway

Before writing the first line of code, it is worth evaluating each provider against a short, measurable list.

• Real cost per transaction. In Argentina and much of LATAM, card gateways usually sit between 3% and 6% plus VAT per operation, with additional fixed costs and settlement times ranging from 24 hours to several days. International players like Stripe hover around 2.9% plus a fixed fee per transaction. The number on the homepage is never the final number: you have to add chargebacks, withdrawals and currency conversion.
• Approval rate. Two gateways with the same fee can differ by several points in how many payments they approve. Every point lost is revenue that never comes in, so this figure weighs more than the nominal fee.
• Settlement and reconciliation model. How and when the money is credited, what reports it delivers and whether those reports match your database without manual work.
• PCI DSS and sensitive data handling. Ideally the gateway tokenizes the card and your system never stores the full number. That keeps your company at the lightest compliance level (SAQ A) instead of taking on the full audit burden.
• Lock-in. How tightly the billing logic is tied to that provider. If migrating gateways means rewriting half the backend, you have already lost negotiating power.

Why multi-gateway stops being optional

When volume grows, relying on a single gateway is a business risk, not just a technical one. If that provider goes down, suffers a degradation or rejects a range of cards, revenue stops entirely.

A multi-gateway architecture solves two problems at once:

1. Failover. If the primary gateway rejects or fails to respond, the charge is retried against a secondary one, transparently for the user.
2. Smart routing. Each payment can be directed to the gateway that best approves that type of card or issuer, or to the one with the lowest cost for that method. In practice, routing by issuer and adding a second backup provider tends to recover between 2 and 5 points of approval rate.

The cost of building this is real, but it pays off quickly: in a fintech processing volume, recovering three approval points is a direct revenue increase without spending a single peso more on acquisition.

Smart retries and reconciliation: where money is won or lost

Not every decline is the same. There are "hard" declines (stolen card, closed account) where retrying makes no sense, and "soft" declines (temporary insufficient funds, a temporary limit) where a retry at the right moment recovers the charge. Retrying blindly burns costs and can trigger antifraud blocks; retrying by reading the response code recovers revenue that most off-the-shelf products leave on the table.

Reconciliation is the other silent half. Every payment must be matched against what the gateway actually settled, accounting for fees, chargebacks and reversals. When this is done by hand in a spreadsheet, it breaks as soon as volume rises. When it is automated with idempotent webhooks (that is, that process the same event only once even if it arrives duplicated), the finance team stops chasing mismatches.

Payment splitting and marketplace models

If the product distributes money among several parties (a marketplace, a services platform, a commission model), the requirement for payment splitting appears: charge once and automatically settle to each beneficiary, withholding the platform's commission. Not all gateways support this natively, and those that do impose their own logic. Designing this layer above the gateways, and not tied to a single one, is what allows you to change providers without rebuilding the business model.

When a custom integration beats off-the-shelf

A prebuilt payment button is the right option to validate an idea in the first week. It stops being so when the business scales and the billing logic becomes a competitive advantage.

A custom integration wins when the company needs to orchestrate several gateways, apply its own retry and routing rules, reconcile automatically, support payment splitting and, above all, not be held hostage by one provider. A multi-gateway integration with well-resolved reconciliation and webhooks usually takes between 4 and 10 weeks depending on scope, and that investment is recovered in margins and operational resilience.

At PairProgramming we approach payment gateway integration as an orchestration layer owned by the product, not as a plugin: the company keeps control of its billing rules and can add or change providers without rewriting its backend. That same data and automation criterion is what we apply in financial vertical projects such as the miseguro.com.ar insurance quoting portal.

The cheapest gateway in the comparison is rarely the most profitable over twelve months. What moves the needle is the architecture around it.

Written by Esteban Aleart, founder & lead engineer at PairProgramming.