What It Costs to Build a Payment Gateway
What It Costs to Build a Payment Gateway
If you are pricing a payment gateway build, you are probably stuck between two useless answers: a round number someone pulled from a blog, or "it depends" with no structure.
This post gives you cost bands by scope, the variables that actually move the number, and a way to turn your situation into a brief vendors can price against. It is written for founders, product owners, and CTOs who have already decided payments are product-critical — not for merchants shopping for a hosted checkout button.
What "gateway" means (before you price anything)
People say "payment gateway" for three different products. Mixing them is how quotes jump by an order of magnitude.
1. Aggregator / connector layer
One API in front of existing processors, wallets, or banking apps. You own merchant onboarding UX, method selection, webhooks, and reconciliation into your ledger. You do not become the money mover of record for every rail.
2. Multi-rail acceptance product
Same as above, plus first-class support for several rails (cards, wallets, bank apps), method-specific failure modes, sandboxes per rail, and ops tooling so support can answer "where is the money?" without pinging engineering.
3. Settlement-ready platform
Everything above, plus payouts to merchant bank accounts, settlement cycles, dispute / reversal handling, stronger KYC/AML hooks, and the reporting finance will not ship without.
If you only need "accept Bankily + Sedad behind one SDK," you are closer to (1)–(2). If you need "we are the settlement layer for every merchant in this market," you are in (3). Price the product you are actually building.
Cost bands by scope
These are planning bands for a competent product engineering team shipping production software — not agency day rates, not "hire three freelancers for a weekend." Currency is USD. Local labour markets move the floor; regulated markets and sparse bank docs move the ceiling.
MVP connector — roughly $40k–$120k
In scope: one or two rails, create payment → collect → webhook → mark paid, basic dashboard, sandbox for happy paths, merchant API keys.
Out of scope: multi-rail parity, automatic settlement, dispute workflows, multi-entity KYC, fancy reconciliation.
When it is honest: you already have bank/PSP contracts (or a clear path), docs are usable, and you can launch with manual ops for edge cases.
When it is a lie: the banks have no public API, every merchant needs a custom agreement, or finance expects settlement reports on day one.
Multi-rail gateway — roughly $120k–$350k
In scope: several methods behind one API, SDKs for the surfaces your merchants actually use, hosted or embedded checkout, webhooks you can trust, sandbox that covers failure modes, merchant dashboard with enough ops to support real volume.
Out of scope: becoming a full processor, building card network connectivity from scratch, or replacing your bank's core.
Shape we have shipped: Moosyl sits here — six Mauritanian banking apps behind one API, SDKs, checkout sessions, webhooks, sandbox, merchant dashboard, settlements to merchant bank accounts in 1–3 business days. That scope is not an MVP connector and it is not "build Visa."
Settlement + reconciliation platform — roughly $350k–$1M+
In scope: payouts, settlement calendars, ledger discipline, dispute/reversal paths, audit trails, role-based ops, reporting finance will sign off on, and the integration work with banks that never published a clean OpenAPI file.
Out of scope for most teams: inventing a new card scheme, or licensing yourself as a bank.
Past ~$1M you are usually funding ongoing product + compliance ops, not a single "build the gateway" project.
What drives the price (the variables that matter)
Ignore vanity stack choices. These are the levers:
Bank / PSP access and documentation.
A clean sandbox with test credentials is cheap. Six undocumented wallet APIs with WhatsApp support channels is expensive. Expect discovery time, brittle certification, and "the field means something else on Fridays."
Number of rails and parity.
Each new method is not +10% — it is another failure taxonomy, another reconciliation shape, another support playbook. Partial parity (launch with two methods, add the rest) is often the only sane plan.
KYC, onboarding, and who holds risk.
If merchants can self-serve with light checks, cost stays in product. If every merchant needs bank-side approval or you sit in the middle of funds flow, budget for ops and compliance design — not just screens.
Disputes, reversals, and idempotency.
Happy-path checkout is the brochure. Double charges, partial failures, and "customer paid but webhook never arrived" are the product. Build for that early or pay for it in war rooms later.
Settlement and finance reporting.
"Money hits our account somehow" is not a settlement product. If finance needs cycles, exports, and unmatched-transaction queues, put it in the brief before you ask for a quote.
SDK and merchant DX.
An API only merchants' senior engineers can use will not get adopted. Time-to-first-successful-payment for a mid-level mobile or web engineer is a real cost driver (docs, examples, error messages that teach).
Ops after go-live.
Dashboards, roles, audit logs, and support tooling are not polish. They are how you avoid hiring an engineer for every merchant ticket.
Soft proof: what a real multi-rail build looks like
On Moosyl we built the gateway end to end for a market where cash still dominates and each banking app shipped its own API with almost no documentation. The product job was simple to say and expensive to fake: one integration for merchants, six rails underneath, webhooks and sandbox included, settlements to merchant bank accounts.
Public shape, not a fake quote: 10K+ transactions, 99.9% uptime, six banking apps through one API. Use that as a calibration for "multi-rail in a hard documentation environment" — not as your budget.
If your market has Stripe-like rails and clean docs, your connector MVP can land near the bottom of the first band. If your market looks more like Moosyl's, plan for the middle band even when the pitch deck says "MVP."
DIY vs studio vs buying a processor
| Path | When it fits | What you still own |
|---|---|---|
| Buy a global processor (Stripe-class) | Your market and methods are already covered | Product UX, edge-case ops, anything the processor does not settle locally |
| DIY with your team | You have senior payment engineers and months of focus | Everything — including the opportunity cost of not shipping the rest of the product |
| Product studio / specialist team | Payments are critical but not your only roadmap | Product decisions, bank relationships, compliance posture — the studio should not "own" those by accident |
Building a gateway because "processors take 2%" is usually the wrong reason. Building one because no processor covers your rails — or because the aggregator is the product — is the right reason.
Get a real number (not another blog band)
Bands are for planning. Quotes need a brief.
Download the integration scoping template. Fill the same fields for every vendor: identity and rails, current state, data and triggers, failure modes, definition of done. Comparable inputs beat three sales calls that describe three different products.
If you already have a concrete integration plan (methods, environments, settlement rules) and want it de-risked on paper, use the architecture review instead — written feedback on one plan, not a discovery call.
Either way: price the gateway you are actually building, not the word on the slide.