
If you're running finance or product for an enterprise right now, you've probably had this conversation at least once this year: should we license a payment gateway and put our logo on it, or should we build our own from the ground up? It sounds like a simple procurement question. It isn't. Payment infrastructure touches revenue, compliance, customer trust, and engineering bandwidth all at once, so the decision you make here tends to stick around for five to seven years, whether you planned for that or not.
This guide walks through the real cost structures, the hidden line items nobody puts in the pitch deck, and a practical way to figure out which path fits your business today — not the business you hope to be in three years.
The Two Paths, in Plain Terms
A white-label payment gateway is a payment processing platform that already exists, already has its compliance certifications sorted, and already works. A provider builds and maintains the core engine — the routing logic, the fraud checks, the acquirer connections — and you license it, put your brand on the checkout page, and go live in weeks instead of months. You're not buying a black box exactly; you get some room to configure flows, add payment methods, and adjust the UI. But the underlying plumbing belongs to someone else.
A custom-built payment gateway means your engineering team (or a development partner working under your direction) designs the entire stack from the transaction schema up: how payments are authorised, how you connect to acquiring banks, how fraud rules are written, how PCI DSS scope is handled, how settlement and reconciliation work. Nothing is inherited. Everything is built to match your specific transaction patterns, your specific markets, and your specific risk appetite.
Neither option is "better." They solve different problems at different stages of a business's life, and the mistake most teams make is comparing them as if they're the same category of purchase.
What It Actually Costs to Go White-Label
The upfront cost of a white-label gateway is deliberately low — that's the whole pitch. Most providers charge a setup or configuration fee, then move you onto a recurring model built around monthly infrastructure fees plus a per-transaction charge.
Here's roughly how that breaks down for a mid-to-large enterprise:
| Cost Component | Typical Range |
| Initial configuration/setup fee | ₹40,000 – ₹4,00,000 (roughly $500 – $5,000) |
| Monthly infrastructure/platform fee | ₹15,000 – ₹1,50,000 per month |
| Per-transaction fee | 0.5% – 2.5% of transaction value, sometimes plus a flat fee |
| Compliance/PCI overhead passed to you | Usually bundled, occasionally billed separately |
| Customisation (UI, checkout flow, branding) | ₹1,00,000 – ₹8,00,000 depending on depth |
The appeal is obvious: you can live and process real transactions within four to eight weeks. You're not hiring a compliance officer, you're not negotiating directly with acquiring banks, and you're not carrying the operational risk of a platform outage on your own engineering team's shoulders.
The catch is that the per-transaction fee scales with your volume forever. At low-to-medium volumes, that's a fair trade — you'd never recoup a custom build at that scale anyway. But as transaction volume climbs, that percentage-based fee starts compounding into real money, and unlike a fixed engineering cost, it never plateaus.
What It Actually Costs to Build Custom
A custom gateway inverts the cost curve entirely. You pay a large amount upfront and comparatively little per transaction afterward.
| Cost Component | Typical Range |
| Core build (architecture, APIs, ledger, reconciliation) | ₹40,00,000 – ₹3,00,00,000+ (roughly $50,000 – $400,000+) |
| PCI DSS certification and audit | ₹8,00,000 – ₹40,00,000, recurring annually |
| Acquirer/bank integration work | ₹5,00,000 – ₹30,00,000 per acquirer relationship |
| Fraud detection and risk engine | ₹10,00,000 – ₹60,00,000 |
| Ongoing maintenance and engineering team | 15–25% of build cost, annually |
| Timeline | 14 to 40 weeks, longer for multi-market builds |
Once built, the marginal cost of processing one more transaction is close to zero — you're mostly paying interchange and acquirer fees, not a markup layered on top by a gateway provider. That's the entire economic argument for going custom: at sufficient volume, owning the infrastructure is cheaper per transaction than renting it, even after accounting for the maintenance burden.
But "sufficient volume" is doing a lot of work in that sentence, and it's the part most vendor pitches gloss over.
Where the Two Curves Cross
This is the number that actually matters, and it's specific to your business, not a generic industry rule of thumb. For India-focused businesses processing card and UPI transactions, the practical crossover tends to sit somewhere around ₹50–75 lakh in monthly transaction volume. Below that, the percentage-based fees on a white-label platform are smaller in absolute terms than the annualised cost of building and maintaining your own infrastructure. Above it, the math flips, and the savings from owning your stack start to outpace what you're paying a third party in transaction fees — typically somewhere in the first two years after volume clears that threshold.
A few things shift that crossover point earlier or later:
- Multiple payment methods and geographies push the custom build cost up front, delaying the point where it pays off.
- A high concentration of large-ticket transactions (as in real estate, B2B invoicing, or high-value retail) means even modest transaction counts generate meaningful fee savings, pulling the crossover point earlier.
- Regulatory complexity operating across multiple jurisdictions with different compliance regimes tends to make custom builds more expensive to maintain than the spreadsheet suggests, because compliance isn't a one-time cost, it's a standing team.
If you're nowhere near that volume yet, a custom build is very likely the wrong call regardless of how appealing full control sounds in a strategy meeting.
The Hybrid Path Most Enterprises Actually End Up On
In practice, a clean binary choice is rarer than the framing suggests. A common middle path is to license the core processing engine the part that's genuinely commoditised, like PCI-certified card handling and acquirer connectivity while building custom orchestration on top: routing logic tailored to your approval rate history, fraud rules specific to your customer base, and reconciliation that plugs directly into your existing finance systems.
This hybrid approach keeps the heaviest compliance burden with a certified provider while giving you control over the parts of the payment experience that actually differentiate your business checkout conversion, approval rates, and how payment data feeds into your broader operations. It costs more than a pure white-label setup and less than a full custom build, and for a lot of mid-to-large enterprises sitting just below or just above the crossover point, it's the more sensible answer than either extreme.
A Practical Way to Decide
Rather than starting with "white-label or custom" it helps to answer four questions first:
- What's your current and projected monthly transaction volume, honestly? Not the number in the pitch deck for investors — the number your finance team would sign off on.
- How many markets and payment methods do you need to support in the next 18 months? Every additional market adds compliance and integration complexity that compounds faster in a custom build than in a white-label one.
- Do you have, or can you hire and retain, a team capable of owning PCI DSS compliance long-term? This is a yes/no question with real consequences either way not a "we'll figure it out" answer.
- Is payment experience actually a point of competitive differentiation for your business, or is it infrastructure you'd rather not think about? If customers choose you for something other than checkout experience, renting proven infrastructure is usually the more rational allocation of engineering effort.
Answer those four honestly, and the white-label-versus-custom decision mostly makes itself. The businesses that get this wrong tend to fall into one of two traps: scaling teams overbuild bespoke infrastructure before their volume justifies it, chasing control they don't yet need, or growing enterprises stay on a percentage-based white-label model well past the point where it's the cheaper option, simply because switching feels riskier than staying put.
Payment infrastructure is one of the few technical decisions that shows up directly on both your P&L and your risk register. It deserves a decision process that treats it that way grounded in your actual volume, your actual compliance capacity, and a realistic three-year view, rather than whichever option was easiest to greenlight this quarter.
Common Questions Worth Settling Early
Does a white-label gateway limit how much I can customize the checkout experience? Less than most teams assume. Branding, layout, field order, and payment method sequencing are usually fully configurable. What's off-limits is the underlying transaction logic routing rules, fraud thresholds, and settlement mechanics stay with the provider unless you're on an enterprise tier that explicitly opens those up
What's the single biggest cost teams underestimate in a custom build? Not the initial build the ongoing compliance and maintenance tail. Card network rule changes, new payment method support, and annual PCI DSS re-certification all require a standing team long after the "project" is technically finished. Businesses that budget only for the build, not the years of upkeep after it, are the ones most likely to regret going custom.
Whichever path you take, the decision holds up better when it's revisited on a schedule annually at minimum rather than treated as a one-time choice made at launch and never reconsidered as volume, markets, and risk exposure change.
Sign in to leave a comment.