How to scope a fintech payment infrastructure build

A customer taps pay. The gateway authorizes the card and sends the browser back to your site, then delivers a webhook a moment later — sometimes in that order, sometimes not. Occasionally twice. Something on your side has to decide this order is now paid and record why. It has to give the same answer when the same event arrives again later. That decision and the record behind it are what a fintech payment infrastructure build consists of. The checkout page is the smallest part of it.

The expensive parts all sit after authorization. The refund that has to reach both your ledger and the customer’s statement. The renewal attempted on a card that expired in the meantime. The settlement file the bank drops in a format nobody documented. The month-end where finance asks which of two numbers is true and nobody can say.

What a fintech payment infrastructure build actually contains

A checkout that collects card details without those details reaching your servers. One adapter per gateway, so the provider’s vocabulary stops at a single file. A store of payment events in your own database, written as they happen. Handlers that are safe to run twice, because gateways redeliver. A refund and dispute path your support staff can operate without logging into a vendor dashboard. A reconciliation job that matches your orders against the settlement file and lists the mismatches instead of netting them off.

Only the first of those is visible to a customer, which is why a brief can describe the checkout in detail and leave the other five as a single line. Everything not named up front becomes a change request later, and that is why two quotes for the same payments project can differ by an amount nobody can explain to a board.

Each item on that list is a decision about who holds the data: you, or the company processing your transactions. Make those decisions deliberately and you have infrastructure. Make them one sprint at a time and you end up with a checkout that has a vendor attached to it.

Why your own payment ledger comes before the gateway choice

Write every payment event into your own tables at the moment it happens. Authorization, capture, refund, retry, dispute, payout, mandate created, mandate canceled. Keep the provider’s raw payload next to your interpretation of it, because your interpretation will be wrong about something and reprocessing from the original is the only cheap fix.

The gateway dashboard looks like it already does this, which is the reason it gets skipped. The dashboard shows the provider’s view. The question that matters at month-end is whether the provider’s view and yours agree, and you cannot compare a record against itself.

An event store also changes what a failure costs. A webhook that lands mid-deploy, a handler that throws halfway through, a payout that never arrives — each becomes a row with a status you can query and retry, rather than a gap you learn about when a customer emails. Alert on those states directly. A payout that has not confirmed by its expected date should page whoever is on call.

Why payments logic belongs behind an internal API

Payments logic gets called from more places than the checkout it was written for. A partner bank’s onboarding flow. A marketplace that wants your billing behind its checkout. An internal ops tool. A finance system that needs yesterday’s transactions in a shape it can import. An acquirer’s technical due diligence, if it comes to that.

Payments logic sitting inside your web controllers cannot be called by anything else, so the first partner integration becomes a rewrite on a deadline set outside your company. Behind an internal interface — start a payment, capture, refund, tokenize a card, open and close a subscription, translate a webhook into one of your own events — the same logic can be exposed to a partner without touching product code.

Keep that interface narrow. A universal abstraction over everything every gateway can do is its own product, and you would maintain it forever. The discipline that makes any integration between two systems survive a vendor’s roadmap applies here, with money on top: cover only the operations you actually call, and put genuinely provider-specific code in a named place. When you change providers, that named place should be the only thing that gets rewritten.

Why a UPI-first checkout and a card-first one are separate builds

A card payment is synchronous and yours to retry. A UPI collect request is asynchronous, sits pending while a human opens a banking app, and can time out without producing a failure event you can act on. Wallets have their own pending windows. Net banking hands your customer to a bank page you do not control and returns them, or does not.

Each method you add brings a state your order model has to represent and a timeout you have to choose. It also needs copy that tells the customer what to do while nothing appears to be happening. Miss that and the customer pays twice, or pays once and sees an error, and support inherits both.

A single global checkout is a false economy for this reason. The methods your buyers expect are local, and so are the failure modes. Authorization rates depend on whether you acquire locally or route a card across a border. Pick the market first and the method set second. One checkout with methods switched on per country is a reasonable target, provided the pending states were designed in from the start and not bolted on the week the second market opened.

What cross-border payments add to the build

Display currency and settlement currency are two separate fields, and conflating them is how a cross-border build starts leaking money. The customer sees a price in their currency. You receive a payout in yours, at a rate set on the day, less a spread. Your ledger has to hold both amounts and the rate used, or your revenue figures drift from your bank balance in a way nobody can reconstruct afterwards.

A refund issued long after the charge moves at a different rate than the charge did, so the amount returned to the customer and the amount leaving your account differ. Somebody has to decide who absorbs that difference. Write the answer down as a policy and have your code implement it, because the alternative is whatever the gateway happens to do by default, discovered at month-end.

Then tax. GST, VAT and US sales tax apply by jurisdiction, and the jurisdiction follows the buyer. A jurisdiction error is expensive to fix backwards: the correction is retrospective and the counterparty is a tax authority. Chargeback rules and evidence windows also vary by scheme and region, so the dispute flow you build for one market needs rechecking before you open the next.

When compliance has to be in the architecture

At the start, or at a price you will resent. An audit trail is not a report you generate later; it is an append-only record of who did what, written as they do it. Which staff member approved this refund, and against what evidence. Retrofitting that means reconstructing history from application logs that were never meant to be evidence.

Card data works the same way. Using the gateway’s hosted card fields keeps raw card numbers off your servers and your PCI scope small, and it is a structural decision you make once — after card details start flowing through your application code, the audit obligations attach to your whole stack. Card storage and tokenization rules differ by market, so ask what applies in yours before you pick a provider, and keep tokenization behind one interface so a rule change touches a single adapter.

Regulated procurement asks these questions in writing. Our fintech and banking software work starts from the assumption that it will. Write the audit record in the same database transaction as the payment record, and the questionnaire that lands later is answerable out of the database.

What a multi-currency, multi-gateway build costs

Two gateways behind one checkout is not one gateway twice. It is one gateway, plus a second, plus the layer that reconciles two providers who disagree about what a refund object contains and when a payment counts as settled. Add currencies and you add tax rules and FX handling to every report. Add split payouts to sellers who are not you and you add seller onboarding, KYC per account, a ledger per seller and a payout schedule.

A multi-currency, multi-gateway integration sits in Tier 3 of our payment gateway integration cost guide, at ₹9L – ₹18L. Marketplace and platform payments sit a tier above. Those are indicative ranges for a scoping conversation, and your own figure comes out of a paid discovery against a written scope, fixed before any code is written. On payments work an hourly bill puts the risk of a vague scope on you rather than on us, which is why we do not offer one.

Sitting on an aggregator or holding your own merchant ID moves that number and your ongoing fee load in opposite directions, and it deserves a deliberate decision rather than whichever signup was easier. Our payment aggregator versus direct gateway comparison sets out the trade-offs.

Where to start

Start with the ledger and the adapter, before you shortlist gateways. Define the payment events your business actually has and create the tables that store them under your own IDs. Every call to a provider goes behind one interface carrying the operations you know you need. Then integrate a single gateway for a single market through that interface and run real money through it. Reconcile a full month against the settlement file before you add a second method or a second country. Most of a custom payment gateway integration is that structural work. In this order it is cheap. In the other order it is a rewrite, arriving in the quarter you are trying to close a partner.