Most businesses use the terms payment gateway, payment processor, and payment orchestration platform as if they were interchangeable. They are not. Each plays a distinct role in moving money from a customer’s account to a merchant’s bank account, and the differences matter the moment your business grows beyond a single market or a single provider.
This guide explains what each one does, where the boundaries actually lie, and how to decide which combination is right for your business. By the end, you’ll be able to read any payment vendor’s marketing page and immediately identify which layers they cover and which ones they don’t.
For readers who need the short version:
The rest of this article unpacks each one in depth, shows how they interact during a real transaction, and provides a decision framework based on business stage, geography, and volume.
Before comparing the three layers, it helps to understand the underlying choreography. A typical online card transaction involves four core players, with payment orchestration sitting on top as an optional fifth layer:
| # | Player | Role |
|---|---|---|
| 1 | Cardholder (customer) | Initiates payment with card details |
| 2 | Issuing bank | Bank that issued the customer’s card and holds the funds |
| 3 | Card network | Visa, Mastercard, Amex, Discover, JCB, UnionPay, and others |
| 4 | Acquiring bank (merchant bank) | Bank that holds the merchant’s account and receives funds |
Around these four banks and networks, three commercial layers handle the technology:
When orchestration is added, the gateway and processor layers can be plural rather than singular, with the orchestration platform deciding which gateway, which processor, and which acquirer to use for each individual transaction in real time.
A payment gateway is the technology that connects a merchant’s website or app to the rest of the payment ecosystem. It does three core jobs: collect payment details at the point of sale, encrypt and tokenize that data, and pass it to a payment processor for authorization.
If you imagine the in-person equivalent, the gateway is the card reader on the counter. It captures the card information, secures it, and hands it off to the systems behind it. It does not move money. It moves information about a payment.
A modern gateway typically provides:
A gateway connects to one processor in most setups. Some larger gateways connect to several, but the merchant typically chooses one primary route and treats the others as backup. The gateway does not negotiate interchange fees, hold merchant funds, or settle transactions. It is purely a secure conduit.
Common gateways include Authorize.net, NMI, Cybersource, and Worldpay’s gateway products. Many providers brand themselves as gateways while also offering processing or acquiring services through the same parent company, which is part of why the terms get blurred in the market.
A gateway works well when a business operates in one market, processes through a single acquirer, sells primarily to card-paying customers, and has predictable transaction volumes. For a small or mid-market merchant selling domestically, a gateway plus its associated processor often delivers everything needed.
The limits show up when the business expands into new geographies, wants to add local payment methods, needs higher authorization rates, or finds itself dependent on a single provider whose outages and pricing it cannot influence.
A payment processor is the service that actually moves the authorization request through the payment networks and, after authorization, handles the settlement of funds. Where a gateway moves information, a processor moves money.
The processor sits between the gateway and the acquiring bank, with the card networks (Visa, Mastercard, and others) in the middle. When a customer’s card details arrive at the processor, the processor formats the authorization request for the relevant card network, transmits it through the network to the customer’s issuing bank, receives the approve-or-decline response, and returns that response back to the gateway. Later, during settlement (usually at end-of-day batch processing), the processor coordinates the actual movement of funds from the issuing bank through the card network to the acquiring bank, where the merchant’s account is held.
A processor’s responsibilities include:
Some processors also act as acquirers, holding the merchant account directly. Others connect to a separate acquiring bank. Stripe, Adyen, and Square are well-known examples of providers that combine processing and acquiring in a single offering, which simplifies setup at the cost of some flexibility.
Within processing, there are technically two sub-roles. Front-end processors handle the live authorization request during checkout. Back-end processors handle the batch settlement at end of day. Most modern processors do both, but in enterprise stacks, these are sometimes separated for performance and reliability reasons.
A bundled gateway-plus-processor offering, such as one from Stripe, Adyen, or a traditional acquirer, covers most needs for businesses with straightforward payment requirements. The advantages are a single integration, one contract, one support relationship, and unified reporting.
The trade-off is vendor concentration. Authorization rates are limited to whatever that single processor can deliver. Outages stop payment acceptance entirely. Adding new payment methods waits on the provider’s roadmap. Cross-border transactions go through whatever acquiring relationships the provider has, even when a local acquirer would deliver higher approval rates at lower cost. These limitations are the reason payment orchestration exists.
A payment orchestration platform sits above gateways, processors, and acquirers as a single integration layer that connects to many of them at once. The merchant integrates the orchestration platform once, and the platform handles the routing of each transaction to whichever gateway, processor, or acquirer is best suited to it.
A payment orchestration platform (POP) is a centralized payment management system that connects businesses to multiple payment service providers, acquirers, and fraud prevention tools through a single integration. Routing decisions are typically made in real time based on configurable business rules, historical performance data, cost optimization, geography, currency, and the specific payment method being used.
A modern orchestration platform typically provides:
For a deeper view of what an orchestration platform does day to day, see Gr4vy’s guide on what a payment orchestration platform is and why your business needs one.
The category includes Gr4vy, Primer, Spreedly, Yuno, IXOPAY, Cellpoint Digital, and a small number of others. Some are infrastructure-as-a-service (single-tenant, deployed per merchant), while others are software-as-a-service (multi-tenant, shared infrastructure). The architectural choice affects performance, customization, data localization, and PCI scope.
Orchestration starts paying off when a business operates across multiple geographies, processes high transaction volume, needs to support multiple payment methods (cards, wallets, BNPL, local methods), has experienced or feared a payment outage with no failover, or finds its engineering team spending significant time managing PSP integrations rather than building product. The break-even point varies, but most enterprise merchants find orchestration valuable once payment volume exceeds roughly $50M annually or once they begin operating in more than two markets.
The differences between the three layers across every dimension that matters for an enterprise decision:
| Dimension | Payment gateway | Payment processor | Payment orchestration platform |
|---|---|---|---|
| Primary function | Capture and transmit payment data | Authorize, clear, and settle transactions | Coordinate multiple gateways, processors, and providers |
| Position in flow | Front of the stack (customer-facing) | Middle of the stack | Layer above gateways and processors |
| Moves money? | No (moves information) | Yes | No (orchestrates the providers that move money) |
| Number of provider connections | Typically one processor | One acquirer (sometimes more) | Many gateways, processors, and acquirers |
| Routing intelligence | None or basic | Limited (within their own network) | Advanced, rule-based, real-time |
| Failover support | None | None (single point of failure) | Multi-provider redundancy |
| Token portability | Tokens locked to gateway | Tokens locked to processor | Provider-agnostic vault, network tokens |
| New payment method onboarding | Roadmap-dependent | Roadmap-dependent | Configuration-based, often days |
| Geographic flexibility | Limited to gateway’s coverage | Limited to acquirer’s coverage | Cross-acquirer routing, local acquiring per market |
| Cost optimization | None | Limited | Routes by acquirer cost, declines, performance |
| PCI DSS scope reduction | Some (depends on integration mode) | Some (depends on integration mode) | Significant (centralized vaulting) |
| Reporting | Single-provider view | Single-processor view | Unified across all providers |
| Authorization rate optimization | None | Within own network only | Cross-provider, intelligent routing |
| Vendor lock-in risk | High (data tied to gateway) | High (data tied to processor) | Low (designed for portability) |
| Integration complexity | Low | Low (when bundled with gateway) | Higher up-front, lower long-term |
| Best for | Single-market, lower-volume merchants | Bundled with a gateway for most merchants | Multi-market, multi-PSP, high-volume merchants |
Two more terms come up constantly in this conversation: payment service provider (PSP) and acquirer. They are not separate layers in the same sense as the three above. They are different ways of describing what a provider does.
A payment service provider is a commercial label, not a technical layer. A PSP is any company that offers payment acceptance services to merchants. In practice, a PSP usually bundles a gateway and a processor (and sometimes an acquirer) into one product. Stripe is a PSP. Adyen is a PSP. PayPal is a PSP. The category is broad and the term is used loosely.
An acquirer (or acquiring bank, merchant acquirer) is the financial institution that holds the merchant’s account and is licensed by the card networks to accept transactions on the merchant’s behalf. Acquirers are the regulated banking entity at the end of the chain. Some processors are also acquirers, some are not.
So the layers, end to end, are:
PSPs are simply commercial bundles that combine some or all of layers 1, 2, and 3 into a single offering.
If a single gateway-and-processor combination handles the full transaction flow, what does orchestration add? Five concrete improvements, each measurable in revenue or cost.
A single processor sends every transaction down the same path. When that path performs poorly for certain card BINs, regions, or customer profiles, the merchant loses those transactions. Orchestration platforms route each transaction in real time to the gateway, processor, or acquirer most likely to approve it, based on historical performance data, the card type, the geography, and the currency.
Merchants implementing orchestration-based routing typically see authorization rate improvements of 2 to 4% immediately, with 5 to 10% gains as rules are refined over time. For cross-border transactions specifically, routing through a local acquirer can deliver up to 16% higher acceptance than the same transaction sent through a single foreign processor. For a deeper view of this layer, see intelligent payment routing.
Every payment provider has outages. When a single-PSP merchant’s provider goes down, payment acceptance stops entirely until service is restored. Orchestration platforms automatically reroute transactions to alternative providers during outages, with no customer-facing disruption.
This is no longer a niche concern. Payment outages have been estimated to cost businesses tens of billions of dollars annually in lost sales, and that figure excludes the engineering hours spent on emergency fixes and the damage to customer trust.
When a merchant stores cards with a single processor, those tokens only work within that processor’s system. Switching providers means re-collecting card data from every customer, which is operationally costly and often impossible at scale.
Orchestration platforms maintain a provider-agnostic vault. Tokens can be used across any connected processor, and network tokens (issued by Visa, Mastercard, and other schemes) update automatically when underlying cards are reissued or expire. The merchant owns its payment data, not the provider.
Adding a new payment method through a traditional gateway or processor depends on the provider’s product roadmap. The merchant waits for the provider to support Apple Pay, then PIX, then iDEAL, then BNPL, often for months. Through orchestration, new methods can typically be added in days through configuration rather than custom development, because the orchestration platform already maintains the integrations.
A range of alternative payment methods including wallets, BNPL, and local schemes becomes available with the flip of a switch rather than a development project.
Each system that stores, processes, or transmits cardholder data falls under PCI DSS audit scope. Traditional architectures with multiple gateway and processor integrations multiply this scope across every connected system. Centralizing payment data through an orchestration platform with a single vault and a single set of API controls dramatically reduces the merchant’s PCI footprint, often by 70% or more, depending on the architecture before migration. For more on this, see Gr4vy’s analysis of PCI DSS compliance and payment orchestration.
The right answer depends on a small number of business characteristics. The following framework cuts through the marketing noise:
For a closer look at the strategic case, our analysis of how to increase payment approval rates in 2026 walks through the specific levers orchestration unlocks.
A few persistent myths get in the way of clear decisions.
“My PSP already does orchestration.” Most PSPs route transactions only within their own network. True orchestration means routing across competing providers, which a single-PSP architecture cannot do. If your “orchestration” feature stops at your provider’s borders, it is not orchestration.
“Orchestration is just another middleman that adds cost.” Orchestration platforms charge a small per-transaction fee, but the authorization rate lift, cost optimization through smart routing, and operational savings typically exceed that fee by multiples. For enterprise volume, the ROI is usually visible within the first quarter of operation.
“I can build orchestration in-house.” Some merchants do, but the engineering effort is significant. A functional in-house orchestration layer requires multi-PSP integrations, a provider-agnostic vault, a rules engine, network token management, failover logic, reconciliation across providers, fraud orchestration, PCI DSS compliance for the vault, and ongoing maintenance as each underlying provider’s API evolves. Most teams that estimate the cost honestly choose to buy.
“Orchestration is only for huge merchants.” The threshold has come down significantly. Merchants in the $20M to $50M annual volume range increasingly find orchestration valuable, particularly if they sell internationally or rely on subscriptions.
What is the difference between a payment gateway and a payment processor?
A payment gateway captures and securely transmits payment information from the customer to the processor. A payment processor moves the authorization request through the card networks to the customer’s bank, then handles the settlement of funds. The gateway moves information; the processor moves money. Most modern providers bundle the two together, which is why the terms are often used interchangeably even though they describe different functions.
What is the difference between a payment processor and a payment orchestration platform?
A payment processor handles the technical movement of a transaction through the card networks for a single provider relationship. A payment orchestration platform sits above one or more processors and routes each transaction to the best one based on real-time rules. Orchestration is not a replacement for processing; it is a coordination layer that uses multiple processors and gateways at once.
Do I need both a payment gateway and a payment processor?
You need both functions, but you do not necessarily need them from two different vendors. Most merchants buy them bundled as part of a single PSP product. The relevant question is not whether you have both, but whether your gateway and processor offer the routing flexibility, geographic coverage, and resilience your business actually needs.
Can a payment orchestration platform replace my existing PSP?
No, and that is not what orchestration is designed to do. Orchestration platforms work alongside existing PSPs, processors, and gateways. The merchant continues to maintain commercial relationships with those providers; the orchestration platform manages the routing and provides a unified integration on top.
What is the difference between a PSP and a payment orchestration platform?
A PSP (payment service provider) is a single commercial bundle that provides gateway, processing, and sometimes acquiring services. A payment orchestration platform connects to multiple PSPs at once and routes transactions across them. A PSP is one provider; orchestration is the layer that coordinates many providers.
How does payment orchestration affect PCI DSS compliance?
Orchestration platforms typically reduce a merchant’s PCI DSS scope significantly, often by 70% or more, by centralizing card data storage in a single PCI Level 1 compliant vault rather than spreading it across multiple gateway and processor integrations. This simplifies audits, reduces ongoing compliance overhead, and makes it easier to comply with newer requirements such as PCI DSS 4.0.1.
Does payment orchestration add latency to checkout?
A well-architected orchestration platform adds minimal latency, typically under 50 milliseconds per transaction. Single-tenant orchestration architectures (where the platform is deployed dedicated to one merchant) tend to perform better than multi-tenant ones because they avoid shared-infrastructure contention. The latency added is usually invisible to customers and is more than offset by the higher authorization rates orchestration enables.
How long does it take to implement payment orchestration?
Implementation timelines vary by complexity, but most merchants are live with their primary PSP routed through orchestration within four to eight weeks. Adding additional providers, optimizing routing rules, and migrating stored credentials typically continues for another one to three months. The up-front effort is greater than a single PSP integration, but it replaces many future integrations.
Is orchestration only useful for cards, or does it cover other payment methods?
Orchestration covers cards, digital wallets (Apple Pay, Google Pay, Click to Pay), buy now pay later providers (Klarna, Afterpay, Affirm), local methods (PIX, iDEAL, UPI), bank transfers, and increasingly, agentic and AI-initiated payments. The benefit of orchestration grows with each additional method, because managing them all through one integration is dramatically simpler than maintaining direct connections to each provider.
The three layers are not competitors. They are complementary parts of the same payment stack, and the right architecture depends on where your business is now and where it is going.
Gateways and processors are necessary in every payment flow. Whether you buy them from one vendor or several, whether you call your provider a PSP or something else, the core functions of capturing payment data and moving money through the card networks must exist.
Payment orchestration becomes valuable the moment a single-provider architecture starts costing you more than it saves: through declined transactions you could have recovered, through outages that stop your business, through engineering time absorbed by integrations rather than product, or through the inability to expand into a market your provider does not serve well.
If you’re evaluating where your payment stack sits on this spectrum and what orchestration could unlock for your business, contact our team for a walkthrough of how Gr4vy’s cloud-native orchestration platform fits into the architecture you already have.
Peak moments don’t break systems by accident. They expose the limits that were always there.…
Mastercard is changing how transactions are tracked across the payment lifecycle. The Transaction Link Identifier…
Last updated May 21st 2026 Around half of online merchants now use more than one…
The complexity of managing digital transactions has grown exponentially as businesses expand their reach globally.…
The choice between hosted checkout and API checkout shapes how a payment stack handles every…
Card payments don’t fail randomly. They fail because the data behind them becomes outdated. Cards…