The build vs buy payment gateway decision depends on processing volume, control needs, and margin economics. Third-party gateways are the right choice below $1M in monthly volume, fast to deploy, PCI DSS compliant, and vendor-maintained. Between $1M and $20M per month, white-label and orchestration-layer solutions offer branded checkout and multi-PSP routing without a full build. Custom payment gateway development becomes cost-effective above $20M in monthly volume, where per-transaction fee savings offset build and maintenance costs, or when checkout flows, routing rules, or regulatory coverage exceed what any API supports.
The payment stack that got a platform to $10M in monthly volume produces a different economics problem at $50M — and that’s when the build or buy question stops being hypothetical. Deloitte’s research on the payment processing industry found that merchant acquiring margins have compressed by 30% over the past five years, and processing fees in the US now often exceed 2% per transaction. Run that rate against $50M in annual transaction volume and the fee line alone clears $1M a year — the number that turns this from an engineering curiosity into a finance conversation for mid-sized and enterprise teams in FinTech, insurance, legal, healthcare, eCommerce, and manufacturing industries, and other regulated or data-intensive businesses.
Most guides that claim to answer this question just warn that building is complex. That’s not a framework — it’s not useful to a CTO who already knows building a payment platform is complex. ACI Worldwide’s 2026 payments predictions put it plainly: intelligent orchestration is becoming a competitive requirement as new payment methods multiply across channels. That’s why the real decision isn’t binary — third-party gateway, build payment gateway, and orchestration layer are three distinct paths, and treating the third as an afterthought is how teams choose wrong.
Getting this call wrong is expensive to reverse — a custom build abandoned mid-project can cost a year or more of engineering time to unwind, and by the time PCI DSS v4.0.1 became the only version the PCI Security Standards Council supports, most teams learned compliance scope isn’t something you retrofit cheaply after the architecture decision is made.
Here’s the payment solution framework: the volume and margin thresholds that separate buy, build, and hybrid; a key components breakdown of what building actually requires; a cost and timeline model; and the compliance architecture that has to be designed in from day one.
Why the Build vs Buy Payment Gateway Decision Is Harder Than It Looks
Building a payment gateway is sophisticated, but manageable once you know what you’re building — the hard part is knowing which components you need, what each costs to build and maintain, and what your PCI scope looks like under each path. Skip that step, and teams tend to fail one of two ways: sticking with a third party solution long past the point where fees exceed what building would’ve cost, or starting an in-house payment gateway without scoping the full component list and PCI implications, ending up with a half-finished custom platform that costs more to abandon than finish.
Underneath both failures is the same blind spot — a fee stack that compounds quietly. U.S. merchants paid a record $198.25 billion in card processing fees in 2025, and that total is built from three stacked layers — interchange, network assessment fees, and processor markup — plus the monthly platform charges, currency conversion markup, and chargeback fees layered on top, none of which look large individually as additional costs.
The Three Signals That Mean the Existing Gateway Has Become a Constraint
The first signal is margin. Once processing fees as a share of revenue cross the point where a three-year development costs comparison favors building, the math has already shifted even if nobody’s run it yet. For most companies that inflection surfaces somewhere between $10M and $50M in annual payment processing volume, depending on average transaction size and the fee structure negotiated at signup.
The second is product. When the roadmap includes custom checkout flows, transaction routing logic across multiple providers, white-label payment experiences, or coverage for multiple payment methods in markets the current provider handles poorly, the constraint isn’t cost — it’s that the API was never designed to do what the product now needs.
The third is compliance or control. When PCI DSS scope, local regulations, data residency requirements, or the need to own payment stack data for fraud modeling and reporting start conflicting with how a third-party gateway is architected, no amount of configuration will resolve it. At that point the gateway isn’t a vendor choice — it’s an architectural mismatch.
Why “Build vs Buy” Is Usually the Wrong Frame
Most companies that say they’re building a payment gateway system aren’t building one from scratch. They’re building an orchestration layer on top of existing provider APIs, or building specific components — routing, tokenization, reconciliation — while leaving the rest, like acquiring relationships and scheme certification, to providers who already do it well.
Andrii Semitkin
Delivery Director at SPD Technology
“The real question isn’t whether to build a gateway — it’s which components of the payment stack you own versus outsource. That decides your scope, your cost, and your timeline. For nearly everyone who reaches this point, it’s never all or nothing.”
Decision Framework: When to Stay With a Third-Party Gateway
For most companies, staying on a third-party gateway is the right call — not a compromise, not something to eventually outgrow. The table below shows when buying beats building.
Signal | Threshold | Why Third-Party Wins Here |
|---|---|---|
Annual processing volume | < $10M–$20M | Processing fees are lower than the engineering cost of building and maintaining equivalent infrastructure |
Engineering team size | < 5 dedicated payments engineers | Custom gateway development requires sustained payments engineering capacity; most product teams don’t have it |
Time-to-market requirement | < 6 months to production | Third-party gateways integrate in days to weeks; custom development requires 9–18 months minimum for production-grade scope |
Payment method coverage | Standard card payments in 1–3 major markets | Third-party providers offer global payment method coverage (local bank transfers, wallets, BNPL) built and maintained by the vendor |
PCI DSS posture | Prefer minimal PCI scope | Third-party gateways reduce PCI scope to SAQ A or SAQ A-EP; custom gateways require full PCI DSS Level 1 or Level 2 assessment |
Product customization need | Standard checkout flows, no white-label requirement | Third-party APIs handle standard payment flows; custom requirements are an indicator to build, not a reason to rule out buy |
Signal
Annual processing volume
Engineering team size
Time-to-market requirement
Payment method coverage
PCI DSS posture
Product customization need
Threshold
< $10M–$20M
< 5 dedicated payments engineers
< 6 months to production
Standard card payments in 1–3 major markets
Prefer minimal PCI scope
Standard checkout flows, no white-label requirement
Why Third-Party Wins Here
Processing fees are lower than the engineering cost of building and maintaining equivalent infrastructure
Custom gateway development requires sustained payments engineering capacity; most product teams don’t have it
Third-party gateways integrate in days to weeks; custom development requires 9–18 months minimum for production-grade scope
Third-party providers offer global payment method coverage (local bank transfers, wallets, BNPL) built and maintained by the vendor
Third-party gateways reduce PCI scope to SAQ A or SAQ A-EP; custom gateways require full PCI DSS Level 1 or Level 2 assessment
Third-party APIs handle standard payment flows; custom requirements are an indicator to build, not a reason to rule out buy
What third-party gateways provide isn’t just speed — it’s infrastructure that would take years to replicate even with unlimited substantial investment. Global payment method coverage across dozens of markets, PCI DSS compliance handled at the vendor level, fraud detection systems that benefit from network effects across the provider’s entire merchant base rather than just one company’s transaction history, continuous regulatory updates as card scheme rules and local regulations shift, and 24/7 uptime management that doesn’t depend on one team’s on-call rotation.
In house development doesn’t just cost engineering time and significant resources — it means competing with providers who have spent a decade and hundreds of millions of dollars on exactly this problem, which is why for most companies at this stage, the higher-leverage move is investing in payment gateway integration rather than replacing the payment systems underneath it.
Stripe wins on developer experience, Adyen on its single-platform reach across acquiring and risk, Braintree on PayPal/Venmo integration, Checkout.com on enterprise acquiring in EMEA/APAC, Worldpay on omnichannel digital payments coverage.
Meet most of these criteria? The decision’s closed. Next up: what happens when volume, business requirements, or compliance push past these thresholds.
Decision Framework: When Custom Payment Gateway Development Makes Sense
The signals pointing toward custom are specific and measurable — this isn’t about ambition; it’s about complete control and lower total cost at your actual volume and business requirements.
Signal | Threshold | Why Custom Wins Here |
|---|---|---|
Annual processing volume | > $50M (card-present) or > $100M (card-not-present) | At scale, direct acquiring relationships and interchange optimization reduce effective processing costs below third-party gateway fees |
Processing fee as % of revenue | > 1.5–2% blended effective rate | Custom gateway + direct acquiring typically achieves 0.1–0.5% effective rate at scale; the delta funds the build cost in 12–24 months |
Product differentiation requirement | Custom checkout UX, white-label payments, embedded finance features | Gateway APIs impose UX and flow constraints; custom development removes them entirely |
Multi-provider routing requirement | Need to route between 3+ acquirers or gateway providers based on cost, success rate, or geography | Custom orchestration layer provides routing logic that no single third-party gateway will optimize for you |
Data ownership requirement | Need full transaction data for fraud modeling, reporting, or regulatory purposes | Third-party gateways limit access to raw transaction data; custom gateways own the data layer completely |
Geographic or regulatory requirement | Markets where existing providers have poor coverage, high fees, or licensing gaps | Custom gateway enables direct relationships with local acquirers and payment schemes in markets where third-party coverage is thin |
Signal
Annual processing volume
Processing fee as % of revenue
Product differentiation requirement
Multi-provider routing requirement
Data ownership requirement
Geographic or regulatory requirement
Threshold
> $50M (card-present) or > $100M (card-not-present)
> 1.5–2% blended effective rate
Custom checkout UX, white-label payments, embedded finance features
Need to route between 3+ acquirers or gateway providers based on cost, success rate, or geography
Need full transaction data for fraud modeling, reporting, or regulatory purposes
Markets where existing providers have poor coverage, high fees, or licensing gaps
Why Custom Wins Here
At scale, direct acquiring relationships and interchange optimization reduce effective processing costs below third-party gateway fees
Custom gateway + direct acquiring typically achieves 0.1–0.5% effective rate at scale; the delta funds the build cost in 12–24 months
Gateway APIs impose UX and flow constraints; custom development removes them entirely
Custom orchestration layer provides routing logic that no single third-party gateway will optimize for you
Third-party gateways limit access to raw transaction data; custom gateways own the data layer completely
Custom gateway enables direct relationships with local acquirers and payment schemes in markets where third-party coverage is thin
Custom buys control no API offers: routing tuned to your own data, a vault you own payment gateway system-wide, settlement built around your ledger, white-label checkout with no vendor constraints, fraud detection systems trained on your own history instead of a shared pool, and direct acquiring for better rates than any markup gives you.
What Custom Payment Gateway Development Actually Requires
The core pieces: an API layer, tokenization vault, routing engine, authorization/capture flow, and settlement engine. On top: compliance (PCI DSS, 3DS2, AML/KYC, EMV) plus operations — monitoring, fraud detection, chargebacks, and 24/7 ongoing support.
This isn’t one software development project, it’s a set of infrastructure investments best scoped individually. Most companies end up building some components and integrating the rest via API integration with third-party providers. The real skill is knowing which ones are worth owning as part of your own solution.
The True Cost Model for Custom Payment Gateway Development
Initial build typically runs $500K–$2M for a production-grade gateway with core components, depending on scope.
See our full breakdown in How Much Does It Cost to Build a Payment Gateway.
Ongoing maintenance needs 2–4 dedicated payments engineers, roughly $300K–$600K a year fully loaded. Compliance adds a PCI DSS Level 1 QSA assessment ($50K–$200K/year) plus penetration security testing.
Andrii Semitkin
Delivery Director at SPD Technology
“Break-even usually lands at $50M–$100M in annual processing volume, depending on your current effective rate and build scope — and accelerates meaningfully if direct acquiring relationships come with the build. These are planning ranges, not a quote; actual numbers depend on scope, team structure, and what you can negotiate with acquirers.”
The Hybrid Path: Payments Orchestration and What Most Companies Actually Build
Most companies that say they’re “building a payment gateway” are actually building something narrower: a payments orchestration layer. This is a custom layer that sits between the product and multiple gateway or acquirer providers, handling routing, failover, token management, and reconciliation — without replacing the underlying gateway infrastructure itself. It’s often the highest-ROI path available, and it’s the one competitor content skips entirely.
The math explains why: orchestration captures 60–70% of what a full own payment gateway delivers, at 20–30% of the cost and timeline.
Path | What It Is | Best For | Build Timeline | Relative Cost |
|---|---|---|---|---|
Third-party gateway | Full outsourcing: Stripe, Adyen, Braintree handle authorization, tokenization, settlement | < $20M processing volume; standard payment flows; minimal PCI scope preferred | Days to weeks | Lowest upfront; highest per-transaction cost at scale |
Payments orchestration layer | Custom routing and management layer over 2+ third-party gateways; own the logic, not the infrastructure | $20M–$100M volume; need routing optimization, multi-provider redundancy, unified data layer | 3–6 months | Medium upfront; materially lower effective rate through routing optimization |
Custom payment gateway | Full ownership: custom authorization flow, tokenization vault, direct acquiring relationships, settlement engine | > $100M volume; white-label requirement; direct acquiring economics; full data ownership | 12–24 months | Highest upfront; lowest per-transaction cost at scale; full control |
Path
Third-party gateway
Payments orchestration layer
Custom payment gateway
What It Is
Full outsourcing: Stripe, Adyen, Braintree handle authorization, tokenization, settlement
Custom routing and management layer over 2+ third-party gateways; own the logic, not the infrastructure
Full ownership: custom authorization flow, tokenization vault, direct acquiring relationships, settlement engine
Best For
< $20M processing volume; standard payment flows; minimal PCI scope preferred
$20M–$100M volume; need routing optimization, multi-provider redundancy, unified data layer
> $100M volume; white-label requirement; direct acquiring economics; full data ownership
Build Timeline
Days to weeks
3–6 months
12–24 months
Relative Cost
Lowest upfront; highest per-transaction cost at scale
Medium upfront; materially lower effective rate through routing optimization
Highest upfront; lowest per-transaction cost at scale; full control
Three patterns make up most orchestration builds. Multi-gateway routing sends transactions to Stripe, Adyen, or Checkout.com based on success rate, cost, or geography rather than a single hardcoded integration. Smart retry logic catches a failed transaction and automatically retries it on a secondary provider before the customer sees a decline. Unified tokenization maintains a single token vault across providers, so a returning customer’s card-on-file works no matter which provider ultimately processes the transaction process.
Orchestration rarely stays the end state for companies still scaling — it’s step one in a longer sequence: orchestration, then direct acquiring for the biggest corridors, then a custom vault, then a full gateway where it’s actually justified. Most scale-stage companies work through that sequence rather than jumping straight to a full build, especially given the fast-paced shift in the payment gateway market.
When to Build the Orchestration Layer First
Orchestration is the right first move when online transactions volume sits between $20M and $100M — large enough that the current fee structure hurts, too early to justify a full gateway build. It’s also right when the product needs multi-provider redundancy or routing optimization no single gateway offers, or when the team needs to build internal technical expertise before taking on full gateway ownership.
Built well, an orchestration layer routes high-payment performance traffic to a primary provider and fails over automatically to a secondary, optimizes routing by payment method, geography, or time of day, maintains a unified token vault across providers, and produces one reporting layer across all payment flows instead of several disconnected ones.
What it doesn’t replace: the underlying gateway infrastructure — authorization and settlement still run through third-party providers — PCI-compliant handling of sensitive data, which stays in third-party scope, and the economics of direct acquiring, which requires its own licensing and relationships.
Companies that skip orchestration and jump straight to a full gateway build tend to underestimate both the compliance scope and the timeline. Starting with orchestration buys 12–18 months to build payments engineering depth before taking on PCI Level 1 certification and direct acquiring relationships — a much cheaper place to learn that lesson.
Component Breakdown: What a Custom Payment Gateway Actually Includes
Building a payment gateway means owning five distinct systems, each with its own design decisions, compliance implications, and failure modes — not one monolithic engineering project, and the sequence in which you tackle them matters as much as the components themselves, a distinction covered in more depth in how to build a payment gateway.
The Payment API Layer
The payment API takes in requests, validates them, runs fraud checks, and routes them to the processing engine. Two things matter most: sub-100ms response time, since checkout latency kills conversion, and idempotency keys, so a retry doesn’t quietly double-charge someone.
Security layers on top — TLS 1.3, input validation, rate limits, signed webhooks. Miss the idempotency piece, and you’ve built one of payments’ costliest bugs: a retry nobody flags as a duplicate, a double charge, a support ticket, a chargeback, and a customer who doesn’t trust you anymore — all from one gap.
Tokenization and PCI DSS Scope
Tokenization replaces raw card data — the PAN, CVV, and expiry — with a non-sensitive token that can be stored and transmitted safely, while a token vault holds the mapping between token and payment details inside a PCI-compliant boundary. There are two ways to approach this. Building a custom token vault gives complete control but carries maximum PCI scope, requiring PCI DSS Level 1 certification. Using a third-party tokenization provider — Spreedly, Basis Theory, or Stripe’s own vault — and storing only tokens dramatically reduces that scope, often down to SAQ A or SAQ D with no cardholder data environment at all.
Network tokenization adds another layer — Visa and Mastercard’s services link tokens to device and merchant, boosting authorization rates and cutting fraud, but need a scheme relationship or passthrough support. Decide on a tokenization strategy before payment gateway software development starts, or PCI Level 1 certification shows up mid-project and adds six to nine months nobody planned for.
Routing Engine and Acquirer Relationships
The routing engine picks which acquirer handles each transaction — based on card type, geography, amount, success rate, cost, whatever rules matter to you. Done well, it pays off in two ways: cheaper corridors get the lowest-cost acquirer, and tricky ones get whichever provider actually authorizes best there.
At scale — generally above $50M in a given corridor — direct acquiring relationships with Visa, Mastercard, or regional schemes eliminate the gateway markup entirely and expose interchange rates directly, though this requires either a banking license or a sponsorship arrangement with a licensed merchant account provider. Companies that route all volume through a single provider leave this value on the table: intelligent multi-acquirer transaction routing typically recovers 10–30 basis points in effective rate, which compounds fast once volume is high enough for the decision to matter in the first place.
Settlement, Reconciliation, and Reporting
Settlement moves the money — batching, acquirer submission, settlement files — and in a custom gateway, that’s on you. Reconciliation checks it: matching files against records, resolving discrepancies within an SLA.
Reporting needs real-time rates, per-acquirer settlement, chargeback monitoring (Visa and Mastercard both enforce termination thresholds), and usable finance output. Miss a settlement file for 48+ hours and it stops being small — six figures, days of cleanup, and strain on technical support.
Compliance, PCI DSS, and Security Architecture
Any system touching sensitive data falls inside PCI DSS scope — a gateway handling raw credit card payments needs Level 1 or 2 certification, part of the industry standards any serious build has to meet. Scope shrinks if you tokenize at entry so raw payment information never hits your server, or route it through a third-party tokenization provider instead. These controls belong to a broader payment gateway security architecture — designed in from the start, not bolted on after a near miss with data breaches.
Beyond PCI DSS itself, most builds also need 3DS2 for PSD2 SCA compliance in EU markets, AML/KYC workflows if the gateway handles fund flows under a PayFac model, GDPR-compliant handling for EU cardholders, and local regulatory licensing wherever payment institution rules apply — the broader environment of payment processing compliance that a build has to sit inside from day one. For the full compliance architecture — CDE scoping, tokenization design, and the audit process end to end — see SPD Technology’s payment gateway compliance and security framework.
Get all implementation details, including technical integration guidance, in our guide on how to build a payment gateway.
Build vs Buy Payment Gateway: Decision Summary at a Glance
The three paths aren’t equally likely to fit a given company, they map fairly cleanly to transaction volume and how much control over data and routing actually matters to the business.
Decision Factor | Third-Party Gateway | Payments Orchestration | Custom Gateway |
|---|---|---|---|
Best for | < $20M volume; standard flows; minimal PCI scope | $20M–$100M volume; multi-provider routing; unified data layer | > $100M volume; white-label; direct acquiring; full data ownership |
Build timeline | Days to weeks | 3–6 months | 12–24 months |
Initial investment | Low (integration cost only) | Medium ($150K–$500K) | High ($500K–$2M+) |
Annual cost | Processing fees (0.3–2.9% + fixed per transaction) | Engineering + reduced processing fees | Engineering + compliance + infrastructure; lowest per-transaction cost |
PCI DSS scope | Minimal: SAQ A or SAQ A-EP | Reduced: SAQ D without cardholder data environment | Full: PCI Level 1 or Level 2 QSA audit required |
Payment method coverage | Full: vendor-managed global coverage | Full: inherits coverage from integrated providers | Custom: only what you build and certify |
Routing control | None: single provider optimization | Full: custom logic across 2+ providers | Full: custom logic + direct acquirer relationships |
Data ownership | Limited: provider controls transaction data | Partial: own routing data, not raw transaction data | Full: complete transaction data ownership |
Key risk if wrong | Margin erosion at scale; product constraints accumulate | Underestimating orchestration complexity | PCI scope, timeline, and compliance cost overruns |
Decision Factor
Best for
Build timeline
Initial investment
Annual cost
PCI DSS scope
Payment method coverage
Routing control
Data ownership
Key risk if wrong
Third-Party Gateway
< $20M volume; standard flows; minimal PCI scope
Days to weeks
Low (integration cost only)
Processing fees (0.3–2.9% + fixed per transaction)
Minimal: SAQ A or SAQ A-EP
Full: vendor-managed global coverage
None: single provider optimization
Limited: provider controls transaction data
Margin erosion at scale; product constraints accumulate
Payments Orchestration
$20M–$100M volume; multi-provider routing; unified data layer
3–6 months
Medium ($150K–$500K)
Engineering + reduced processing fees
Reduced: SAQ D without cardholder data environment
Full: inherits coverage from integrated providers
Full: custom logic across 2+ providers
Partial: own routing data, not raw transaction data
Underestimating orchestration complexity
Custom Gateway
> $100M volume; white-label; direct acquiring; full data ownership
12–24 months
High ($500K–$2M+)
Engineering + compliance + infrastructure; lowest per-transaction cost
Full: PCI Level 1 or Level 2 QSA audit required
Custom: only what you build and certify
Full: custom logic + direct acquirer relationships
Full: complete transaction data ownership
PCI scope, timeline, and compliance cost overruns
Build vs Buy Payment Gateway: Decision Checklist
No single signal settles the decision on its own — it’s the pattern across volume, engineering capacity, and data requirements that points to one path.
✓ | Decision Signal | Points Toward |
|---|---|---|
☐ | Annual processing volume exceeds $20M | Orchestration or Custom |
☐ | Annual processing volume exceeds $100M | Custom Gateway |
☐ | Effective processing rate exceeds 1.5% blended | Orchestration or Custom |
☐ | Processing fees exceed $500K/year | Run TCO model for custom build |
☐ | Product roadmap requires custom checkout UX or white-label payments | Custom Gateway |
☐ | Product roadmap requires custom checkout UX or white-label payments | Custom Gateway |
☐ | Need to route between multiple acquirers or gateway providers | Orchestration Layer |
☐ | Expanding into markets where current provider has poor coverage or high fees | Orchestration or Custom |
☐ | Need full transaction data ownership for fraud modeling or regulatory reporting | Custom Gateway |
☐ | Current gateway API cannot support required payment methods or flows | Orchestration or Custom |
☐ | Compliance or data residency requirements make third-party data sharing problematic | Custom Gateway |
☐ | Payments engineering team has fewer than 3 dedicated engineers | Third-Party Gateway |
☐ | Time-to-production requirement is under 6 months | Third-Party Gateway |
☐ | Processing volume is below $10M annually | Third-Party Gateway |
☐ | PCI DSS Level 1 certification is not feasible within 12 months | Third-Party or Orchestration |
☐ | Need 24/7 vendor-managed uptime without internal on-call capability | Third-Party Gateway |
☐ | Direct acquiring relationship established or in progress | Custom Gateway ready |
✓
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
Decision Signal
Annual processing volume exceeds $20M
Annual processing volume exceeds $100M
Effective processing rate exceeds 1.5% blended
Processing fees exceed $500K/year
Product roadmap requires custom checkout UX or white-label payments
Product roadmap requires custom checkout UX or white-label payments
Need to route between multiple acquirers or gateway providers
Expanding into markets where current provider has poor coverage or high fees
Need full transaction data ownership for fraud modeling or regulatory reporting
Current gateway API cannot support required payment methods or flows
Compliance or data residency requirements make third-party data sharing problematic
Payments engineering team has fewer than 3 dedicated engineers
Time-to-production requirement is under 6 months
Processing volume is below $10M annually
PCI DSS Level 1 certification is not feasible within 12 months
Need 24/7 vendor-managed uptime without internal on-call capability
Direct acquiring relationship established or in progress
Points Toward
Orchestration or Custom
Custom Gateway
Orchestration or Custom
Run TCO model for custom build
Custom Gateway
Custom Gateway
Orchestration Layer
Orchestration or Custom
Custom Gateway
Orchestration or Custom
Custom Gateway
Third-Party Gateway
Third-Party Gateway
Third-Party Gateway
Third-Party or Orchestration
Third-Party Gateway
Custom Gateway ready
Three or more boxes clustered on orchestration or custom? Start running the TCO model — the checklist already told you what you need to know. Land on third-party instead, and the honest move is staying put; deeper integration with your current provider beats a build you don’t actually need.
Two or more pointing specifically at a full custom gateway means one thing: open a PCI scope assessment now. It’s the longest lead-time item in the whole build, so it’s the one that can’t wait.
Key Takeaways
- Third-party gateways win below $10M–$20M in annual volume; custom development turns cost-positive once fees pass the 3-year build cost, usually somewhere between $50M–$100M.
- The real cost isn’t the headline rate — it’s the blended rate, stacking per-transaction fees, currency markup, and chargeback fees, and watching subscription cost alone misses most of the bill.
- Most companies that say they’re “building a payment gateway” are actually building a payments orchestration layer over two or more third-party providers, capturing 60–70% of a custom gateway’s value at 20–30% of the build cost.
- PCI DSS scope is the most underestimated cost and timeline factor in custom builds: any system storing, processing, or transmitting raw card data requires PCI Level 1 or Level 2 certification, adding 6–9 months and $100K–$200K a year.
- Tokenization architecture must be decided before the first line of gateway code is written, since retrofitting it after development starts is what turns a scoped project into a blown timeline.
- Smart routing across acquirers typically saves 10–30 basis points, enough to fund an orchestration build within 12–18 months at $50M+ volume.
- The escalation path from buy to custom is predictable and sequential — orchestration layer, then direct acquiring for high-volume corridors, then a custom tokenization vault, then a full gateway for specific flows — and skipping steps is how many businesses overbuild too early.
FAQ
What is the difference between building and buying a payment gateway?
Buying a payment gateway means integrating a third-party provider — Stripe, Adyen, Braintree, Checkout.com — that handles card authorization, tokenization, settlement, and compliance infrastructure. Building a secure payment gateway in-house means owning some or all of those components yourself: the API layer, routing engine, tokenization vault, and settlement engine.
The practical difference at scale is full control versus cost: third-party gateways are faster and simpler but carry per-transaction fees that become material at high transaction volumes, while custom gateways demand more investment but deliver lower effective processing rates, full data ownership, and product differentiation no API can match. Most production systems at scale land on a hybrid — custom orchestration or specific custom components layered over third-party infrastructure.
When does it make sense to build a custom payment gateway?
Three signals indicate custom development has become defensible, based on your business model and business needs. Annual processing volume has crossed $50M–$100M, and the gap between current processing fees and a direct acquiring relationship now exceeds the annual engineering cost of building.
The product roadmap needs payment experiences — white-label checkout, custom routing logic, embedded finance features — that third-party APIs simply can’t deliver. Or regulatory and data ownership requirements make third-party data sharing architecturally incompatible with the product direction. Most companies start with a payments orchestration layer before taking on a full gateway build.
How much does it cost to build a custom payment gateway?
Initial build cost for a production-grade gateway with core components — API layer, routing engine, tokenization, settlement, reconciliation — typically runs $500K–$2M depending on scope, team structure, and compliance requirements.
Ongoing cost adds 2–4 dedicated payments engineers at $300K–$600K a year plus a PCI DSS compliance program at $50K–$200K a year. Break-even against third-party processing fees usually lands between 12 and 24 months at $100M+ in annual volume, faster if direct acquiring relationships come with the build. For a full component-by-component model, discover how much does it cost to build a payment gateway.
What is a payment orchestration layer and how is it different from a custom gateway?
A payments orchestration layer is a custom routing and management layer sitting between your product and multiple third-party gateway or acquirer providers. It handles routing logic, automatic failover to a secondary provider, unified token management, and consolidated reporting — without replacing the underlying payment infrastructure.
A custom gateway goes further, owning the authorization flow, the tokenization vault, and sometimes the direct acquiring relationship itself. Orchestration captures most of the routing and data benefits of a custom gateway at a fraction of the cost and timeline, making it the right first step for most companies between $20M and $100M in annual processing volume.
What are the PCI DSS requirements for a custom payment gateway?
Any custom gateway that stores, processes, or transmits raw cardholder data falls within PCI DSS scope, requiring either Level 1 certification (above 6M transactions a year, with an annual QSA audit) or Level 2 (1–6M transactions a year).
The most effective scope reduction strategy is tokenizing card data at the point of entry — browser or mobile SDK — so raw data never reaches the gateway server. Third-party tokenization providers like Spreedly or Basis Theory can contain the cardholder data environment to a single certified service. Compliance architecture has to be defined before development starts, since retrofitting it afterward costs significantly more. See SPD Technology’s Payment Gateway Compliance and Security framework for the full picture.
How long does it take to build a custom payment gateway?
A full-scope gateway takes 12–24 months; an orchestration layer, the more common starting point, takes 3–6 months. The main drivers are PCI DSS certification (+6–9 months if handling raw card data), acquiring setup (3–6 months), and payment method/geography coverage. Skipping compliance planning to save time almost always backfires when PCI findings force rework mid-build.
What is the difference between a payment gateway and a payment processor?
A payment gateway is the technology layer that accepts payment data, validates it, and routes it to a processor or acquirer. A payment processor, or acquirer, is the financial institution that actually moves funds between the cardholder’s bank and the merchant’s bank account.
Many providers combine both functions — Stripe, Adyen, and Checkout.com act as gateway and processor in most integrations. Building a custom gateway means owning the routing and data layer while typically still relying on third-party processors or direct acquiring relationships for the funds movement itself, and direct acquiring requires a banking license or sponsorship arrangement, which is a separate and more regulated undertaking.