(Updated – August 2026)

With customer expectations and the complexity of global payments overwhelming businesses, the need for payment orchestration services is about to scale unimaginably. Gone are the days when all could be bundled through one PSP or standard payment gateway. While payment orchestration consolidates multiple payment methods, it simultaneously routes transactions intelligently, thus enabling global scalability.

With a projection that eCommerce is estimated to top $7 trillion in 2025 alone globally, the need for orchestration to enable operational efficiency, drive costs further down, and improve the customer experience has never been greater.

What is payment orchestration?

Payment orchestration means that companies are joined with various payment service providers, gateways, and financial services to bring all their payments in one place. Payment Orchestration: The “Command Center” Unlike the gateway technology of the Payment Gateway that bridges customers to payment providers, orchestration serves as an “advanced command center” for everything related to payments.

Manage, through one API, the configuration of payment routing, multiple methods of payments, workflow automation, security, and regulatory requirements of the payments, such as PCI DSS. Merchants seek control, cost reduction, and a high approval rate, which is, in simple words, what payment orchestration platforms like Gr4vy work on.

Learn more about payment orchestration.

Top 10 benefits of payment orchestration in 2026

1. Increased payment flexibility and support for multiple payment methods

Today’s consumer expects to pay by the method of their choice, be that credit cards, e-wallets, BNPL, or even cryptocurrencies. In this regard, payment orchestration can enable merchants to offer a wider variety of payment methods without accomplishing the daunting task of complex integrations.

Why It Matters:

• It improves customer satisfaction, with reduced cart abandonment.
• Supports location-dependent payment methods such as iDEAL in the Netherlands and Boleto in Brazil.

Learn more about alternative payment methods.

2. Higher transaction success rate

With payment orchestration, businesses can enable intelligent routing to achieve higher approval rates. Slightly different, if one PSP had declined a transaction, it would automatically switch to retry via another, so fewer of those payments fail.

Why it matters:

• Increased revenue because of reduced payment failures.
• This is failover protection if the first PSP is unable to process the payment.

Explore tips to improve your approval rates.

3. Cost reduction and fee optimization

The higher volume of payments that are processed within a company, the more payment fees increase, including cross-border ones. Payment orchestration helps online merchants reduce their payment fees via availing of lower-fee PSPs or through rerouting with local acquirers.

Why it matters:

• Reduces Interchange, Assessment, and PSP fees
• Route payments to providers with the lowest transaction fees.
• Learn how to save on online payment processing fees.

4. Central payment management

It means that it enables the merchant to run all their payments from one place without necessarily keeping different PSP dashboards. Because of orchestration, all transactions and all KPIs could be viewed from one single point of view.

Why It Matters:

• Real-time transparency into the payment activity.
• Reporting, reconciliation, and dispute management also become easier.

5. Improved data security and compliance towards PCI-DSS.

PCI DSS compliance is mandatory for merchants handling cardholder data. Payment orchestration platforms like Gr4vy handle PCI compliance, enabling businesses to operate more securely without the heavy operational burden.

Why It Matters:

• Eases the pain of PCI DSS certification.
• Offloads the liability of dealing with cardholder data to the orchestration provider.
• Learn more about compliance with PCI DSS.

6. Scaling faster and expanding internationally

The larger an e-commerce business is, the more local payment options are needed, and so is their compliance with local legislations. Payment orchestration allows for seamless scaling into new markets.

Why it matters:

• Support for local payment methods across international markets.
• Help enterprises scale up faster by reducing operational friction.

7. Faster time-to-market for new payment integrations

It takes a few weeks, sometimes even months, before new payment providers are integrated. Payment orchestration allows the option to onboard new PSPs fast due to the existing prebuilt integrations.

Why it matters:

• Least technical debts and time spent on development.
• Merchants can expand into more regions more quickly.

8. Dynamic payment workflows

Furthermore, when it comes to the rules-based workflow, the merchants can customize the unique payment logic. They can set the high-value transaction routing rules with a PSP or include on-the-fly fraud detection for suspicious payments.

Why it matters:

• Operational flexibility for unique logics of paying.
• Provide workflow conditionality without any coding.

9. Enhanced customer experience

Payment friction is among the top causes of cart abandonment. Through one-click payment, quicker checkout, and the ability to support customer-preferred ways of payment, payment orchestration facilitates this.

Why it matters:

• Reduces friction at check-out; increases conversions
• Drives customer loyalty with faster, frictionless payment experiences.
• Learn not to abandon checkout.

10. Reduced compliance hassle and regulatory support

Above all, compliance in matters concerning payment is tough the moment it goes cross-border. It automates compliance in orchestration processes: PCI DSS, PSD2, and GDPR.

Why it matters:

• Releases the regulatory burden from the merchant.
• Ensures operating compliance with ever-evolving regulations across a multitude of regions. 

Learn more about Compliance and Regulations. 

Frequently Asked Questions 

1. What is a payment orchestration platform? 

It’s a place where all the processes around payments are managed centrally. Thus, it can enable the same businesses to connect to several sources of payments, manage payment routing, and optimize transaction flows. 

2. How does the idea of payment orchestration differ from that of a payment gateway? 

The answer is straightforward: a payment gateway is a bridge for the customer and PSPs, while payment orchestration provides the capability to manage multiple PSPs, routes, and means of paying. 

3. How does the payment orchestration help decrease the cost of the payables? 

It guides the routing of the payments towards PSPs, which charge less and helps in negotiating volume in return for better rates. 

4. Why is payment orchestration so important for any e-commerce? 

It improves the success rate of each transaction, reduces part of the costs, and improves the customer experience; it will also enable new trends and changes in regulations. 

5. How can I incorporate payment orchestration into my business? 

For instance, on the Gr4vy platform, a business can integrate with one API and in return, manage PSPs, payment methods, and workflows. 

Payment orchestration stopped being a “nice-to-have” and has grown into a “must” for every business because it resolves all three problems in one stroke-operational efficiency, global growth, and lower payment costs. Advantages abound, from supporting multiple payment methods to added security and compliance; in many ways, payment orchestration shapes the face of 2026 payments. 

Contact Gr4vy today to understand how payment orchestration will increase your success rate, decrease your costs, and future-proof your business for 2026.

(Updated – August 2026)

Payment orchestration is a technology layer that connects a merchant to multiple payment service providers, acquirers, and payment methods through a single integration, and routes each transaction to the option most likely to serve it best. Instead of building and maintaining a separate integration for every provider, a merchant connects once to the orchestration layer and controls how payments are routed, retried, and reconciled across all of them from one place.

That single idea, a control layer sitting between the merchant and its many payment providers, is what the rest of this guide unpacks: what payment orchestration is, how it works step by step, what it is genuinely good for, where its limits are, and how to tell whether a business actually needs it.

What is payment orchestration?

Payment orchestration is the practice of managing multiple payment providers through one unified platform that decides how each transaction is processed. The orchestration layer connects to a merchant’s payment service providers (PSPs), acquirers, gateways, payment methods, and fraud tools, and coordinates them, so the merchant operates one integration and one set of rules rather than a tangle of separate connections.

The category has grown quickly as payments have become more complex. Independent research from Grand View Research valued the global payment orchestration platform market at USD 1,386.9 million in 2023 and projects it to reach USD 6,520.4 million by 2030, a compound annual growth rate of 24.7%. That growth reflects a simple pressure: as businesses add providers, payment methods, and markets, managing each connection separately becomes unsustainable, and a coordinating layer becomes the practical way to keep control.

The essential distinction to hold onto is that orchestration is a layer rather than a processor. It does not replace a merchant’s PSPs or acquirers; it sits above them and decides which one handles each transaction. That is why orchestration is often described as a control layer or a payment orchestration layer, and it is the reason a business can adopt orchestration without abandoning the payment relationships it already has.

How does payment orchestration work?

Payment orchestration works by inserting a coordinating layer between the checkout and the payment providers, and applying rules and real-time data to route each transaction. Following a single payment through the layer shows what it does at each step.

Transaction initiation. A customer chooses a payment method at checkout and confirms the payment. The transaction enters the orchestration layer instead of going directly to a single hard-wired provider.

Routing decision. The orchestration layer evaluates the transaction against the merchant’s rules and live data, weighing factors such as the card type, the customer’s country, the cost of each available provider, and each provider’s recent approval performance. It then selects the provider most likely to approve the transaction at the best cost. This routing logic is the core of orchestration, and Gr4vy’s guide on intelligent payment routing covers how it is built and tuned.

Authentication and fraud checks. Where required, the layer applies authentication such as 3D Secure and passes the transaction through the merchant’s chosen fraud tools before it is sent for authorization.

Authorization. The selected provider sends the transaction to the customer’s issuing bank for approval, and the approve-or-decline response returns through the layer.

Retry and fallback. If the transaction is declined for a reason that another provider might approve, the orchestration layer can automatically retry it through an alternative provider or apply fallback logic, recovering payments that a single-provider setup would simply have lost.

Reconciliation and reporting. The layer records the transaction and consolidates data across every provider into one unified view, so reporting and reconciliation happen in one place instead of provider by provider.

The whole authorization sequence happens in the moment the customer waits, while the routing intelligence and the unified data operate continuously behind it.

What is a payment orchestration layer?

A payment orchestration layer is the technical framework that performs the coordination described above. It is the software that connects to all of a merchant’s providers, holds the routing rules, applies retries and fallback, stores payment credentials in a provider-agnostic way, and unifies reporting. When people refer to a payment orchestration platform, the orchestration layer is the engine inside it doing the work. The layer is what lets a merchant add or change a provider through configuration instead of a new engineering integration each time.

Benefits of payment orchestration

The benefits of payment orchestration come down to a few areas that matter directly to revenue and operations. Each follows from the same underlying capability: routing across many providers instead of depending on one.

Higher authorization and approval rates

Because the orchestration layer can send each transaction to the provider most likely to approve it, and retry declines through an alternative, it recovers revenue that a single-provider setup loses to avoidable declines. As a documented example, the Australian retailer Baby Bunting secured a 2.8% uplift in authorization rates within four months of moving to an orchestrated dual-acquirer setup with failover routing. Gr4vy’s guide on how to increase payment approval rates covers the mechanisms in more depth.

Lower payment processing costs

Routing introduces competition among providers and lets a merchant send each transaction along the lowest-cost path that will still get it approved, using local acquiring to avoid cross-border fees where possible. This turns payment cost from a fixed expense into something the business can actively manage.

Access to more payment methods and markets

The orchestration layer gives a merchant access to a wide range of payment methods, currencies, and local acquirers through one integration. Gr4vy, for instance, connects merchants to more than 400 payment providers, methods, and anti-fraud services. Adding a new method or entering a new market becomes a configuration change instead of a fresh engineering project, which is what makes fast expansion feasible.

Resilience and no single point of failure

Depending on one provider means one point of failure: if it has an outage, payments stop. By connecting several providers and rerouting around any that fail, orchestration removes that single point of failure and keeps payments flowing when a provider degrades. For a business where downtime is lost revenue, this resilience alone can justify orchestration.

Unified data and control

Running many providers separately fragments reporting and forces every change through engineering. Orchestration consolidates data across all providers into one view and lets payments teams build and adjust routing rules without code, which is the operational independence orchestration is meant to deliver.

Payment orchestration platform capabilities

A payment orchestration platform typically bundles the orchestration layer with the tools a merchant needs to run it. The core capabilities to expect are a single integration to many providers and methods; a routing engine that can be configured without code; retry, failover, and fallback logic; provider-agnostic vaulting and tokenization of payment credentials; support for authentication such as 3D Secure; fraud-tool integration; and unified reporting and reconciliation across every connected provider.

Platforms differ in how they are architected, and the architecture has real consequences for security and control. Some platforms run all merchants together in a shared, multi-tenant environment. Others, such as Gr4vy, deploy a dedicated, single-tenant instance for each merchant, which isolates each merchant’s data and payment traffic and gives greater control over data residency and configuration. This distinction matters most for larger merchants and those in regulated markets, where data isolation and sovereignty are genuine requirements rather than nice-to-haves.

What payment orchestration does not solve

It is worth being clear about the limits, because orchestration is sometimes described as if it fixes everything, and it does not. Orchestration coordinates and routes payments; it does not, by itself, do the following.

It does not eliminate the underlying costs of the payment providers themselves; each provider’s fees still apply, and orchestration manages how they are used instead of removing them. It does not replace a merchant’s need for acquiring relationships or a merchant account. It cannot approve a transaction that every available provider would decline for a legitimate reason, such as genuinely insufficient funds. And it does not run itself: getting value from orchestration requires configuring the routing rules thoughtfully and maintaining them as provider performance changes. Understanding what orchestration does not do is as important as understanding what it does, because it sets realistic expectations for what adopting it will and will not change.

What payment orchestration does not solve

It is worth being clear about the limits, because orchestration is sometimes described as if it fixes everything, and it does not. Orchestration coordinates and routes payments; it does not, by itself, do the following.

It does not eliminate the underlying costs of the payment providers themselves; each provider’s fees still apply, and orchestration manages how they are used instead of removing them. It does not replace a merchant’s need for acquiring relationships or a merchant account. It cannot approve a transaction that every available provider would decline for a legitimate reason, such as genuinely insufficient funds. And it does not run itself: getting value from orchestration requires configuring the routing rules thoughtfully and maintaining them as provider performance changes. Understanding what orchestration does not do is as important as understanding what it does, because it sets realistic expectations for what adopting it will and will not change.

Challenges of payment orchestration

Alongside the benefits, adopting payment orchestration carries real challenges that a business should weigh honestly.

The first is implementation effort. Connecting a merchant’s existing providers into the orchestration layer takes configuration, testing, and integration work, and every provider added carries its own requirements. The second is cost: an orchestration platform carries its own fees (setup, subscription, or per-transaction), which sit on top of the underlying provider costs, so the case for orchestration rests on the routing and resilience gains outweighing that added layer of cost. The third is technical involvement: while good platforms let payments teams manage routing without code, the initial integration and ongoing operation still call for technical capacity. The fourth is dependency: placing an orchestration layer at the center of the payment stack means the platform’s own reliability and neutrality matter, which is why the platform’s uptime and whether it profits from routing decisions are worth scrutinizing during evaluation.

None of these is a reason to avoid orchestration, but each is a reason to adopt it deliberately, with a clear view of the effort and cost against the expected gain.

Do you need a payment orchestration platform?

Payment orchestration is not necessary for every business, and the honest answer to whether a business needs it depends on its situation.

The case for orchestration is strongest for businesses that sell across multiple countries, where local acquiring and local payment methods materially improve approval rates and reach; businesses using or planning to use more than one PSP or acquirer; businesses where payment downtime is costly enough that resilience justifies the investment; high-volume businesses where routing on cost and recovering declined transactions produces meaningful savings; and subscription businesses where recovering failed recurring payments directly reduces involuntary churn.

The case is weaker for small, single-market businesses with modest volume, a single provider that meets their needs, and no near-term plans to add providers or markets. For them, a single well-chosen PSP may be entirely sufficient, and the added cost and complexity of orchestration would not pay for itself yet. The right approach is to match the decision to the business’s actual payment complexity rather than adopting orchestration for its own sake.

Payment orchestration vs a single PSP

The most common alternative to orchestration is simply using one payment service provider that bundles a gateway, processing, and acquiring together. A single PSP is simpler to manage and can be a good fit for businesses with straightforward needs. The tradeoff is that it means one set of approval rates, one pricing relationship, and one point of failure, with limited ability to route for performance or add providers as the business grows. Orchestration trades some of that simplicity for control, redundancy, and the ability to optimize across many providers. For the detailed comparisons, see Gr4vy’s guides on payment orchestration vs a payment processor and payment orchestration vs payment aggregators.

How to choose a payment orchestration platform

If a business decides orchestration fits, the evaluation should weigh depth of coverage in its priority markets rather than raw connector count; the sophistication of the routing and recovery logic; whether the platform is genuinely neutral or profits from where transactions route; data ownership and portability; security and compliance, including PCI DSS Level 1 certification; reliability and redundancy; and how much the team can control without engineering involvement. Gr4vy’s guide on PCI DSS compliance and payment orchestration covers the security dimension, and the fuller set of evaluation criteria is worth working through before committing to a platform.

Payment orchestration and agentic commerce

Looking ahead, one of the developments making orchestration more relevant is the rise of agentic commerce, where AI agents shop, compare, and transact on a consumer’s behalf. Existing payment stacks were not built for agent-initiated transactions, and merchants need a way to identify, route, and control them separately from ordinary traffic. Because orchestration already sits at the control layer, it is well positioned to do this: agent transactions can be marked, routed through their own rules, sent to different providers or fraud tools, and held to specific limits, all without rebuilding the payment stack. Gr4vy has built an early version of exactly this, described in its guide on payment orchestration for agentic commerce. It is a useful illustration of the broader point that an orchestration layer lets a business adopt new payment developments through configuration rather than re-engineering.

Frequently asked questions

What is payment orchestration in simple terms?

Payment orchestration is a technology layer that connects a merchant to many payment providers through one integration and automatically routes each transaction to the provider most likely to approve it at the best cost. Instead of managing separate connections to each provider, the merchant manages one platform and one set of rules. It coordinates payments instead of replacing the providers themselves.

How does payment orchestration work?

It inserts a coordinating layer between the checkout and the payment providers. When a customer pays, the layer evaluates the transaction against the merchant’s rules and live data, routes it to the best-suited provider, applies authentication and fraud checks, and if the transaction is declined can retry it through another provider. It then consolidates the data from every provider into one unified view for reporting and reconciliation.

What is a payment orchestration layer?

A payment orchestration layer is the technical framework that connects to all of a merchant’s payment providers, holds the routing rules, applies retries and fallback, stores payment credentials in a provider-agnostic way, and unifies reporting. It is the engine inside a payment orchestration platform that does the coordination, and it is what allows a merchant to add or change a provider through configuration instead of a new engineering integration.

What are the benefits of payment orchestration?

The main benefits are higher authorization and approval rates (by routing to the best provider and retrying declines), lower processing costs (by routing on cost and using local acquiring), access to more payment methods and markets through one integration, resilience through the removal of a single point of failure, and unified data and control across all providers. The benefit that matters most varies by business.

Is payment orchestration a single point of failure?

Used correctly, orchestration reduces single points of failure rather than creating one, because it connects multiple providers and reroutes around any that fail. The consideration is the orchestration platform’s own reliability, since it sits at the center of the payment stack. This is why the platform’s uptime and redundancy architecture are worth evaluating, and why platforms are designed so the layer itself is resilient.

How much does payment orchestration cost?

An orchestration platform carries its own fees, which may be setup, subscription, or per-transaction, and these sit on top of the underlying costs of the payment providers themselves. The case for orchestration rests on the gains (higher approval rates, lower routing costs, reduced downtime, less engineering overhead) outweighing that added layer of cost, which is why the honest way to evaluate it is to model the specific expected gain against the specific cost for the business.

Do all businesses need payment orchestration?

No. Orchestration is most valuable for businesses selling across multiple markets, using more than one provider, running high volume, or depending on recurring payments. A small, single-market business with one provider that meets its needs may find a single PSP entirely sufficient, and the added cost and complexity of orchestration would not yet pay for itself. The decision should match the business’s actual payment complexity.

What is the difference between payment orchestration and a PSP?

A payment service provider (PSP) processes payments, often bundling a gateway, processing, and acquiring. Payment orchestration is a layer that sits above multiple providers, including PSPs, and routes between them. A single PSP is simpler but means one set of approval rates and one point of failure; orchestration adds control, redundancy, and the ability to optimize across many providers. Some businesses use a PSP directly; others use orchestration to coordinate several.

Does payment orchestration replace my payment providers?

No. Orchestration is a coordinating layer rather than a processor. It sits above a merchant’s existing PSPs, acquirers, and gateways and decides which handles each transaction, so a business can adopt orchestration while keeping the payment relationships it already has. It manages how providers are used rather than replacing them.

How does payment orchestration help with international expansion?

Entering a new market requires supporting local payment methods and, ideally, local acquiring for higher approval rates. Orchestration provides access to those methods and acquirers through one integration, so adding a market becomes a configuration step instead of a separate engineering project for each country. This is one of the most common reasons cross-border businesses adopt orchestration.

Where payment orchestration is heading

Payment orchestration began as a way to manage the growing complexity of digital payments, and it has become the control layer through which many merchants run their entire payment operation. The core value has stayed constant: connect many providers through one integration, route each transaction intelligently, add resilience, and keep ownership of the data and the decisions. What changes is the range of things that control layer can do, from lifting approval rates and cutting costs today to coordinating agent-initiated transactions as commerce shifts toward AI.

For a business, the practical question is not whether orchestration is impressive in the abstract but whether its own payments are complex enough to benefit: multiple providers or markets, meaningful volume, costly downtime, or recurring billing to protect. Where those conditions hold, orchestration turns a fragmented, engineering-bound payment operation into one a team can control and optimize directly.

Gr4vy is a cloud-native payment orchestration platform that connects merchants to more than 400 payment providers and methods through a single integration, with each merchant running in its own dedicated instance for control over data and configuration. To talk through whether orchestration fits your payment operation, get in touch with our team.

A customer sees a charge on their card statement they do not recognize, or a purchase that never arrived, and instead of contacting the merchant they call their bank and ask for their money back. A few days later the merchant finds the sale reversed, the goods gone, and a fee deducted on top. That reversal is a chargeback, and the sequence of events that produced it, from the cardholder’s call to the final resolution, is a defined process with fixed stages, deadlines, and rules set by the card networks.

Most explanations of chargebacks jump straight to how to prevent them. This one does something different: it walks through what a chargeback actually is and how the dispute moves through the system from start to finish, because understanding the mechanism is what makes everything else, the reason codes, the deadlines, the decision of whether to fight one, make sense.

What is a chargeback?

A chargeback is a forced reversal of a card payment, initiated by the cardholder’s bank rather than by the merchant. When a cardholder disputes a transaction with the bank that issued their card, the bank can reverse the payment, pull the funds back from the merchant, and return them to the cardholder, while the dispute is investigated under the card network’s rules.

The mechanism exists for consumer protection. In the United States its legal foundation is the Fair Credit Billing Act of 1974, which gave cardholders the right to dispute billing errors and unauthorized charges. The card networks (Visa, Mastercard, American Express, and Discover) built their own dispute frameworks on top of that principle, and those frameworks are what govern how a chargeback plays out today.

The essential thing to grasp is who initiates it. A chargeback comes from the issuing bank, at the cardholder’s request, and it happens whether or not the merchant agrees. That single fact, that the reversal is imposed from outside rather than granted by the merchant, is what separates a chargeback from a refund and what makes it costly and adversarial in a way a refund is not.

What is the difference between a chargeback and a refund?

A refund and a chargeback both return money to the customer, but they travel opposite paths. A refund is voluntary and merchant-led: the customer contacts the business, the business agrees, and it returns the money directly. The process is cooperative, there is no penalty, and no third party is involved.

A chargeback is involuntary and bank-led: the customer bypasses the merchant, goes to their issuing bank, and the bank forces the reversal. The merchant usually pays a chargeback fee on top of losing the sale, the transaction counts against the merchant’s chargeback ratio, and the card networks are directly involved. A refund is a customer-service outcome; a chargeback is a dispute with financial and reputational consequences for the merchant. Because the two are so often confused, Gr4vy covers the distinction in more detail in its guide on refunds versus chargebacks.

How the chargeback process works, stage by stage

A chargeback is not a single event but a sequence, and the sequence matters because each stage has its own actors, deadlines, and decisions. Here is how a typical card dispute moves from the cardholder’s first complaint to a final resolution.

Stage 1: The cardholder disputes the transaction

The process begins when a cardholder contacts their issuing bank to dispute a charge. They might claim the transaction was fraudulent, that the goods never arrived, that the product was not as described, that they were charged twice, or that a subscription they thought they had cancelled was billed again. The cardholder does not need the merchant’s involvement or agreement to start this; they simply tell the bank they want the charge reversed.

Stage 2: The issuing bank reviews and assigns a reason code

The issuing bank examines the cardholder’s claim and, if it decides the dispute is valid enough to proceed, provisionally credits the cardholder and assigns a reason code that categorizes the dispute. This code (more on the categories below) is the bank’s shorthand for why the chargeback is being raised, and it determines what evidence the merchant will need if they choose to fight it. At this point the funds are pulled from the merchant’s account through the acquiring bank.

Stage 3: The acquirer notifies the merchant

The dispute travels from the issuing bank, through the card network, to the merchant’s acquiring bank, which notifies the merchant of the chargeback along with its reason code and the amount reversed. The merchant now learns that a sale has been pulled back, why the cardholder says it should be reversed, and how long they have to respond. This is usually the first moment the merchant knows a dispute exists.

Stage 4: The merchant accepts or represents the chargeback

The merchant now faces a decision. They can accept the chargeback, absorbing the loss and the fee, which is often the rational choice for a low-value transaction or one the merchant knows it cannot win. Or they can contest it through a process called representment, submitting evidence to the issuing bank that the charge was legitimate. That evidence depends entirely on the reason code: proof of delivery for a “goods not received” claim, proof of authentication for a fraud claim, records of a cancellation policy for a subscription dispute. Representment has to be built to answer the specific claim the reason code describes, under a tight deadline.

Stage 5: Arbitration by the card network

If the merchant represents and the issuing bank rejects the evidence, the dispute can escalate. The cardholder’s bank may file a second chargeback, and if the two banks still disagree, the case can go to arbitration, where the card network itself reviews the evidence and makes a binding decision. Arbitration carries fees and risk for whichever side loses, so it is usually reserved for higher-value disputes where the amount justifies the cost. Most disputes resolve before this stage, but it is the backstop that settles the ones that do not.

Chargeback reason codes explained

The reason code assigned in Stage 2 is the pivot the whole dispute turns on, so it is worth understanding what these codes are. A chargeback reason code is a standardized identifier that the issuing bank attaches to a dispute to describe why the cardholder says the charge should be reversed. Each card network maintains its own set of codes with its own format: Visa uses codes under its Visa Claims Resolution framework, Mastercard uses four-digit numeric codes, and American Express and Discover each have their own systems.

Despite the different formats, the codes across all networks fall into roughly four categories:

The first is fraud, where the cardholder claims they did not authorize the transaction. The second is authorization, covering transactions that should not have been approved, such as a charge on a card that was already declined or over its limit. The third is processing errors, operational mistakes like charging the wrong amount, billing twice, or failing to process a credit. The fourth is consumer disputes, where the cardholder acknowledges the purchase but has a complaint, such as goods not received, a product not as described, or a cancelled service still being billed.

One caution that experienced merchants learn quickly: the reason code reflects what the cardholder told their bank rather than a verified fact. A cardholder may select or be assigned a code that does not match what really happened, sometimes out of confusion and sometimes deliberately. The code tells the merchant what claim they have to rebut and what evidence will count, which is why reading it carefully before responding matters more than the label suggests.

How long does the chargeback process take?

Chargebacks operate on the card networks’ deadlines instead of the merchant’s, and the full cycle can stretch over weeks or months. A cardholder generally has a set window after the transaction or statement to raise a dispute, often up to 120 days depending on the network and the reason, though for some claim types it can be longer. Once a chargeback is filed, the merchant typically has a limited response window, frequently around 20 to 45 days depending on the network, to submit representment evidence.

From there, the issuing bank takes time to review any evidence, and if the dispute escalates to a second chargeback or arbitration, additional weeks are added. In practice, a straightforward chargeback that the merchant accepts closes quickly, while a contested one can take two to three months or more to fully resolve. The precise deadlines vary by card network and reason code, which is one reason cross-border merchants dealing with multiple networks find dispute management complex to run.

Who pays for a chargeback, and what does it cost?

When a chargeback succeeds, the merchant bears the cost, and that cost is larger than the sale itself. The merchant loses the transaction amount, which is returned to the cardholder. On top of that, the acquirer typically charges a chargeback fee for processing the dispute, which the merchant pays regardless of whether they win or lose the case. If physical goods were shipped, the merchant has usually lost those too.

Beyond the direct costs, every chargeback counts toward the merchant’s chargeback ratio, the proportion of its transactions that end in disputes. Card networks monitor this ratio, and merchants who exceed the networks’ thresholds can face monitoring programs, additional fines, higher processing costs, and in severe cases the loss of their ability to accept card payments. This is why chargebacks are treated as a serious operational risk rather than an occasional cost of doing business: the fees and lost goods are visible, but the threat to the merchant’s processing standing is often the more consequential exposure.

What is friendly fraud, and why is it rising?

A growing share of chargebacks are not fraud in the traditional sense at all. Friendly fraud, also called first-party misuse, happens when a legitimate customer disputes a charge for a purchase they actually made and received, to get their money back while keeping the goods or service. Sometimes it is deliberate abuse; sometimes it is genuine confusion, such as not recognizing a merchant’s billing name on a statement or forgetting about a subscription.

Friendly fraud is difficult for merchants because it arrives disguised as a legitimate dispute, often under a fraud reason code, even though the transaction was valid. Industry research points to this category growing: the Merchant Risk Council’s 2026 Global eCommerce Payments and Fraud Report, a survey of 1,278 merchants across 37 countries, found that around 64% of merchants reported increasing first-party misuse. Because the transaction really did happen, the merchant’s defense in representment rests on evidence that the cardholder received what they paid for, which is why records like delivery confirmation, usage logs, and authentication data matter so much. Gr4vy’s guide on payment fraud prevention strategies covers how merchants detect and respond to this pattern.

Frequently asked questions

What is a chargeback in simple terms?

A chargeback is a forced reversal of a card payment that the cardholder’s bank initiates after the cardholder disputes the charge. The bank pulls the funds back from the merchant and returns them to the cardholder while the dispute is investigated under the card network’s rules. Unlike a refund, it happens without the merchant’s agreement and usually comes with a fee and a mark against the merchant’s chargeback ratio.

What is the difference between a chargeback and a refund?

A refund is voluntary and handled directly between the customer and the merchant, with no penalty and no third party. A chargeback is involuntary: the customer goes to their issuing bank, which forces the reversal. The merchant typically pays a fee, loses the sale, and has the transaction counted against its chargeback ratio. A refund is a customer-service outcome; a chargeback is a formal dispute with financial consequences.

How does the chargeback process work?

It moves through stages. The cardholder disputes a charge with their issuing bank; the bank reviews the claim, assigns a reason code, and provisionally reverses the funds; the merchant’s acquiring bank notifies the merchant; the merchant either accepts the chargeback or contests it through representment by submitting evidence; and if the banks still disagree, the dispute can escalate to arbitration, where the card network makes a binding decision.

What are chargeback reason codes?

Reason codes are standardized identifiers that the issuing bank attaches to a dispute to describe why the cardholder says the charge should be reversed. Each card network has its own format (Visa, Mastercard, American Express, and Discover all differ), but the codes generally fall into four categories: fraud, authorization issues, processing errors, and consumer disputes. The code determines what evidence a merchant needs to contest the dispute.

How long does a merchant have to respond to a chargeback?

The response window depends on the card network and reason code but is commonly in the range of 20 to 45 days from notification. Merchants have to submit their representment evidence within that window, which is why having documentation organized in advance matters. Missing the deadline generally means the chargeback stands regardless of the merits.

Can a merchant fight a chargeback?

Yes, through a process called representment, where the merchant submits evidence to the issuing bank that the transaction was legitimate. The evidence has to answer the specific claim behind the reason code, such as proof of delivery for a “goods not received” dispute or authentication records for a fraud claim. Whether it is worth fighting depends on the transaction value, the reason code, and the strength of the available evidence.

How much does a chargeback cost a merchant?

A merchant that loses a chargeback loses the transaction amount, typically pays a chargeback fee to its acquirer regardless of outcome, and often loses any goods that were shipped. Each chargeback also counts toward the merchant’s chargeback ratio, and exceeding the card networks’ thresholds can lead to fines, monitoring programs, higher costs, and in serious cases losing the ability to accept cards.

What is friendly fraud?

Friendly fraud, or first-party misuse, is when a legitimate customer disputes a charge for something they actually bought and received, keeping the goods or service while recovering their money. It can be deliberate or the result of genuine confusion, such as not recognizing a billing descriptor. It is hard to counter because it looks like a legitimate dispute, and research indicates it is rising, with most merchants reporting increases.

What happens if a merchant gets too many chargebacks?

Card networks track each merchant’s chargeback ratio. Merchants who exceed the networks’ thresholds can be placed into chargeback monitoring programs, charged additional fines, moved to higher processing costs, and, in severe or sustained cases, lose their ability to accept card payments. This is why keeping the chargeback ratio low is a priority even beyond the cost of individual disputes.

Do chargebacks apply to digital wallets and other payment methods?

Card-based digital wallet transactions (a card loaded into Apple Pay or Google Pay, for example) are still subject to the card networks’ chargeback rules, because the underlying payment is a card payment. Other payment methods, such as bank transfers or certain local payment methods, have their own dispute mechanisms that differ from the card chargeback process, which is one more reason merchants operating many payment methods find dispute handling complex.

Where chargebacks fit in a merchant’s payment strategy

Understanding the chargeback process end to end changes how a merchant treats it. A chargeback is not a random misfortune but a defined procedure with predictable stages, actors, and deadlines, which means it can be prepared for: documentation kept ready for representment, billing descriptors made clear to reduce confusion-driven disputes, delivery and authentication records retained, and reason-code patterns watched for the operational problems they reveal.

The deeper point is that chargebacks sit at the intersection of fraud, customer experience, and payment operations. Some are genuine fraud, some are friendly fraud, and many trace back to preventable friction like an unclear billing name or a confusing cancellation flow. Reducing them is less about fighting each dispute and more about addressing what causes them, which is the subject of Gr4vy’s guides on avoiding and controlling chargebacks and, for European merchants specifically, reducing chargebacks and protecting revenue.

Gr4vy is a cloud-native payment orchestration platform that gives merchants centralized visibility over disputes across every connected provider, along with the fraud tooling, authentication controls, and unified reporting that help keep chargeback ratios in check. To see how consolidated dispute visibility would work across your payment stack, talk to our team.

Payment orchestration sits at the intersection of two fast-moving trends: the shift of nearly all commerce to digital payments, and the growing pressure on merchants to stop losing revenue to failed and falsely declined transactions. The statistics below map both, drawn from independent research firms and, where merchant outcomes are cited, from published case studies with named companies behind them.

Every figure here is attributed to its source. Market and industry data come from independent research organizations such as Grand View Research, Worldpay’s Global Payments Report, Statista, Capgemini, Datos Insights, Juniper Research, and the Merchant Risk Council, rather than from payment vendors quoting one another. Merchant-result figures come directly from Gr4vy’s published case studies and are stated as those case studies report them. Where sources disagree or a number is an estimate, that is flagged, because a statistic is only as useful as its provenance is clear.

Payment orchestration market size statistics

The payment orchestration platform market is small relative to the wider payments industry but growing quickly, and estimates vary by research firm depending on how each defines the category.

• The global payment orchestration platform market was valued at USD 1,386.9 million in 2023, according to Grand View Research.
• Grand View projects the market will reach USD 6,520.4 million by 2030, roughly a fourfold increase over the forecast period.
• An alternative estimate from GM Insights placed the 2023 market at around USD 1.2 billion, close to Grand View’s figure.
• Vantage Market Research sized the market higher, at USD 2.8 billion in 2025, projecting USD 9.7 billion by 2035. The spread across firms reflects different definitions of what counts as orchestration revenue.
• Across every major research firm, the consistent signal is a market growing at double-digit annual rates, placing payment orchestration among the faster-growing payments infrastructure segments.

The takeaway from the market-size data is less about any single headline number and more about the direction and pace: independent researchers disagree on the exact figure but agree the category is expanding quickly.

Payment orchestration market growth and regional statistics

Growth rates and regional share show where orchestration adoption is concentrated and where it is accelerating.

• Grand View Research puts the payment orchestration market’s compound annual growth rate at 24.7% from 2024 to 2030, among the highest in payments infrastructure.
• North America accounted for 31.4% of the global market in 2023, making it the largest region by revenue, according to Grand View Research.
• Asia Pacific is the fastest-growing region at roughly 26% CAGR, per Grand View, driven by rapid e-commerce growth and smartphone adoption.
• India is expected to register the highest country-level growth rate through 2030, reflecting the expansion of digital payments across the region.
• The B2B segment held the largest share of the orchestration market in 2023 at roughly 64%, according to Grand View’s segmentation, while the B2C segment is projected to grow fastest.

Digital payments statistics driving orchestration demand

Payment orchestration exists because digital payments have become the dominant way the world transacts, creating the multi-provider complexity that orchestration is built to manage.

• Total transaction value in the global digital payments market is projected to reach USD 20.09 trillion in 2025, growing at a 13.63% CAGR to USD 38.07 trillion by 2030, according to Statista Market Insights.
• Spending through digital payment methods in e-commerce and in-person shopping grew from USD 1.7 trillion in 2014 to USD 18.7 trillion in 2024, a nearly elevenfold increase over the decade, per Worldpay’s Global Payments Report.
• The total value of digital payments is expected to exceed USD 33.5 trillion by 2030, according to Worldpay.
• Digital payments grew from 34% of e-commerce value in 2014 to 66% in 2024, and from 3% to 38% of in-store value over the same period, per Worldpay.
• Instant payments accounted for 13% of global non-cash transactions in 2022 and are projected to exceed 22% by 2028, according to the Capgemini Research Institute.
• Two-thirds of adults worldwide now use digital payments, and 76% of adults globally now have a bank account or mobile money provider, per the World Bank’s Global Findex.

Digital wallet and payment method statistics

The proliferation of payment methods, and the dominance of digital wallets, is a core reason merchants need to manage many providers and methods at once.

• Digital wallets accounted for 56% of global e-commerce value and 33% of point-of-sale value in 2025, representing over USD 13.8 trillion in combined spending, according to Worldpay’s Global Payments Report.
• In APAC, digital wallets were even more dominant, accounting for 77% of online spending and 62% of in-store spending in 2025, per Worldpay.
• Digital wallet spending is forecast to grow around 10% annually from 2025 to 2030, with payment apps across channels projected to reach USD 23.4 trillion by 2030, according to the Worldpay / Global Payments report.
• Direct credit and debit card use accounted for 20% and 12% of e-commerce payments respectively in 2024 (and 25% and 22% at the point of sale), making cards the second and third most-used methods behind digital wallets, per Worldpay.
• Brazil’s Pix instant-payment system accounted for 42% of e-commerce and 34% of POS value in Brazil in 2025 and has expanded acceptance into markets including Argentina, Chile, Portugal, Spain, and the US, per Worldpay.
• China’s Alipay+ platform connects 1.8 billion users to 100 million merchants across 14 markets, according to Worldpay’s report.

Authorization rate and payment decline statistics

Authorization rates are the metric orchestration most directly targets, and the decline data shows why the opportunity is large.

• The average payment decline rate across industries runs at roughly 7.9% of attempted transactions, with some sectors seeing materially higher rates, according to aggregated industry data.
• E-commerce authorization declines can reach as high as 17% in certain high-risk or high-ticket sectors, per industry analysis.
• Roughly 60 to 65% of declined transactions are estimated to come from legitimate customers instead of genuine fraud, according to industry research on authorization performance, indicating how much declined volume is potentially recoverable.
• Domestic acquiring commonly delivers 10 to 20% higher approval rates than cross-border processing for in-market cards, a gap orchestration addresses through local acquirer routing, per widely cited industry figures.

False decline statistics

False declines, legitimate transactions wrongly rejected, are one of the largest and least-measured sources of lost e-commerce revenue.

• The global average false-decline rate was 1.51% of e-commerce sales in 2024, according to Datos Insights drawing on Cybersource’s E-Commerce Fraud Landscape and Trends report.
• False declines were estimated to cost merchants nearly USD 175 billion in 2024, projected to approach USD 265 billion by 2027, per the same Datos Insights / Cybersource data.
• By comparison, actual e-commerce payment fraud losses were estimated at around USD 48 billion in 2023 by Juniper Research, meaning false declines cost merchants several times more than the fraud that decline systems are trying to prevent.
• These figures are independent estimates and specific numbers vary by source, but the consistent finding across studies is that false declines outweigh actual fraud by a wide margin.

Failed payment and subscription churn statistics

For subscription and recurring-billing businesses, failed payments translate directly into involuntary churn, most of which is recoverable.

• In roughly four out of five cases, failed payments stem from system friction such as false declines, processor issues, and expired credentials, rather than a genuine inability to pay, according to PYMNTS Intelligence research.
• Involuntary churn (subscribers lost to failed payments rather than active cancellation) accounts for an estimated 20 to 40% of total subscription churn, according to aggregated subscription-industry benchmarks.
• The average transaction failure rate for subscription businesses runs near 7.9% across industries, reaching as high as 14.7% in certain sectors, per aggregated 2025 subscription-payment data.
• Industry benchmarks place the median failed-payment recovery rate near 47.6%, indicating that roughly half of failed recurring payments can be recovered with retry and dunning strategies, with top performers recovering considerably more.
• These recovery figures come from a mix of research and vendor datasets and are best treated as directional benchmarks instead of precise universal rates.

Payment fraud statistics

The fraud landscape that decline and authentication systems respond to is shifting, which affects how merchants tune routing and authentication.

• The Merchant Risk Council’s 2026 Global eCommerce Payments and Fraud Report, a survey of 1,278 merchants across 37 countries, found around 64% of merchants reporting increasing first-party misuse (customers falsely claiming a legitimate transaction was unauthorized), with roughly a quarter seeing increases of 25% or more.
• Global digital payment fraud losses were estimated at around USD 41 billion in 2023, up roughly 18% year on year, according to industry data compiled from independent sources.
• First-party misuse is harder for traditional fraud rules to catch than classic stolen-card fraud, which pushes merchants toward more nuanced authentication and routing rather than blunt declines.

Real payment orchestration results from merchant case studies

The most directly verifiable statistics are those tied to a named business and a published outcome. The following come from Gr4vy’s own merchant case studies and are stated as those case studies report them.

• Baby Bunting secured a 2.8% uplift in authorization rates within the first four months of moving to a dual-acquirer setup with failover routing, as reported in its case study. Baby Bunting is Australia’s largest specialty baby-goods retailer. Read the Baby Bunting case study.
• Ding cut the time to integrate a new gateway and add a new local payment method from 3 to 6 weeks down to just 3 days through orchestration, as its case study reports. Ding is a mobile top-up service operating across more than 140 countries, and used orchestration to launch Pix in Brazil and prioritize PayPal in Germany through no-code rules. Read the Ding case study.
• FuturHealth completed its entire orchestration integration in 27 days, implementing dynamic routing across multiple PSPs with built-in retry logic to improve authorization rates and recover previously failed transactions, per its case study. Read the FuturHealth case study.
• Mattilda supports more than 180,000 students across a growing network of private schools in Latin America and selected Gr4vy to power Mattilda Pay, its white-label payment offering, as its case study documents. Read the Mattilda case study.
• Gr4vy connects merchants to more than 400 payment service providers, payment methods, and anti-fraud services through a single integration, turning the addition of a provider or method into a configuration change rather than an engineering project.

These merchant figures are the most concrete evidence in this guide, because each is tied to a named company and a published case study, unlike an industry average.

Payment orchestration statistics at a glance

A consolidated reference of the figures above, with sources.

Statistic	Figure	Source
Global orchestration market size (2023)	USD 1,386.9 million	Grand View Research
Global orchestration market size (2030, projected)	USD 6,520.4 million	Grand View Research
Orchestration market CAGR (2024-2030)	24.7%	Grand View Research
North America market share (2023)	31.4%	Grand View Research
Asia Pacific growth rate	~26% CAGR	Grand View Research
B2B share of orchestration market (2023)	~64%	Grand View Research
Global digital payments transaction value (2025)	USD 20.09 trillion	Statista Market Insights
Global digital payments value (2030, projected)	USD 38.07 trillion	Statista Market Insights
Digital payment method spending (2024)	USD 18.7 trillion	Worldpay Global Payments Report
Digital payments share of e-commerce (2024)	66%	Worldpay Global Payments Report
Digital wallet share of global e-commerce (2025)	56%	Worldpay Global Payments Report
Digital wallet share of global POS (2025)	33%	Worldpay Global Payments Report
Digital wallet share of APAC online spend (2025)	77%	Worldpay Global Payments Report
Instant payments share of non-cash transactions (2022)	13%	Capgemini Research Institute
Average payment decline rate	~7.9% of attempts	Aggregated industry data
Declines from legitimate customers	~60-65%	Industry research
Domestic vs cross-border approval gap	10-20% higher	Industry figures
Global false-decline rate (2024)	1.51% of e-commerce sales	Datos Insights / Cybersource
False-decline losses (2024)	~USD 175 billion	Datos Insights / Cybersource
False-decline losses (2027, projected)	~USD 265 billion	Datos Insights / Cybersource
E-commerce fraud losses (2023)	~USD 48 billion	Juniper Research
Failed payments from system friction	~4 in 5	PYMNTS Intelligence
Involuntary share of subscription churn	20-40%	Aggregated subscription benchmarks
Median failed-payment recovery rate	~47.6%	Industry benchmarks
Merchants reporting rising first-party misuse	~64%	Merchant Risk Council (2026)
Baby Bunting authorization-rate uplift	2.8% in first four months	Gr4vy (Baby Bunting case study)
Ding gateway/method integration time	3 days, down from 3-6 weeks	Gr4vy (Ding case study)
FuturHealth integration time	27 days	Gr4vy (FuturHealth case study)
Mattilda students supported (white-label)	180,000+	Gr4vy (Mattilda case study)
Gr4vy connections	400+ PSPs, methods, anti-fraud	Gr4vy

Frequently asked questions

How big is the payment orchestration market?

According to Grand View Research, the global payment orchestration platform market was valued at USD 1,386.9 million in 2023 and is projected to reach USD 6,520.4 million by 2030, growing at a 24.7% CAGR. Other firms estimate it differently (GM Insights at around USD 1.2 billion in 2023, Vantage Market Research at USD 2.8 billion in 2025), but all show double-digit growth. The variation comes from how each firm defines the orchestration category.

What is the growth rate of the payment orchestration market?

Grand View Research puts the payment orchestration market’s compound annual growth rate at 24.7% from 2024 to 2030, among the highest in payments infrastructure. Other research firms estimate CAGRs from roughly 13% to 25% depending on their market definitions, but all agree on double-digit annual growth.

Which region leads the payment orchestration market?

North America was the largest region in 2023 at 31.4% of global revenue, according to Grand View Research, while Asia Pacific is the fastest-growing region at roughly 26% CAGR, with India expected to post the highest country-level growth rate through 2030.

How much revenue do merchants lose to false declines?

According to Datos Insights, drawing on Cybersource’s 2024 report, the global false-decline rate averaged 1.51% of e-commerce sales, costing merchants nearly USD 175 billion in 2024 and projected to approach USD 265 billion by 2027. For comparison, Juniper Research estimated around USD 48 billion in actual e-commerce fraud losses in 2023, meaning false declines cost merchants several times more than actual fraud.

What percentage of failed payments are recoverable?

PYMNTS Intelligence research found that in roughly four out of five cases, failed payments stem from system friction (false declines, processor issues, expired credentials) rather than a genuine inability to pay, which makes much of the lost revenue recoverable. Industry benchmarks place the median failed-payment recovery rate near 47.6%, with top performers recovering considerably more through retry and dunning strategies.

How much of subscription churn is caused by failed payments?

Involuntary churn (subscribers lost to failed payments rather than active cancellation) accounts for an estimated 20 to 40% of total subscription churn, according to aggregated subscription-industry benchmarks, with some high-risk sectors reporting higher rates. Most of this churn is preventable through better routing, retries, and automatic credential updating.

What share of digital payments comes from digital wallets?

According to Worldpay’s Global Payments Report, digital wallets accounted for 56% of global e-commerce value and 33% of point-of-sale value in 2025, representing over USD 13.8 trillion in combined spending. In APAC the share is higher still, at 77% of online spending in 2025.

How much do authorization rates improve with payment orchestration?

Improvement depends on the business, its markets, and its previous setup, so there is no single universal figure. As a documented example, Baby Bunting reported a 2.8% uplift in authorization rates within the first four months of moving to an orchestrated dual-acquirer setup with failover routing, as stated in its Gr4vy case study. Gains come from routing each transaction to the provider most likely to approve it, plus retries and fallback logic. Domestic acquiring can also deliver 10 to 20% higher approval rates than cross-border processing, a gap orchestration addresses through local routing.

Where do these payment orchestration statistics come from?

The merchant-result figures come directly from Gr4vy’s published case studies (Baby Bunting, Ding, FuturHealth, Mattilda). The market and industry figures come from independent research organizations, including Grand View Research (market size and growth), Statista and Worldpay (digital payments and wallets), Capgemini (instant payments), Datos Insights and Cybersource (false declines), Juniper Research (fraud losses), PYMNTS Intelligence (failure causes), and the Merchant Risk Council (fraud trends). None of the industry figures come from payment vendors.

What the payment orchestration statistics show

Read together, the numbers tell a coherent story. Digital payments have become the dominant form of commerce, with global transaction value measured in the tens of trillions and digital wallets alone accounting for more than half of e-commerce spend. That shift multiplied the providers, methods, and markets a merchant has to manage, which is the complexity payment orchestration exists to handle, and it is why the orchestration market is growing at double-digit rates while remaining small relative to the payments industry overall.

At the same time, the decline, false-decline, and failed-payment figures quantify a large and mostly recoverable revenue leak: false declines alone are estimated to cost merchants far more than actual fraud, and the majority of failed payments come from system friction rather than customers who cannot pay. The merchant case-study results put concrete numbers on what addressing that leak can look like, from Baby Bunting’s authorization uplift to Ding’s collapse in integration time.

For a business weighing whether orchestration is worth evaluating, the most useful exercise is to measure its own equivalents of these figures: its current authorization and decline rates, its false-decline rate, the share of its failed payments caused by system friction, and the time it takes to launch a new payment method or market. Those numbers, measured honestly against the benchmarks above, show how much of the opportunity these statistics describe is actually present in the business.

Gr4vy is a cloud-native payment orchestration platform connecting merchants to more than 400 payment providers and methods through a single integration, with the routing, retries, and unified data behind the merchant results above. To see how these statistics might translate to your own payment operation, talk to our team.

Picture a large retailer on the busiest sales day of its year. Its single acquiring bank has an outage that lasts forty minutes. For those forty minutes, every card transaction fails. Customers have the funds and the checkout works fine; the problem is that the one institution authorized to process the retailer’s card payments is unreachable. The revenue lost in that window is gone, and no amount of checkout optimization would have saved it, because the failure was upstream of everything the merchant controlled.

That scenario, and several less dramatic versions of it, is why a growing number of enterprises no longer rely on a single acquirer. Concentrating all card volume with one acquiring bank means one set of approval rates, one pricing schedule, one geographic footprint, and one point of failure. A multi-acquirer strategy spreads that volume across several acquiring relationships and routes each transaction to the one best suited to approve it. The result is more resilience, better approval rates, lower costs, and broader reach, though running it well introduces real complexity of its own.

What an acquirer is, and why the relationship matters

An acquiring bank, or acquirer, is the financial institution that holds a merchant’s account and processes card payments on its behalf, receiving the funds from the customer’s issuing bank through the card networks and depositing them into the merchant’s account. The acquirer is the merchant’s entry point into the card system: it carries the merchant’s relationship with the card networks, takes on a degree of risk for the merchant’s transactions, and is the destination where settled money arrives.

Because the acquirer sits at this structural position, the acquiring relationship shapes several things at once. The acquirer’s connectivity to issuing banks affects how many transactions get approved. Its geographic reach determines which markets a merchant can serve well. Its pricing determines a meaningful part of the cost of every transaction. And its uptime determines whether payments flow at all. When a merchant has only one acquirer, all of these are fixed by that single relationship. This is a different concern from the number of payment service providers or gateways a merchant uses; the acquirer is specifically the licensed institution that settles the funds, which is why the acquiring layer is worth examining on its own. For the distinction between the acquirer and the other parties in the chain, see Gr4vy’s guide on card network versus payment processor.

What a multi-acquirer strategy is

A multi-acquirer strategy is an arrangement in which a merchant maintains relationships with more than one acquiring bank and directs transactions among them based on criteria such as geography, card type, cost, and performance. Rather than sending every transaction to a single acquirer by default, the merchant can send a Brazilian customer’s card to a local Brazilian acquirer, route a high-value European transaction to whichever European acquirer approves those best, and shift traffic away from any acquirer that is degraded or down.

The strategy rests on the fact that acquirers are not interchangeable. One acquirer may have strong issuer relationships in one region and weak ones in another. One may price certain card types or transaction types more favorably. One may support payment methods or currencies another does not. By holding several relationships and routing intelligently among them, a merchant stops being limited to the strengths and weaknesses of a single acquirer and starts using the best of each.

Why enterprises adopt a multi-acquirer strategy

Research into merchant acquiring behavior consistently surfaces the same handful of motivations. A survey by Edgar, Dunn & Company and ACI Worldwide found that the top three reasons merchants work with more than one acquirer were resilience, reducing operational costs, and improving conversion rates. The same study reported that 85 percent of merchants that moved to multiple acquirer relationships saw an increase in conversion rates, with 23 percent improving conversion by more than 10 percent, and that 71 percent were satisfied or very satisfied with the multi-acquiring approach. Those figures come from that specific study and are worth treating as directional rather than guaranteed, but they line up with the reasons enterprises give in practice.

Resilience and business continuity

The most cited reason is resilience. A single acquirer is a single point of failure: if it has an outage, a business failure, or a change in the kinds of business it is willing to handle, a merchant relying on it alone loses the ability to process payments. Multiple acquirer relationships mean that if one acquirer goes down, traffic can be routed to another and payments keep flowing. For a business where every minute of downtime is lost revenue, this alone can justify the strategy. Gr4vy’s guide on downtime in payments covers the outage risk in more depth.

Higher approval rates

Approval rates vary by acquirer, and the variation is largest across borders. Domestic acquirers commonly achieve meaningfully higher approval rates than cross-border processing for in-market cards, with industry sources frequently citing gains in the range of 10 to 20 percent when a local acquirer is used instead of a foreign one. The reason is that issuing banks tend to trust and approve transactions acquired locally more readily than the same transaction routed through a foreign acquirer, which can look riskier. A merchant with acquirers in its key markets can route each transaction to a local acquirer and recover approvals it would otherwise lose. This is one of the strongest and most measurable benefits, and it connects directly to the wider practice of lifting approval rates covered in Gr4vy’s guide on how to increase payment approval rates in 2026.

Lower costs and stronger negotiating position

Working with a single acquirer means accepting its pricing schedule with little bargaining power. Holding multiple acquirer relationships introduces competition: a merchant can route transactions to the acquirer with the most favorable rates for a given card type, region, or transaction type, and can negotiate better terms because it is not wedded to one provider. Over time, the ability to route on cost and to negotiate from a position of choice produces meaningful savings. Gr4vy’s guide on least cost routing explains the cost-routing mechanics.

Broader geographic and payment method reach

Different acquirers support different markets, currencies, and payment methods. A merchant expanding internationally often finds its incumbent acquirer is strong at home but weak in the new markets it wants to enter. Adding acquirers with strength in those markets, and the local methods they connect to, makes expansion viable in a way a single acquirer cannot. Gr4vy’s guide on card acquiring for international markets goes into the global, local, and cross-border considerations.

Better risk and chargeback management

Holding multiple acquiring relationships also lets a merchant monitor chargeback and fraud patterns across acquirers, identify where problems concentrate, and adjust routing accordingly. Spreading volume also avoids over-concentrating risk with any single acquirer, which matters because an acquirer that sees a merchant’s chargeback ratio climb can change terms or withdraw service.

The real challenges of running multiple acquirers

The benefits are real, and so are the difficulties. The competitor content on this topic tends to skip past the challenges, but they are the reason a multi-acquirer strategy is hard to run without the right infrastructure.

Integration complexity. Each acquirer has its own connection, its own technical requirements, and its own quirks. Integrating and maintaining several acquirer connections directly is a substantial and ongoing engineering effort, and every new acquirer adds to it.

Routing logic. Deciding which transaction goes to which acquirer, and doing it in real time based on geography, card type, cost, and live performance, requires routing logic that has to be built, maintained, and continuously tuned. Static rules decay as acquirer performance shifts.

Stored credentials and tokenization across acquirers. A card stored for use with one acquirer is not automatically usable with another. Without a provider-agnostic way to store credentials, routing a returning customer’s stored card to a different acquirer becomes a problem, particularly for subscriptions and card-on-file transactions.

Fragmented reporting. Each acquirer reports separately, in its own format. Reconciling and getting a unified view of performance across all of them is a real operational burden when done manually.

Compliance across relationships. Each acquiring relationship carries its own compliance obligations, and managing PCI scope, tokenization, and regulatory requirements across several at once adds overhead.

These challenges are exactly why a multi-acquirer strategy and payment orchestration are so closely linked. The strategy is the goal; orchestration is what makes it operationally feasible.

How payment orchestration operationalizes a multi-acquirer strategy

A multi-acquirer strategy without the right infrastructure means absorbing all the complexity above directly: integrating each acquirer, building the routing, solving the stored-credential problem, and stitching together the reporting. A payment orchestration platform is the layer that turns the strategy from an integration burden into a configuration exercise.

Orchestration addresses each of the challenges directly. It connects to multiple acquirers through a single integration, so adding an acquirer is a configuration step rather than a new engineering project. It provides the routing engine that directs each transaction to the best acquirer based on geography, card type, cost, and performance, and lets that logic be adjusted without code. It stores credentials in a provider-agnostic vault so a stored card can be routed to any acquirer, which is what makes multi-acquirer routing work for subscriptions and card-on-file. It handles failover automatically, rerouting around a degraded acquirer. And it unifies reporting across every acquirer into one view.

In other words, orchestration is the practical foundation of a multi-acquirer strategy. The strategy defines what a merchant wants (resilience, better approvals, lower cost, broader reach); orchestration is how a merchant achieves it without taking on unmanageable complexity. This is also why the multi-acquirer question sits inside the broader multi-provider conversation. For the wider strategy across payment service providers, see Gr4vy’s guides on building a multi-PSP payment strategy and multi-PSP credit card processing, and for the routing mechanics specifically, the guide on intelligent payment routing.

When a multi-acquirer strategy makes sense

Not every business needs multiple acquirers, and it is worth being clear about when the strategy earns its complexity.

The case is strongest for businesses that sell across multiple countries, where local acquiring delivers materially better approval rates and access to local payment methods; for businesses where payment downtime is expensive enough that resilience alone justifies a second acquirer; for high-volume businesses where routing on cost and negotiating from a position of choice produces meaningful savings; and for subscription and card-on-file businesses where recovering failed transactions by retrying through an alternate acquirer directly reduces involuntary churn.

The case is weaker for small, single-market businesses with modest volume and no cross-border ambitions, where a single reliable acquirer may be entirely sufficient and the added complexity would not pay for itself. As with most payment stack decisions, the strategy should follow the business’s actual needs rather than being adopted for its own sake.

Frequently asked questions

What is a multi-acquirer strategy?

A multi-acquirer strategy is an arrangement where a merchant maintains relationships with more than one acquiring bank and routes transactions among them based on factors such as geography, card type, cost, and performance. Instead of sending every transaction to a single acquirer, the merchant directs each one to the acquirer best suited to approve it, which improves resilience, approval rates, cost control, and geographic reach.

What is an acquirer in payments?

An acquiring bank, or acquirer, is the financial institution that holds a merchant’s account and processes card payments on its behalf. It receives funds from the customer’s issuing bank through the card networks and deposits them into the merchant’s account. The acquirer carries the merchant’s relationship with the card networks and is where settled money arrives, which is why the acquiring relationship shapes approval rates, cost, reach, and reliability.

Why do enterprises use more than one acquirer?

The most common reasons are resilience (so a single acquirer outage does not stop all payments), higher approval rates (especially by using local acquirers in different markets), lower costs and a stronger negotiating position, and broader geographic and payment-method reach. Research by Edgar, Dunn & Company and ACI Worldwide found resilience, cost reduction, and improved conversion to be the top three drivers, with most merchants that adopted multiple acquirers reporting higher conversion.

Does using multiple acquirers improve approval rates?

It can, particularly across borders. Domestic acquirers commonly achieve higher approval rates than cross-border processing for in-market cards, with industry sources frequently citing improvements in the range of 10 to 20 percent when a local acquirer is used instead of a foreign one, because issuing banks tend to approve locally acquired transactions more readily. Routing each transaction to a well-suited acquirer recovers approvals that a single acquirer would lose.

What is the difference between a multi-acquirer and a multi-PSP strategy?

A multi-acquirer strategy specifically concerns the acquiring banks that hold the merchant account and settle funds. A multi-PSP strategy concerns the payment service providers a merchant works with, which may bundle gateways, processing, and acquiring together. The two overlap, because a multi-acquirer strategy is often implemented through multiple providers, but the acquirer is the specific licensed institution that settles the money, which is why the acquiring layer is worth considering in its own right.

What are the challenges of a multi-acquirer strategy?

The main challenges are integration complexity (each acquirer has its own connection to build and maintain), routing logic (deciding and continuously tuning which transaction goes where), stored credentials across acquirers (a card stored for one acquirer is not automatically usable with another), fragmented reporting (each acquirer reports separately), and compliance across multiple relationships. These challenges are why a multi-acquirer strategy is typically implemented through a payment orchestration platform rather than by integrating each acquirer directly.

How does payment orchestration help with a multi-acquirer strategy?

Payment orchestration connects to multiple acquirers through a single integration, provides the routing engine that directs each transaction to the best acquirer, stores credentials in a provider-agnostic vault so stored cards can be routed to any acquirer, handles failover automatically, and unifies reporting across all acquirers. It turns a multi-acquirer strategy from a heavy, ongoing engineering effort into a configuration exercise, which is why the strategy and orchestration are so closely linked.

Does a multi-acquirer strategy reduce costs?

It can. Holding multiple acquirer relationships introduces competition, letting a merchant route transactions to the acquirer with the most favorable rates for a given card type or region and negotiate better terms from a position of choice instead of being tied to one provider’s schedule. Over time, cost-based routing and a stronger negotiating position can produce meaningful savings, though the size depends on volume and transaction mix.

How does a multi-acquirer strategy help with international expansion?

Different acquirers are strong in different markets. A merchant’s incumbent acquirer may perform well at home but poorly in new markets. Adding acquirers with strength in target markets provides higher local approval rates and access to local payment methods, making expansion viable in a way a single acquirer cannot support. Orchestration makes adding those acquirers a configuration step rather than a fresh integration for each market.

Is a multi-acquirer strategy worth it for a small business?

For a small, single-market business with modest volume and no cross-border plans, a single reliable acquirer is often sufficient, and the added complexity of multiple acquirers may not pay for itself. The strategy earns its complexity for businesses selling across multiple countries, those where downtime is costly, high-volume businesses that benefit from cost routing, and subscription businesses that recover failed payments by retrying across acquirers. The decision should follow the business’s actual needs.

Where this leaves enterprise payment teams

The move from a single acquirer to several is, at its core, a decision to stop being limited by one institution’s approval rates, pricing, reach, and uptime. For an enterprise selling across borders or at scale, those limits translate directly into lost approvals, higher costs, failed expansions, and exposure to outages that a single relationship cannot protect against. The survey data and the consistent experience of large merchants point the same way: spreading volume across multiple acquirers and routing intelligently among them improves resilience, conversion, and cost at once.

The reason more enterprises have not always done it is that running multiple acquirers directly is genuinely hard, between the integrations, the routing, the stored-credential problem, and the fragmented reporting. That difficulty is precisely what payment orchestration removes. The strategy defines the destination; orchestration is the vehicle that makes the journey manageable, turning what would be a standing engineering burden into rules a payments team can configure and adjust.

Gr4vy is a cloud-native payment orchestration platform that connects merchants to more than 400 payment providers and acquiring relationships through a single integration, with the routing, provider-agnostic vault, automatic failover, and unified reporting that make a multi-acquirer strategy practical to run. To explore what a multi-acquirer setup would look like for your markets and volume, talk to our team.

Every time a customer pays with a card, an invisible piece of infrastructure does the work of checking that the money exists, reserving it, and moving it from the customer’s bank to the merchant’s. That infrastructure is the payment processor. It is the engine that turns a tap, dip, or click into settled funds in a merchant’s account, and although customers never see it and most merchants rarely think about it, it sits in the path of every card transaction a business accepts.

Understanding what a payment processor does (and how it differs from the gateway, the acquirer, the card networks, and the payment service provider it is so often confused with) matters because the processor shapes the fees a business pays, the speed at which it receives funds, the share of transactions that get approved, and the reliability of the whole payment operation. What follows explains what a payment processor is, how it moves money step by step, the types and pricing models to know, and how to evaluate one.

Payment processor, defined

A payment processor is the company that manages the movement of a card transaction between the merchant, the card networks, and the banks, handling the authorization of the payment and the settlement of the funds. When a customer pays, the processor is the party that carries the authorization request to the customer’s bank, relays back the approve-or-decline decision, and then, later, moves the actual money from the customer’s bank to the merchant’s account.

Where a payment gateway captures and transmits the payment information, the processor acts on it. It communicates with the card networks and the issuing bank to authorize the transaction, and it handles the settlement process that transfers the funds. The processor is the operational engine of the payment: the component that does the work of moving money, as distinct from the component that collects the payment details.

Well-known payment processors include companies such as Stripe, Square, and PayPal, though many of these bundle processing with other functions. The pure processing role (authorize the transaction, settle the funds) is the core of what defines a processor, whatever else a given provider packages around it.

How a payment processor works, step by step

The processor’s role is clearest when followed through a single card transaction, from the moment a customer confirms payment to the moment the money lands in the merchant’s account. Two distinct phases are involved: authorization (real-time) and settlement (which follows later).

Authorization, in real time:

1. The transaction reaches the processor. After the gateway captures and encrypts the payment data at checkout, it passes the transaction to the processor. In an in-person sale, the point-of-sale terminal performs the capture role and hands the transaction to the processor.

2. The processor forwards an authorization request. The processor formats the transaction and sends an authorization request through the appropriate card network (Visa, Mastercard, and others) to the customer’s issuing bank.

3. The issuing bank decides. The issuing bank checks that the card is valid and that funds or credit are available, runs the transaction against its fraud and risk rules, and returns an approve-or-decline response.

4. The processor relays the decision. The response travels back through the card network to the processor, which passes it to the gateway and the merchant. If approved, the sale completes for the customer and the funds are placed on hold in the customer’s account.

Settlement, which follows later:

5. Transactions are batched. The merchant’s approved transactions are collected, typically batched together at the end of the business day.

6. The processor initiates settlement. The processor works with the card networks and banks to move the actual funds. The issuing bank transfers the money, the card network routes it, and it flows toward the merchant’s acquiring bank.

7. Funds reach the merchant. After the acquiring bank processes the settlement (and the processor’s and networks’ fees are accounted for), the funds are deposited into the merchant’s account, usually within one to three business days.

The distinction between authorization and settlement is the key thing to hold onto. Authorization is the instant approve-or-decline that happens while the customer waits. Settlement is the actual transfer of money that happens afterward, in batches. The processor is central to both, which is why it is described as the engine of the payment: it does not merely carry information, it drives the movement of funds. Gr4vy’s guide on payment settlement covers the settlement phase in depth, and the guide on how a credit card scheme works explains the card network’s role in the middle.

Payment processor versus gateway, acquirer, network, and PSP

The payment processor is constantly confused with the other components of the payment stack. Clean definitions of each:

• Payment processor: manages the authorization and settlement of the transaction, moving the request through the networks and the funds between banks. It handles the transaction mechanics and the money movement.
• Payment gateway: captures the payment data at checkout and transmits it securely to the processor. It handles the information while leaving the money movement to the processor. (Gr4vy’s guide on merchant account versus payment gateway covers the gateway and merchant-account roles.)
• Card network: the system (Visa, Mastercard, American Express, Discover) that routes transaction data between the issuing bank and the acquiring bank and sets the rules of the scheme. It facilitates the data transfer between banks. Gr4vy’s guide on card network versus payment processor draws this distinction in detail.
• Acquiring bank (acquirer): the merchant’s bank, which holds the merchant account and receives the settled funds.
• Payment service provider (PSP): a company that bundles several of these functions (often gateway plus processing plus the acquiring relationship) into one package, so a merchant can accept payments through a single provider. Gr4vy’s guide on what a PSP does explains the bundled model.

A useful mental model: the gateway is the front door where the payment enters, the processor is the engine that carries the request to the banks and moves the money, the card network is the road the request travels, and the acquirer is the merchant’s bank where the money arrives. Many modern providers combine the gateway and processor roles (and sometimes the acquiring relationship), which is exactly why the terms blur together in everyday use.

Types of payment processors

Processors can be grouped in a few ways that matter to a merchant’s decision.

By pricing and relationship model:

• Payment facilitators (aggregators) such as Square and PayPal place merchants under a shared master merchant account, which makes onboarding fast and simple but offers less customization. This model suits smaller businesses and those that want to start accepting payments quickly.
• Merchant account providers (ISOs/MSPs) set a business up with its own dedicated merchant account, which involves more underwriting but offers more control, often better rates at volume, and a more stable relationship. This model suits established and higher-volume businesses.

By channel:

• Front-end processors handle the authorization side: connecting to the card networks and routing the authorization request and response.
• Back-end processors handle the settlement side: moving the funds from the issuing bank to the acquiring bank.

Many processors handle both the front-end and back-end roles, but the distinction matters for understanding where different parts of the process happen and where problems can arise.

By integration approach: some processors are tightly bundled with a specific gateway or platform, while others are provider-agnostic and can be connected through different gateways or an orchestration layer. This affects how easily a business can change processors later.

Payment processing pricing models

Pricing is where processors differ most in ways that directly affect a merchant’s costs, and understanding the models is essential to evaluating any processor. Three main structures dominate.

Interchange-plus. The processor charges the underlying interchange fee (set by the card networks and passed through to the issuing bank) plus a transparent, fixed markup. This is generally the most transparent model, because the merchant can see the true network cost separately from the processor’s margin. It tends to be the most cost-effective for higher-volume and established businesses.

Flat-rate. The processor charges a single, simple rate for all transactions (for example a fixed percentage plus a small fixed fee), regardless of the underlying card type. This is predictable and easy to understand, which suits smaller businesses, but it can be more expensive overall because the processor builds a cushion into the flat rate to cover its own costs across all card types.

Tiered. The processor sorts transactions into tiers (typically labelled qualified, mid-qualified, and non-qualified) and charges different rates for each. This model is the least transparent, because how a transaction gets categorized is not always clear to the merchant, and transactions can be shifted into more expensive tiers in ways that are hard to predict.

Underlying all of these is interchange, the fee set by the card networks and paid to the issuing bank, which the processor passes through in one form or another. Because interchange is a cost every processor faces, the real comparison between processors comes down to the markup and the transparency of the model rather than the interchange itself. Gr4vy’s guide on credit card processing fees breaks down the full fee structure a merchant encounters.

What a payment processor affects in a business

The processor is not a neutral pipe; its performance and terms feed directly into several things a business cares about.

Cost of accepting payments. The processor’s pricing model and markup are a direct input to the total cost of every transaction, which at scale is a meaningful line item.

Authorization rates. How a processor connects to the networks and issuers, and how it handles retries and declines, affects how many transactions get approved. A processor with weaker connectivity to certain issuers or geographies approves fewer transactions there.

Speed of funding. How quickly the processor settles determines when a business actually receives its money, which affects cash flow, particularly for businesses operating on thin margins or tight cycles.

Reliability. If the processor has an outage, transactions fail. A business dependent on a single processor has no fallback when that processor goes down, which is one of the reasons businesses with significant volume connect to more than one.

Supported methods and markets. The processor determines which card types, currencies, and markets a business can serve. A processor with narrow coverage constrains where and how a business can sell.

How to choose a payment processor

The right processor depends on the business, but a consistent set of criteria applies.

Pricing model and total cost. Understand which pricing model the processor uses and model the true total cost against the business’s actual transaction mix and volume. Interchange-plus tends to favor higher-volume businesses through transparency; flat-rate favors simplicity for smaller ones. Look past the headline rate to the complete fee schedule.

Authorization performance. Ask about approval rates, particularly for the card types, issuers, and markets that matter to the business. Small differences in approval rates compound into significant revenue over time.

Funding speed. Confirm how quickly the processor settles funds, and whether that cadence works for the business’s cash-flow needs.

Supported methods and geographies. Check that the processor supports the payment methods, currencies, and countries the business needs now and plans to need soon.

Reliability and support. Consider the processor’s uptime and the quality of its support, since processing failures directly stop revenue. For businesses where downtime is costly, consider whether relying on a single processor is acceptable.

Integration and flexibility. Assess how the processor integrates and how hard it would be to change or add processors later. A business locked to a single processor has less negotiating power and less resilience than one that can route across several.

That last point is where growing businesses often reach the limits of a single processor. Depending on one processor means one set of authorization characteristics, one pricing relationship, and one point of failure. As volume and complexity grow, businesses commonly connect to multiple processors and route transactions across them to improve approval rates, control costs, and add redundancy, which is the role a payment orchestration layer plays above the individual processors. Gr4vy’s guides comparing payment orchestration and a payment processor and the full orchestration versus gateway versus processor comparison cover how that layer works.

Frequently asked questions

What is a payment processor in simple terms?

A payment processor is the company that moves a card payment through the system: it carries the authorization request to the customer’s bank, relays back the approve-or-decline answer, and then moves the actual funds from the customer’s bank to the merchant’s account. It is the engine that turns a card payment into settled money, handling both the real-time authorization and the later settlement of funds.

What is the difference between a payment processor and a payment gateway?

A payment gateway captures the payment details at checkout and transmits them securely. A payment processor acts on those details: it moves the authorization request through the card networks to the banks and handles the settlement of funds. The gateway handles the information; the processor handles the money movement. Many providers offer both, which is why the terms are often used interchangeably even though they describe different roles.

What is the difference between a payment processor and a card network?

A card network (such as Visa or Mastercard) is the system that routes transaction data between the customer’s issuing bank and the merchant’s acquiring bank and sets the scheme’s rules. A payment processor is the company that manages the transaction on the merchant’s behalf, sending the authorization request through the network and handling settlement. The network facilitates the data transfer between banks; the processor manages the transaction and moves the money.

How does a payment processor make money?

Processors earn revenue mainly through the fees they charge merchants for each transaction. Depending on the pricing model, this is either the interchange fee plus a transparent markup (interchange-plus), a single flat rate, or tiered rates. The interchange portion is set by the card networks and passed to the issuing bank; the processor’s own revenue comes from the markup it adds on top.

What are the main payment processing pricing models?

The three main models are interchange-plus (the network interchange fee plus a fixed, transparent markup), flat-rate (a single simple rate for all transactions), and tiered (transactions sorted into qualified, mid-qualified, and non-qualified tiers at different rates). Interchange-plus is the most transparent and often the most cost-effective at volume; flat-rate is the simplest; tiered is the least transparent.

What is the difference between authorization and settlement?

Authorization is the real-time step where the processor asks the customer’s bank to approve the transaction and reserve the funds; it happens in seconds while the customer waits. Settlement is the later step where the actual money is transferred from the customer’s bank to the merchant’s account, typically processed in batches at the end of the day and completed within one to three business days. The processor is central to both.

Do I need a payment processor and a payment gateway?

For online payments, a business generally needs both functions: the gateway to capture and transmit the payment data, and the processor to authorize the transaction and settle the funds. They can come from separate providers or be bundled together in a single package, which is what many payment service providers offer. The functions are distinct even when one company provides both.

How long does a payment processor take to deposit funds?

Most processors settle and deposit funds within one to three business days after the transaction, though the exact timing depends on the processor, the merchant’s account setup, and the batching schedule. Some offer faster or same-day funding options. Funding speed is worth confirming during evaluation because it directly affects a business’s cash flow.

Can a business use more than one payment processor?

Yes, and many growing businesses do. Using multiple processors provides redundancy so that a single processor outage does not stop all payments, lets a business route each transaction to whichever processor performs best for that card type or market, and preserves negotiating power. Connecting and routing across multiple processors is the role a payment orchestration layer performs above the individual processors.

What is the difference between a payment processor and a PSP?

A payment processor performs the specific function of authorizing and settling transactions. A payment service provider (PSP) is a company that bundles several payment functions together, typically including processing along with a gateway and an acquiring relationship, so a merchant can accept payments through one provider. A PSP includes processing as part of a broader package rather than being a distinct function.

How do I choose the right payment processor?

Evaluate the pricing model and true total cost against your transaction mix and volume, the authorization performance for your key card types and markets, funding speed, supported payment methods and geographies, reliability and support quality, and how easily you could add or change processors later. For a business expecting growth, it is also worth considering whether a single processor will remain sufficient or whether routing across several will eventually be needed.

The bottom line on processors

A payment processor is the engine of a card payment: the component that carries the authorization to the customer’s bank, brings back the decision, and moves the money to the merchant. It works alongside the gateway that captures the payment, the card networks that route the data, and the acquiring bank that receives the funds, and it is distinct from each of them even though modern providers often bundle several roles together. Its pricing model shapes what a business pays, its connectivity shapes how many transactions get approved, and its reliability shapes whether payments keep flowing.

For a single-market business, one well-chosen processor is often enough to start. The limits appear with growth, when depending on one processor means one set of approval characteristics, one pricing relationship, and one point of failure. That is when businesses tend to connect several processors and route across them, which is what a payment orchestration platform is built to coordinate: many processors and providers through one integration, with each transaction routed to the one most likely to serve it best.

Gr4vy is a cloud-native payment orchestration platform that connects merchants to more than 400 payment providers and methods through a single integration, sitting above individual processors to route, optimize, and add redundancy across all of them. To understand how processors fit into a broader payment strategy for your business, talk to our team.

Payment orchestration is easier to understand through what it does than through how it is defined. In the abstract, it is a layer that connects a business to many payment providers and routes transactions across them. In practice, that abstraction shows up as a private-school platform in Mexico cutting payment costs, a bike manufacturer unifying its online and in-store checkout, a global donation platform accepting local payment methods in dozens of countries, and a telehealth company lifting the share of transactions that get approved.

Looking at the concrete situations where businesses reach for orchestration is the fastest way to see whether it fits a given operation. The examples below are drawn from real Gr4vy customers, grouped by the problem orchestration solved for them, with the outcomes as reported in each company’s published case study. They cover the use cases that recur most often across industries: lifting authorization rates, cutting payment costs, launching white-label payments for sub-merchants, unifying payments across channels, expanding into new markets, and enabling payment experiences that would be hard to build alone.

Use case 1: Lifting authorization rates

The most common reason businesses adopt orchestration is that too many of their legitimate transactions are being declined. When a business routes every transaction through a single provider, it is stuck with that provider’s authorization performance for every card, market, and network. Orchestration lets each transaction take the path most likely to be approved, which recovers revenue that would otherwise be lost to avoidable declines.

Baby Bunting, the Australian baby-goods retailer, implemented Gr4vy’s orchestration layer and, as reported in its case study, secured a 2.8% uplift in authorization rates. On retail volume at that scale, a lift of that size represents a meaningful amount of recovered revenue that was previously being declined without the business ever seeing the customer intent behind it. Read the full account in the Baby Bunting case study.

FuturHealth, a telehealth company, turned to orchestration to boost authorization rates on its payment volume, an outcome documented in the FuturHealth case study. For subscription-heavy healthcare businesses, where recurring billing means a declined transaction can mean a lapsed patient relationship, authorization performance is directly tied to retention.

The mechanism behind these gains is routing combined with tools like retries, network tokenization, and fallback logic, which together give each transaction more than one chance to succeed and steer it toward the provider best suited to approve it. For the underlying detail on how this works, see Gr4vy’s guide on how to increase payment approval rates in 2026 and its explanation of intelligent payment routing.

Use case 2: Cutting payment costs

Every transaction carries cost, and when a business is locked to one provider it has little bargaining power over what it pays. Orchestration introduces competition among providers and lets a business route to the lowest-cost path that will still get the transaction approved, which turns payment cost from a fixed expense into something the business can actively manage.

Mattilda, a Mexico City company that provides collections management and payment processing for private schools across Latin America, cut its payment costs by 60% through orchestration, as reported in its case study. Mattilda achieved this while also expanding into new markets and, per the same case study, increasing acceptance rates by 20%. The company reached these outcomes by using orchestration to configure a tailored payment stack for each school it serves, with localized acquiring and the freedom to route for both cost and performance. The full story is in the Mattilda case study.

Cost reduction of this kind comes from several levers at once: routing to cheaper providers where they perform well, using local acquiring to avoid cross-border fees, and avoiding the interchange and scheme costs that pile up when transactions are forced through a single suboptimal path. Gr4vy’s guides on least cost routing and how to cut payment processing costs in 2026 cover the cost levers in detail.

Use case 3: Launching white-label payments for a platform

A distinct and fast-growing use case is the platform or marketplace that wants to offer payments to the businesses operating on it, under its own brand, without becoming a payment facilitator and taking on the full compliance and risk burden that entails. Orchestration provides the infrastructure to do this: dedicated, branded payment environments for each sub-merchant, managed from one place.

Mattilda is again a clear example. Rather than operating as a PayFac and absorbing the associated compliance and risk, Mattilda used Gr4vy’s white-label capability to launch Mattilda Pay, deploying dedicated payment environments for each school with a “bring your own acquirer” model that let each institution keep its own acquiring relationships while benefiting from a unified interface. This turned payments into what the case study describes as the company’s second-largest growth driver.

Woolworths Group selected Gr4vy to power the payments platform of Wpay, its payments business, as documented in the Wpay case study. For a large retail group running a payments platform that serves its own brands and external businesses, orchestration provides the multi-merchant infrastructure to do so at scale.

Aró Digital Strategy likewise selected Gr4vy as its orchestration platform, an arrangement described in the Aró case study. The pattern across all three is the same: a business that wants to offer payments to others uses orchestration as the infrastructure layer rather than building it or becoming a regulated payment entity itself.

For the structural context on the different roles in the payments chain and why a platform might choose orchestration over becoming a payment facilitator, Gr4vy’s guide on what a PSP does is useful background.

Use case 4: Unifying payments across channels

Businesses that sell both online and in person often end up with separate, disconnected payment setups for each channel, which fragments their data, complicates reconciliation, and creates an inconsistent customer experience. Orchestration can unify these channels under a single payment layer.

Trek, the bicycle manufacturer and retailer, used Gr4vy to unify payments across its digital and physical retail operations, as described in the Trek case study. Bringing online and in-store payments into one orchestrated layer gives a retailer like Trek a consistent view of payments across channels, unified reporting, and the ability to apply the same routing and optimization logic everywhere it sells, rather than maintaining separate stacks that each behave differently.

This omnichannel use case is increasingly common as the line between online and physical retail blurs, and businesses want the customer’s payment experience and their own back-office view to be coherent across every place a sale can happen.

Use case 5: Expanding into new markets

Entering a new country means supporting the payment methods local customers actually use and, ideally, acquiring locally to lift approval rates and reduce cross-border costs. Building each of those integrations directly is slow. Orchestration gives a business access to local methods and acquirers through one integration, which turns market expansion from an engineering project into a configuration exercise.

Ding, the international mobile top-up service, called on Gr4vy to accelerate its international expansion, as reported in the Ding case study. For a business whose customers are spread across many countries, the ability to add local payment methods and acquiring without building each integration from scratch is what makes fast expansion feasible.

Mattilda’s expansion across Latin American markets, with Colombia identified as a next step in its case study, was similarly enabled by orchestration’s fast access to local payment methods and PSPs. In both cases, the pattern is that orchestration removes the integration bottleneck that would otherwise gate entry into each new market. Gr4vy’s guide on best practices for international payments covers the wider approach.

Use case 6: Powering donations and nonprofit payments

Nonprofits and donation platforms have payment needs that look much like commerce, plus a particular sensitivity to fees (since every point of cost is money that does not reach the cause) and a need to accept payments from donors across many countries and methods.

JustGiving, one of the largest online fundraising platforms, used Gr4vy to optimize its global donations, as documented in the JustGiving case study. Optimizing donation payments across many countries means accepting local payment methods, lifting the share of donations that are successfully processed, and keeping costs down so more of each donation reaches its destination, all of which are core orchestration capabilities applied to a donation context rather than a retail one.

Use case 7: Enabling payments on streaming and OTT platforms

Streaming and over-the-top media platforms run on recurring subscription revenue across a broad, often international, subscriber base, which makes payment acceptance and retention of active subscriptions central to the business.

Setplex, an OTT platform provider, chose Gr4vy to empower payment acceptance on its platform, as described in the Setplex case study. For an OTT business, orchestration supports the recurring billing, broad payment-method acceptance, and decline recovery that keep subscribers active and revenue flowing, across whichever markets the platform serves.

Use case 8: Enabling new payment experiences

Beyond optimizing existing flows, orchestration gives businesses fast access to new payment experiences and technologies that would be slow or complex to build independently, because the orchestration layer already integrates them.

Gr4vy’s work on sports payments using Mastercard Click to Pay, described in the sports payments case study, is an example: orchestration made it straightforward to bring a faster, fewer-step checkout experience to a sports payments context by drawing on a capability already available through the platform. The general pattern is that when a new payment method, authentication technology, or checkout experience becomes available, a business on an orchestration layer can adopt it through configuration rather than a fresh integration, which is also why orchestration is central to how businesses are preparing for developments like agentic commerce.

The common thread across these use cases

Different as these businesses are, a private-school collections platform, a bike retailer, a telehealth provider, a donation platform, an OTT service, a mobile top-up company, the reason they reach for orchestration rhymes. Each one hit a limit that a single-provider setup could not solve: authorization rates capped by one provider’s performance, costs fixed by one provider’s pricing, expansion gated by integration work, channels fragmented across disconnected systems, or a new capability that would take too long to build alone.

Orchestration addresses all of these through the same underlying move: putting a flexible layer between the business and its payment providers, so the business can route, optimize, expand, and adopt without being constrained by any single provider. The specific benefit that matters most varies by business, which is why the use cases look so different on the surface even though the underlying capability is the same.

The table below summarizes the patterns and the businesses that illustrate them:

Use case	The limit it addresses	Illustrative example
Lifting authorization rates	Approval capped by one provider	Baby Bunting, FuturHealth
Cutting payment costs	Cost fixed by one provider	Mattilda
White-label platform payments	Building or becoming a PayFac	Mattilda, Wpay, Aró
Unifying channels	Fragmented online and in-store stacks	Trek
Market expansion	Integration work gating new markets	Ding, Mattilda
Donations and nonprofit	Fees and global method coverage	JustGiving
Streaming and OTT	Recurring billing and retention	Setplex
New payment experiences	Slow to build new capabilities alone	Sports payments with Click to Pay

Frequently asked questions

What is payment orchestration used for?

Payment orchestration is used to connect a business to multiple payment providers through one integration and route each transaction across them intelligently. In practice, businesses use it to lift authorization rates, reduce payment costs, expand into new markets, unify payments across online and in-store channels, offer white-label payments to sub-merchants, and adopt new payment methods and experiences quickly. The specific use that matters most depends on the business.

What kinds of businesses use payment orchestration?

A broad range: retailers, telehealth and healthcare providers, education and collections platforms, donation and fundraising platforms, streaming and OTT services, mobile and telecom businesses, marketplaces, and payment platforms that serve their own sub-merchants. The common factor is that they have outgrown what a single payment provider can deliver, whether in authorization performance, cost, geographic reach, or flexibility.

How does payment orchestration improve authorization rates?

It routes each transaction to the provider most likely to approve it and adds retries, network tokenization, and fallback logic so a transaction that fails on one path can succeed on another. Gr4vy customers have reported measurable gains: Baby Bunting reported a 2.8% authorization-rate uplift, and Mattilda reported a 20% increase in acceptance rates, each as documented in their respective case studies.

Can payment orchestration reduce payment costs?

Yes. By introducing competition among providers and routing to the lowest-cost path that will still get a transaction approved, orchestration turns payment cost into something a business can actively manage. Mattilda reported cutting payment costs by 60% through orchestration, as documented in its case study, achieved alongside market expansion and higher acceptance rates.

How does payment orchestration help with international expansion?

Entering a new market requires supporting local payment methods and, ideally, local acquiring. Orchestration provides access to those methods and acquirers through a single integration, so adding a market becomes a configuration exercise rather than a fresh engineering project for each one. Ding used Gr4vy to accelerate international expansion, and Mattilda used it to expand across Latin American markets, both as described in their case studies.

What is white-label payment orchestration?

White-label orchestration lets a platform or marketplace offer branded payment experiences to the businesses operating on it, with dedicated payment environments for each, without becoming a payment facilitator and taking on the associated compliance and risk. Mattilda used this model to launch Mattilda Pay for the schools it serves, and Woolworths Group’s Wpay uses Gr4vy to power its payments platform, both documented in their case studies.

Can payment orchestration unify online and in-store payments?

Yes. Businesses that sell across both channels often run separate payment setups that fragment data and reporting. Orchestration can bring both channels under one layer for a consistent customer experience, unified reporting, and the same routing and optimization logic everywhere. Trek used Gr4vy to unify payments across its digital and physical retail operations, as described in its case study.

Is payment orchestration only for large enterprises?

The largest, most measurable gains often appear at high volume, but the underlying benefits (provider flexibility, better authorization rates, cost control, faster expansion, and data ownership) apply well beyond the largest enterprises. The businesses that benefit most are those that have outgrown a single-provider setup, which happens across a wide range of sizes depending on the complexity of the business’s markets and payment needs.

How quickly can a business adopt a new payment method with orchestration?

Because the orchestration layer already integrates a wide range of payment methods and providers, a business can typically add a new method through configuration rather than building a new integration each time. This is what lets businesses on an orchestration layer adopt new payment experiences, such as Click to Pay or emerging methods, far faster than they could by integrating each one directly.

Where can I see real examples of payment orchestration in use?

Gr4vy publishes case studies covering customers across retail, healthcare, education, donations, streaming, and platform payments, including Baby Bunting, FuturHealth, Mattilda, Trek, Ding, JustGiving, Setplex, Wpay, and others. Each documents the specific problem the business faced and the outcome it reported, and they are collected on Gr4vy’s case studies page.

Seeing the pattern in your own operation

The value of looking at orchestration through use cases is that it makes the fit obvious or not. A business feeling the specific pain in one of the examples above (declines it cannot explain, payment costs it cannot move, a new market it cannot enter quickly, channels that will not reconcile, or a capability it cannot build fast enough) is looking at the exact problem orchestration was designed to solve. A business with none of those pains may not need it yet, and that is a legitimate conclusion too.

What the real examples show is that the benefit is rarely theoretical. Baby Bunting’s 2.8% authorization uplift, Mattilda’s 60% cost reduction and new business line, Trek’s unified channels, and Ding’s faster expansion are specific outcomes tied to specific problems, each reported in the companies’ own case studies. The way to evaluate orchestration for a given business is to identify which of these problems it actually has, and how much solving them is worth.

Gr4vy is a cloud-native payment orchestration platform used by businesses across retail, healthcare, education, donations, streaming, and platform payments to route, optimize, and scale their payments through a single integration. To talk through which of these use cases maps to your own operation, get in touch with our team.

By the time an enterprise sits down to evaluate payment orchestration platforms, the shortlist tends to look frustratingly similar. Every vendor claims hundreds of connectors, intelligent routing, high uptime, and a single integration. The marketing pages are near-interchangeable. The hard part of the decision is not finding candidates; it is telling them apart on the dimensions that will actually matter once the platform sits at the center of the payment stack and every transaction flows through it.

This is a decision worth getting right, because the orchestration layer becomes load-bearing infrastructure. A weak choice locks a business into suboptimal routing, fragmented visibility, and a migration project it will not want to repeat. What follows is a vendor-neutral framework for running the evaluation: how to scope requirements, build a shortlist, apply the criteria that separate platforms at enterprise scale, pressure-test the finalists, and handle the commercial and implementation due diligence before committing.

Start with requirements, not vendors

The most common evaluation mistake is starting from a list of platforms and comparing their feature grids. That approach lets vendors define the criteria, and it rewards whoever has the longest feature list rather than whoever fits the business best. The stronger approach starts with a clear picture of the business’s own payment operation, then measures platforms against it.

Before looking at any platform, document the following:

• Current stack. Which PSPs, acquirers, gateways, fraud tools, and payment methods are in use today, and how they are integrated.
• Volume and geography. Transaction volume, the markets that drive it, and the markets the business plans to expand into.
• Current shortcomings. Where the current setup falls short: authorization rates, cost, downtime, slow time-to-market for new methods, fragmented reporting, or engineering bottlenecks.
• Payment methods that matter. The specific cards, wallets, and local methods that carry meaningful volume in priority markets, now and in the near future.
• Success metrics. What the platform is expected to improve, expressed as targets: authorization rate, cost per transaction, provider performance, retry recovery, time-to-launch for new methods.

This requirements picture becomes the scorecard. Platforms are then evaluated on how well they serve this specific operation, which keeps the process grounded in the business’s reality rather than the vendor’s positioning. For the foundational context on what these platforms do, Gr4vy’s guide on what a payment orchestrator is and its overview of what a payment orchestration platform is and why a business needs one are useful groundwork before an evaluation begins.

The criteria that actually separate platforms

Connector counts and routing claims have reached rough parity across the serious platforms, so the differentiation has moved elsewhere. Eight criteria carry the most weight in an enterprise evaluation.

1. Depth of coverage in your priority markets

Total connector count is a vanity metric. What matters is the quality and depth of coverage in the specific markets that drive the business’s volume. A platform with a thousand global connectors but shallow support for the local acquirers and payment methods in a business’s two biggest markets is worse than one with fewer connectors but real depth where it counts. Verify the local acquirers, methods, and currencies for priority countries specifically.

2. Routing intelligence and recovery

Basic rule-based routing is table stakes. The meaningful differences are in how sophisticated the routing logic can get, how well it recovers failed transactions through retries and fallback, and whether routing decisions can be tested and adjusted without engineering work. Ask how routing rules are built, who can change them, and how the platform handles a declined transaction that could succeed through a different provider.

3. Provider neutrality

This is one of the most important and least discussed criteria. Some orchestration providers also operate their own payment rails or acquiring, which creates a structural incentive to route volume toward their own products regardless of whether that serves the merchant’s approval rate and cost. A neutral platform has no financial stake in where volume routes, so its routing optimizes purely for the merchant’s performance. Ask directly whether the platform earns money from where transactions are routed.

4. Data ownership and portability

The orchestration layer sits on top of the business’s most valuable payment data, including stored credentials and transaction history. If that data is locked to the platform, switching later becomes prohibitively hard, which is its own form of vendor lock-in. Confirm that the business owns and can export its tokens and transaction data, and understand what a future migration away from the platform would actually involve. Gr4vy’s guide on payment data portability and avoiding vendor lock-in covers why this matters.

5. Security, compliance, and certifications

The platform handles cardholder data, so its compliance posture is non-negotiable. Confirm current PCI DSS Level 1 certification, understand how the platform reduces the business’s own PCI scope, and check its approach to tokenization, encryption, and data residency in regulated markets. Gr4vy’s analysis of PCI DSS compliance and payment orchestration sets out what to look for.

6. Reliability and redundancy

Because the orchestration layer becomes the center of the payment stack, its own uptime is now the business’s uptime. Evaluate the uptime track record and the SLA, and understand the platform’s own architecture for redundancy. A platform that introduces a single point of failure at the center of the stack undermines one of the main reasons to adopt orchestration in the first place.

7. Operational control and reporting

Payments teams live in the platform day to day. Evaluate whether the team can build and change routing rules, run experiments, and access unified reporting across all providers without filing engineering tickets for every change. Fragmented reporting across providers is a common problem that orchestration is meant to solve, so confirm the platform actually delivers a single, coherent view.

8. Integration model and engineering effort

Assess how the platform integrates, the quality of its APIs, SDKs, and documentation, and how much engineering effort the initial integration and ongoing operation require. A platform that demands constant engineering involvement for routine payment changes has not delivered the operational independence that orchestration promises.

A criteria scorecard

A structured way to compare finalists on the criteria above:

Criterion	What to verify	Why it matters
Market coverage depth	Local acquirers, methods, currencies in priority markets	Shallow local coverage undermines the whole value in your key markets
Routing and recovery	How rules are built and changed, retry and fallback behavior	This is where authorization-rate gains come from
Provider neutrality	Whether the platform profits from routing decisions	Non-neutral routing may optimize for the vendor, not you
Data ownership	Token and data export, migration path out	Locked data is lock-in and a future migration risk
Security and compliance	PCI DSS Level 1, scope reduction, data residency	The layer handles cardholder data; this is non-negotiable
Reliability	Uptime record, SLA, redundancy architecture	The platform’s uptime becomes your uptime
Operational control	Rule changes and reporting without engineering	Determines whether the team gains real independence
Integration effort	API and SDK quality, documentation, ongoing effort	Determines total cost and time-to-value

Weighting the criteria to the business’s own priorities (a cross-border business weights market depth and neutrality heavily; a business burned by outages weights reliability) turns this into a decision tool rather than a generic checklist. For a complementary view of the specific capabilities to look for, Gr4vy’s guide on the top features every payment orchestration platform should have goes deeper on the feature set.

How to pressure-test a shortlist

Marketing pages and demos show platforms at their best. The evaluation needs to go further and test the finalists against the business’s actual requirements. Several techniques separate real capability from positioning.

Test against your real scenarios. Bring the platform your specific routing needs, your priority markets, and your most complex payment flows (refunds, chargebacks, recurring billing, multi-currency settlement) and ask exactly how each would work. Vague answers to specific scenarios are a warning sign.

Ask about the failure modes. Ask what happens when a provider goes down, how a failed transaction is recovered, and what the fallback logic looks like. The quality of these answers reveals how mature the routing and resilience really are.

Verify the neutrality claim. Ask directly whether the platform operates its own acquiring or payment rails and whether it earns money based on where transactions route. The answer determines whether routing recommendations reflect the business’s performance or the vendor’s margin.

Probe the migration path, in both directions. Understand what onboarding actually involves and, just as importantly, what leaving would involve. A platform confident in its value will be straightforward about how a business could export its data and move on. Evasiveness here signals lock-in.

Talk to reference customers with similar profiles. A platform that works well for a domestic subscription business may not suit a cross-border marketplace. Seek references that match the business’s own model and markets.

Involve the right internal stakeholders. Choosing an orchestration platform is a payments decision, an architecture decision, a security decision, and a finance decision at once. The evaluation should include payments, engineering, security, and finance, because each will surface requirements the others miss. As the developer-focused analyses of this category point out, the choice is as much an architecture decision as a payments one.

The commercial and contractual due diligence

Beyond capability, the commercial terms deserve the same scrutiny as the technology.

Pricing structure. Understand exactly how the platform charges (per transaction, tiered, subscription, or a blend) and model it against the business’s actual and projected volume. Confirm there are no fees that scale in ways that become punitive as volume grows.

Total cost against value. Orchestration carries a platform cost, and the case for it rests on offsetting that cost through authorization-rate gains, provider competition, reduced downtime, and lower engineering overhead. Industry analyses commonly cite meaningful revenue loss from failed payments and meaningful acceptance-rate gains from orchestration, but the honest way to evaluate this is to model the specific expected improvement against the specific cost for the business in question, rather than relying on a headline figure. Gr4vy’s guide on build versus buy for payment orchestration works through the cost comparison against building in-house.

Contract flexibility. Understand the commitment term, what happens at renewal, and whether the terms allow the business to add or change providers freely. The point of orchestration is flexibility, so a contract that constrains it works against the purpose.

Support and service model. Understand what support is included, how implementation is handled, and what the ongoing service relationship looks like. For infrastructure at the center of the payment stack, the quality of the support relationship matters as much as the product.

Gr4vy’s guide on questions to ask a payment processor offers a complementary set of pointed questions that apply well to orchestration vendors too.

Common evaluation mistakes

A few patterns lead businesses to the wrong choice.

Counting connectors. The longest integration list rarely correlates with the best fit. Depth in the markets that matter beats breadth almost every time.

Letting the vendor set the criteria. Evaluating platforms on the dimensions their marketing emphasizes rewards positioning over fit. The business’s own requirements should define the scorecard.

Ignoring neutrality. Overlooking whether a platform profits from routing decisions can mean adopting a layer whose routing quietly optimizes for the vendor rather than the business.

Underweighting data portability. Focusing only on onboarding and never asking about the exit leads to the exact lock-in that orchestration is supposed to prevent.

Treating it as purely a payments decision. Leaving engineering, security, and finance out of the evaluation means missing architecture, compliance, and commercial requirements until after the contract is signed.

Skipping the pressure test. Choosing on demos and marketing rather than testing against real scenarios and failure modes leads to surprises once the platform is carrying live volume.

Frequently asked questions

What is the most important factor when choosing a payment orchestration platform?

There is no single factor, because the right weighting depends on the business. That said, three considerations are consistently underrated: depth of coverage in the business’s specific priority markets rather than total connector count, provider neutrality (whether the platform profits from where transactions route), and data portability (whether the business owns and can export its data). These separate platforms that fit from platforms that merely look impressive.

How is choosing an orchestration platform different from choosing a PSP?

A PSP is one provider that processes payments. An orchestration platform sits above multiple PSPs and routes between them. Choosing a PSP is choosing a single processing relationship; choosing an orchestration platform is choosing the control layer that will manage all of those relationships. The orchestration decision is therefore more of an architecture decision, with longer-term consequences for flexibility, data ownership, and how the whole payment stack evolves.

What is provider neutrality and why does it matter?

Provider neutrality means the orchestration platform has no financial stake in where transactions are routed, so its routing optimizes purely for the merchant’s approval rate and cost. Some orchestration providers also operate their own acquiring or payment rails, which creates an incentive to route volume toward their own products. A neutral platform’s routing recommendations reflect the merchant’s performance data rather than the vendor’s margin, which is why it is worth verifying directly during evaluation.

How long does it take to implement a payment orchestration platform?

It varies with the complexity of the existing stack and the number of providers and markets involved. The more useful question during evaluation is what the implementation actually requires from the business’s own engineering team, how much of the integration work the platform handles, and what the realistic timeline looks like for the specific scope. Ask finalists to walk through implementation for a business of similar profile.

Should we build payment orchestration in-house instead of buying?

Building in-house gives maximum control but requires significant and ongoing engineering investment to build and maintain the connectors, routing logic, tokenization, and compliance that a platform provides out of the box. The decision hinges on whether payments are a core competency the business wants to own and resource permanently, or infrastructure it would rather buy. The tradeoffs are covered in depth in the build-versus-buy comparison.

How do we evaluate the cost of a payment orchestration platform?

Model the platform’s specific pricing against the business’s actual and projected volume, then weigh it against the expected value: authorization-rate improvement, savings from provider competition, reduced downtime, and lower engineering overhead. Rather than relying on headline industry figures for revenue recovery, estimate the specific improvement expected for the business and compare it to the specific cost. Watch for fees that scale punitively as volume grows.

What questions should we ask orchestration vendors?

Ask how routing rules are built and who can change them, what happens when a provider goes down, whether the platform profits from routing decisions, whether the business owns and can export its data, what a migration away would involve, what the uptime SLA is, and what the total cost looks like at projected volume. Bring specific scenarios from the business’s own operation and ask exactly how each would be handled.

Does the orchestration platform’s own uptime matter?

Yes, significantly. Once orchestration sits at the center of the payment stack, its uptime becomes the business’s uptime. A platform that introduces a single point of failure undermines one of the core reasons to adopt orchestration. Evaluate the uptime record, the SLA, and the redundancy architecture, and favor platforms designed so that the orchestration layer itself is not a single point of failure.

Who should be involved in the evaluation?

Choosing an orchestration platform is simultaneously a payments, architecture, security, and finance decision. The evaluation should include the payments team (routing and operations), engineering (integration and architecture), security and compliance (data handling and certifications), and finance (commercial terms and cost modeling). Leaving any of these out tends to surface missed requirements after the contract is signed.

How do we avoid vendor lock-in with an orchestration platform?

Confirm before signing that the business owns its payment data and stored credentials, that tokens and transaction data can be exported, and that there is a realistic path to migrate away if needed. A platform confident in its value will be transparent about the exit. Data portability is the single most important defense against lock-in, because the orchestration layer sits on top of the business’s most valuable and hardest-to-move payment data.

Is the platform with the most integrations the best choice?

Usually not. Total connector count is a surface metric that rarely correlates with fit. A platform with deep, high-quality coverage of the specific acquirers and payment methods in a business’s priority markets serves that business better than one with a longer global list but shallow local depth. Match the coverage to the markets that actually drive volume.

Making the decision

The reason orchestration platforms are hard to tell apart is that they have converged on the same surface-level claims. The way through is to stop comparing feature grids and start measuring each platform against a clear picture of the business’s own payment operation: its markets, its volume, its friction, and the metrics it needs to move. Against that scorecard, the differences that matter (depth in priority markets, genuine routing intelligence, provider neutrality, data ownership, reliability, and real operational control) become visible in a way they never are on a marketing page.

The evaluation is worth the effort because the orchestration layer is not a component that can be swapped out casually once it sits at the center of the stack. Running a disciplined process (requirements first, a weighted scorecard, a genuine pressure test of the finalists, and clear-eyed commercial and data-portability due diligence) is what separates a choice the business will be glad of in three years from one it will be trying to migrate away from.

Gr4vy is a cloud-native, PSP-agnostic payment orchestration platform built so that the business keeps ownership of its data and its provider relationships, with no financial stake in where transactions route. If you are running an evaluation and want to see how a neutral orchestration layer would map to your specific markets and stack, arrange a walkthrough with our team.

A payment gateway is the technology that captures a customer’s payment details at checkout, encrypts them, and transmits them securely to the systems that authorize and process the transaction. It is the entry point for nearly every card and digital payment a business accepts, the component that stands between the moment a customer clicks “pay” and the moment their bank approves or declines the charge.

Almost every online business relies on one, yet the gateway is one of the most misunderstood pieces of the payment stack, routinely confused with payment processors, acquirers, and payment service providers. Getting the distinctions right matters, because the gateway’s capabilities shape checkout conversion, security obligations, the payment methods a business can offer, and how well payments scale as the business grows. What follows is a plain explanation of what a payment gateway is, how it works step by step, the types available, the security standards involved, and how to evaluate one.

Payment gateway, defined

A payment gateway is a software service that securely collects a customer’s payment information and transmits it between the customer, the merchant, and the financial institutions that approve and settle the payment. It performs three core jobs: it captures the payment data at the point of checkout, it encrypts that data so it can travel safely, and it relays the authorization request and response between the merchant and the wider payment system.

The gateway does not itself move money. It moves information. The actual transfer of funds is handled by processors, acquirers, and banks further down the chain. The gateway’s role is to be the secure conduit that carries the payment request into that system and carries the approve-or-decline answer back out. This distinction (information versus funds) is the single most useful thing to understand about a gateway, because it explains why a gateway alone is not enough to accept a payment and why it always works alongside other components.

Gateways handle payments across channels: online checkouts, in-app purchases, and in-person point-of-sale terminals all rely on a gateway to capture and transmit payment data. For card-not-present transactions in particular (online and in-app), the gateway is essential, because there is no physical card or terminal to secure the data at the point of sale.

How a payment gateway works, step by step

The gateway’s role is easiest to understand by following a single card transaction from checkout to approval. A typical online card payment moves through the following sequence, all of which happens in a few seconds.

1. The customer enters payment details. At checkout, the customer provides their card number, expiry, and security code, or authorizes a stored card or digital wallet. This happens on the merchant’s site, in an app, or on a page hosted by the gateway.

2. The gateway encrypts the data. The gateway secures the sensitive payment information using encryption protocols (TLS in transit) so that the card data cannot be read as it travels. In modern implementations, the data is also often tokenized, replacing the card number with a token so the raw number is never exposed to the merchant’s systems.

3. The gateway transmits the authorization request. The encrypted, tokenized transaction is passed to the payment processor, which formats it and forwards an authorization request through the appropriate card network (Visa, Mastercard, and others).

4. The card network routes to the issuing bank. The network passes the request to the customer’s issuing bank, which checks that the card is valid, that sufficient funds or credit are available, and that the transaction does not trip fraud or risk rules. Where regulations require it, strong customer authentication (such as 3D Secure) is applied at this stage.

5. The issuing bank approves or declines. The bank returns an authorization response (approved or declined, with a reason code if declined) back through the card network to the processor.

6. The gateway relays the response. The processor passes the response back to the gateway, which communicates the result to the merchant and the customer. If approved, the order proceeds; if declined, the customer is prompted accordingly.

7. Settlement follows later. Approval places a hold on the funds, but the actual movement of money happens during settlement, typically in batches at the end of the day. The issuing bank transfers the funds, which arrive in the merchant’s account after the acquirer processes the settlement, usually within a couple of business days.

The important nuance most explanations blur is that authorization and settlement are two separate events. The gateway’s most visible work happens during authorization (the real-time approve-or-decline in steps 1 through 6). Settlement, the actual transfer of funds, happens afterward and involves the acquirer and the banks more than the gateway.

Payment gateway versus processor, acquirer, and PSP

The gateway is one of several components in the payment stack, and it is constantly confused with the others. A clean disambiguation:

• Payment gateway: captures and transmits payment data securely between the merchant and the processing system. It handles the information.
• Payment processor: takes the transaction from the gateway, formats it, and moves the authorization request through the card networks to the banks, then handles the mechanics of settlement. It handles the transaction mechanics and the money movement.
• Acquiring bank (acquirer): the merchant’s bank, which holds the merchant account, receives the settled funds, and carries the financial relationship with the card networks on the merchant’s behalf.
• Payment service provider (PSP): a company that bundles several of these functions together, often providing the gateway, processing, and acquiring relationship in a single package so a merchant does not have to assemble them separately.

A helpful way to hold the distinction: the gateway is the front door where the payment request enters, the processor is the courier that carries the request through the network and moves the funds, and the acquirer is the merchant’s bank that receives the money at the end of the flow. Many modern providers combine these roles, which is why the terms get used loosely, but they remain distinct functions.

For a deeper treatment of how these roles interact and where a payment orchestration layer fits above them, see Gr4vy’s guide on payment orchestration vs payment gateway vs payment processor, the breakdown of what a PSP does, and the comparison of card networks versus payment processors.

The main types of payment gateway

Gateways differ mainly in where the payment data is captured and how much of the checkout the merchant controls. Three models dominate.

Hosted (redirect) gateways

The customer is redirected from the merchant’s site to a payment page hosted by the gateway provider, completes payment there, and returns to the merchant’s site afterward. The merchant never handles card data, which keeps its security and compliance burden low. The trade is less control over the checkout experience and a redirect that can introduce friction. Hosted gateways suit businesses that want the simplest, lowest-compliance route to accepting payments.

Self-hosted / API gateways

The merchant captures payment data directly in its own checkout and passes it to the gateway through an API. This gives the merchant full control over the checkout experience and branding, at the cost of a significantly higher security and compliance burden, because card data flows through the merchant’s environment. This model suits businesses with the engineering resources and compliance maturity to manage it.

Hosted fields (the middle ground)

Secure input fields served by the gateway are embedded directly inside the merchant’s own checkout page, so the customer stays on the merchant’s site while the sensitive card data is captured inside the gateway’s isolated fields. This combines much of the control of the API model with much of the reduced compliance burden of the hosted model, which is why it has become the common choice for many enterprise checkouts.

The choice between these models is a meaningful decision in its own right, with implications for conversion, PCI compliance scope, and engineering effort. Gr4vy’s guide on hosted checkout versus API checkout works through the tradeoffs in detail.

Security and compliance: what a gateway must handle

Because a payment gateway handles sensitive card data, security is central to what it does, and it operates under specific standards.

PCI DSS compliance. Any system that touches cardholder data must comply with the Payment Card Industry Data Security Standard. The current version, PCI DSS 4.0.1, tightened requirements around stored data, script integrity, and authentication. A gateway’s design has a direct effect on how much of the PCI burden falls on the merchant: hosted and hosted-fields models can substantially reduce the merchant’s compliance scope, while a full API integration expands it.

Encryption. Gateways encrypt payment data in transit (and often at rest) so that card details cannot be intercepted and read as they move between the customer, the gateway, and the processor.

Tokenization. Modern gateways commonly replace the card number with a token, so the actual number is never stored in or exposed to the merchant’s systems. Network tokenization goes a step further by using a network-issued token that updates automatically when the underlying card is reissued, which improves both security and authorization rates. Gr4vy’s guide on how network tokenization works covers the mechanism.

Authentication. For card-not-present transactions in regulated markets, gateways support 3D Secure and the strong customer authentication that regulations such as PSD2 require. Gr4vy’s guide on implementing 3D Secure explains how this layer works.

For the specific interaction between compliance and a broader orchestrated payment stack, see Gr4vy’s analysis of PCI DSS compliance and payment orchestration.

What a payment gateway affects in a business

The gateway does more than pass data along. Its capabilities influence several things that matter directly to revenue and operations.

Checkout conversion. A slow, clunky, or redirect-heavy gateway experience causes cart abandonment. A smooth, fast, well-integrated gateway keeps customers moving through checkout.

Authorization rates. How a gateway handles tokenization, retries, and the data it passes to issuers affects how many transactions get approved. Small differences in approval rates compound into meaningful revenue over time.

Payment method coverage. The gateway determines which payment methods a business can offer. A gateway limited to a narrow set of card types constrains the business; one that supports cards, wallets, and local methods opens up more customers.

Security and compliance load. The gateway model chosen determines how much PCI compliance burden the merchant carries, which has real cost and operational consequences.

Cost. Gateway pricing (per-transaction fees, monthly fees, setup costs) feeds directly into the cost of accepting payments, and the true cost includes chargeback handling and any fees buried in the fee schedule.

How to choose a payment gateway

The right gateway depends on the business, but a consistent set of criteria applies to the evaluation.

Security and compliance. Confirm PCI DSS compliance, strong encryption, tokenization support, and fraud tooling. The gateway’s model also determines how much compliance scope lands on the business, so weigh that against the engineering resources available.

Payment method and market coverage. Check that the gateway supports the card types, digital wallets, and local payment methods relevant to the markets the business sells into. Cross-border sellers should confirm multi-currency support.

Total cost across the full schedule. Look past the advertised per-transaction rate to setup fees, monthly fees, chargeback fees, and any line items in the full fee schedule. Ask for the complete schedule and question anything unclear before committing.

Integration and developer experience. The gateway has to fit the existing tech stack. Poor integration creates operational friction and slows the business down. Evaluate the quality of the APIs, SDKs, and documentation.

Checkout experience. Because the gateway shapes the checkout, evaluate how the payment experience feels across devices, how many steps it imposes, and whether it supports the branding and flow the business wants.

Reliability and redundancy. A gateway that goes down takes checkout down with it. Consider uptime, and consider whether relying on a single gateway is a risk the business can afford, or whether connecting to more than one through an orchestration layer is warranted.

That last point is where many growing businesses eventually run into the limits of a single gateway. Relying on one gateway means one point of failure, one set of authorization performance characteristics, and one commercial relationship. As payment volume and complexity grow, businesses often move to connect several gateways and route transactions across them, which is the role a payment orchestration layer plays above the individual gateways.

Frequently asked questions

What is a payment gateway in simple terms?

A payment gateway is the technology that securely captures a customer’s payment details at checkout and transmits them to the systems that approve the payment. It works like a secure front door for payment information: it takes the card details, encrypts them, sends them off for approval, and brings back the approve-or-decline answer. It handles payment information rather than moving the money itself.

What is the difference between a payment gateway and a payment processor?

A payment gateway captures and securely transmits payment data between the merchant and the processing system. A payment processor takes that transaction, moves the authorization request through the card networks to the banks, and handles the mechanics of settling the funds. The gateway handles the information; the processor handles the transaction mechanics and the money movement. Many providers offer both, which is why the terms are often confused.

Does a payment gateway move the money?

No. The gateway moves payment information rather than funds. It captures and transmits the payment data and relays the approval or decline. The actual movement of money happens during settlement and is handled by the processor, the acquiring bank, and the issuing bank. This is why a gateway alone cannot complete a payment and always works alongside these other components.

Do I need a payment gateway to accept online payments?

For card-not-present transactions such as online and in-app payments, yes, in practice. There is no physical card or terminal to capture and secure the payment data, so a gateway is needed to capture, encrypt, and transmit it. Businesses accept card payments online through a gateway, whether standalone or bundled inside a payment service provider.

How much does a payment gateway cost?

Pricing varies widely and typically includes per-transaction fees, and sometimes monthly fees, setup fees, and chargeback fees. The important step is to look past the headline per-transaction rate to the complete fee schedule, including any charges for chargebacks, refunds, or cross-border transactions, and to question any line item that is unclear before signing.

What are the types of payment gateways?

The three main models are hosted (redirect) gateways, where the customer is sent to the gateway’s payment page; self-hosted or API gateways, where the merchant captures data in its own checkout and passes it through an API; and hosted fields, where the gateway’s secure input fields are embedded inside the merchant’s own checkout page. They differ mainly in how much control the merchant has over the checkout and how much security and compliance burden it carries.

Is a payment gateway the same as a merchant account?

No. A payment gateway is the technology that transmits payment data. A merchant account is a type of bank account, held with an acquiring bank, into which settled funds are deposited. A business generally needs both: the gateway to capture and transmit the payment, and a merchant account to receive the money. Some providers bundle the two together.

How does a payment gateway keep transactions secure?

Gateways secure transactions through encryption of payment data in transit, tokenization that replaces the card number so it is never exposed, PCI DSS compliance covering how cardholder data is handled, and support for authentication measures such as 3D Secure for card-not-present transactions in regulated markets. Together these protect the sensitive data as it moves through the payment flow.

Can a business use more than one payment gateway?

Yes, and many growing businesses do. Using more than one gateway provides redundancy (so checkout does not fail if one gateway goes down), lets the business route transactions to whichever gateway performs best for a given card or market, and avoids dependence on a single commercial relationship. Connecting and routing across multiple gateways is the role a payment orchestration layer performs above the individual gateways.

What is the difference between a payment gateway and a payment service provider?

A payment gateway is one specific component (the technology that captures and transmits payment data). A payment service provider (PSP) is a company that bundles several payment functions together, often including the gateway, the processing, and the acquiring relationship, so a merchant can accept payments through a single provider rather than assembling the pieces separately. A PSP typically includes a gateway as part of what it offers.

What should I look for when choosing a payment gateway?

Evaluate security and PCI compliance, the payment methods and markets it supports, the total cost across the full fee schedule rather than just the headline rate, the quality of its integration and documentation, the checkout experience it produces, and its reliability. For businesses expecting to grow, it is also worth considering whether a single gateway will remain sufficient or whether routing across multiple gateways will eventually be needed.

The bottom line on gateways

A payment gateway is the component that gets a payment request safely from the customer’s checkout into the system that approves it, and carries the answer back. It handles information rather than money, works alongside processors and acquirers rather than replacing them, and comes in models that trade control against compliance burden. For a single-market business accepting card payments, a well-chosen gateway is often all that is needed at the start.

The limits show up with growth. A single gateway is a single point of failure, a single set of authorization characteristics, and a single commercial relationship, and as volume, markets, and payment methods multiply, businesses tend to want more than one gateway working for them. That is the point at which the conversation moves from choosing a gateway to coordinating several, which is what a payment orchestration platform is built to do: connect many gateways and providers through one integration and route each transaction to the one most likely to serve it best.

Gr4vy is a cloud-native payment orchestration platform that connects merchants to more than 400 payment providers and methods through a single integration, sitting above individual gateways to route, optimize, and add redundancy across all of them. To understand how a gateway fits into a broader payment strategy for your business, talk to our team.

Most articles comparing Apple Pay and Google Pay are written for consumers deciding which wallet to tap at a coffee shop. Merchants have a different question, and it is not really “which one should I accept.” For any business selling online or in person to a broad customer base, the answer to that question is both, because the two wallets map almost perfectly onto the two dominant device platforms: Apple Pay reaches iPhone users, Google Pay (now Google Wallet) reaches the Android majority worldwide, and declining to support either means turning away the customers who carry that device.

The questions that actually matter for a merchant are how each wallet works at checkout, whether they cost anything to accept, how they affect authorization rates and fraud, what changes between in-store and online acceptance, and how to implement both cleanly across web, mobile app, and multiple payment providers. This comparison answers those, and treats the consumer “which is better” debate as the wrong frame for a business.

Quick answer for merchants

Apple Pay and Google Pay are digital wallets that let customers pay with a tokenized version of a card stored on their device, authenticated by biometrics. For merchants, the essential facts are consistent across both:

• Neither charges the merchant a fee. Both wallets earn their revenue from card issuers rather than from merchants. There is no wallet surcharge and no added gateway fee inherent to the wallet itself.
• Both use the same underlying acceptance rails. In store, any active NFC terminal accepts both. Online, both are enabled through the merchant’s existing payment provider or orchestration layer.
• Both improve security and can reduce fraud through device tokenization and biometric authentication, which also shifts liability in ways that benefit merchants.
• The interchange applies to the underlying card rather than to the wallet. The payment method does not change the card type being charged.
• Accepting both is the norm, because they cover complementary device populations instead of competing for the same customers.

The strategic decision for a merchant comes down to how to implement both across every sales surface and how to route the resulting transactions across payment providers for the best authorization rates, well beyond any question of which wallet to pick.

What Apple Pay and Google Pay actually are

Both are digital wallets that store a tokenized representation of a customer’s payment card on their device and authorize payments through biometric verification. When a customer adds a card to either wallet, the wallet does not store the actual card number. Instead, it stores a device-specific token (a Device Account Number, or DPAN) issued through the card networks’ tokenization services. When the customer pays, that token is transmitted along with a one-time cryptogram, and the merchant never receives the real card number.

Apple Pay launched in 2014, is built into every iPhone through the Apple Wallet app, and is exclusive to Apple devices. It authenticates with Face ID, Touch ID, or a passcode. Because Apple Wallet comes preinstalled and activated on iPhones, adoption among iPhone users is close to automatic.

Google Pay, now known as Google Wallet, serves the Android platform. A naming clarification that most articles skip: the standalone US Google Pay app shut down on 4 June 2024 and folded into Google Wallet, so “Google Pay” today usually refers to the tap-to-pay feature inside Google Wallet. It authenticates with fingerprint, face recognition, or PIN. Because Android spans many device manufacturers, Google Wallet is not always preloaded or activated by default, which contributes to lower per-user adoption in some markets even where acceptance is broad.

The mechanism is nearly identical between the two. The meaningful differences for a merchant are about reach (which customers can use each) instead of how they function at the moment of payment.

The comparison that matters to merchants

Dimension	Apple Pay	Google Pay / Google Wallet
Device platform	Apple / iOS only	Android (and Wear OS)
US merchant acceptance	~85-90% (per Apple)	~87% of US retailers
Global reach	80+ countries	90+ regions, strong in Android-dominant markets
Strongest markets	US, UK, developed markets	India, Southeast Asia, Latin America, emerging markets
Merchant fee for the wallet	None	None
Revenue source	Card issuers	Card issuers
Authentication	Face ID, Touch ID, passcode	Fingerprint, face, PIN
Tokenization	Device Account Number + cryptogram	Device token + cryptogram
In-store requirement	NFC terminal	NFC terminal (same hardware)
Online requirement	PSP or orchestration support	PSP or orchestration support
Card number shared with merchant	No	No
Best for reaching	iPhone-carrying customers	Android-carrying customers

The table makes the core point visible: on the dimensions a merchant controls (cost, hardware, integration), the two wallets are effectively identical. Where they differ is the customer population each reaches, and those populations are complementary. This is why the merchant decision is about implementing both instead of choosing between them.

Do Apple Pay and Google Pay cost merchants anything?

This is the question merchants ask most, and it carries a persistent misconception. Neither Apple Pay nor Google Pay charges the merchant a fee to accept it. Both wallets generate their revenue from card issuers (Apple, for example, charges issuing banks a small fee in some markets) rather than from the businesses accepting payment. There is no wallet surcharge, no separate wallet gateway fee, and no per-transaction charge that the wallet itself imposes on the merchant.

The interchange, assessment, and processing fees a merchant pays are determined by the underlying card being charged, with the wallet playing no part in setting the rate. A Visa credit card tokenized in Apple Pay carries the same interchange as that Visa credit card would if dipped as a chip. In some cases, tokenized wallet transactions qualify for slightly different interchange treatment than a keyed or non-tokenized transaction, and the security characteristics can reduce fraud and chargeback exposure, which lowers total processing cost for some merchants. But the wallet does not add a fee.

The recurring myth that contactless and wallet payments cost merchants more is simply incorrect. The rate follows the card type, and the wallet often improves the security profile of the transaction.

How the wallets affect authorization rates and fraud

Digital wallets carry a security advantage that shows up in two places a merchant cares about: authorization rates and fraud.

Tokenization improves authorization rates. Because wallet transactions use Network Tokens with a transaction cryptogram in place of a static card number, issuers treat them as higher-trust transactions. Tokenized credentials also update automatically when the underlying card is reissued, so a wallet transaction is less likely to fail because a card expired. Both effects push authorization rates on wallet transactions above those for manually entered card numbers.

Fraud and liability shift in the merchant’s favor. Biometric authentication at the moment of payment means the wallet transaction carries strong cardholder verification. This reduces fraud rates and, for many transactions, shifts fraud liability away from the merchant in the same way a strongly authenticated transaction does. Industry research has reported meaningfully lower fraud rates on wallet transactions than on other card-present and card-not-present methods.

For a merchant, this makes wallet acceptance a lever on two of the metrics that most affect payment revenue, well beyond its role as a customer-convenience feature. The relationship between tokenization and authorization performance is covered further in Gr4vy’s guide on how network tokenization works, and the broader mechanics of digital wallets in Gr4vy’s guide on how digital wallet payments work.

In-store versus online acceptance

The two acceptance contexts work differently enough to be worth separating.

In store, both wallets ride the same NFC infrastructure. Any contactless-enabled terminal that accepts one accepts the other, because both transmit through the same near-field communication standard the terminal already supports. There is no per-wallet configuration and no hardware difference. If a terminal’s NFC is active, it takes both. The merchant’s processing statement generally will not even distinguish an Apple Pay tap from a Google Pay tap, because both arrive as contactless tokenized card transactions.

Online and in-app, the picture requires more from the merchant. Apple Pay on the web works in Safari and requires domain verification with Apple, plus support from the merchant’s payment provider. Google Pay on the web works across browsers and similarly depends on payment provider support. In native mobile apps, both offer SDKs that render the wallet payment sheet and handle the tokenized transaction. This is where the merchant’s payment stack matters: enabling wallets online means the payment provider or orchestration layer has to support them, present them correctly at checkout, and route the resulting tokenized transactions to an acquirer that accepts them.

For online and in-app acceptance, the practical questions become which of a merchant’s payment providers support each wallet, whether the wallets appear correctly across web and app surfaces, and how the tokenized transactions are routed. Gr4vy’s guide on mobile checkout best practices covers the app-surface considerations in more depth.

Why merchants accept both, and how to think about reach

Because Apple Pay and Google Pay are locked to their respective device platforms, they do not compete for the same customers. An iPhone user cannot pay with Google Pay, and an Android user cannot pay with Apple Pay. Supporting only one means the customers carrying the other device lose the fast, tokenized, biometric checkout that raises conversion, and fall back to manual card entry or abandon the purchase.

The device split varies by market, and this is where the choice of emphasis matters for merchants operating in specific regions:

• In the United States and much of Western Europe, iPhone share is high, so Apple Pay reaches a large share of the mobile-paying population, though Android remains a substantial minority.
• In India, Southeast Asia, Latin America, and much of the emerging world, Android dominates, and Google Wallet (or local wallets built on similar rails) reaches the majority.
• In Android-dominant markets like India, mobile payment penetration through Google’s rails can exceed 80%, making Google Pay support essential instead of optional.

A merchant selling globally therefore needs both to avoid leaving conversion on the table in every market. A merchant selling only in a single market can weight its emphasis toward the locally dominant wallet, but even then, excluding the minority platform means turning away real customers. The pragmatic answer for nearly every merchant with a broad customer base is to accept both and let each customer use the wallet already in their hand.

Where the wallets fit in a multi-provider payment stack

For a merchant running more than one payment provider, wallet acceptance intersects with routing in a way single-PSP guides tend to miss. A wallet transaction still resolves to an underlying card that has to be authorized by an acquirer, and different acquirers perform differently for different card types, geographies, and networks. Enabling Apple Pay and Google Pay across a multi-provider stack raises three practical considerations.

First, not every payment provider supports every wallet in every market, so the merchant needs the wallets enabled consistently across whichever providers handle the relevant traffic. Second, the tokenized wallet transaction should be routed to the acquirer most likely to approve it, the same way any other transaction would be, so the authorization-rate benefit of the wallet is not undercut by suboptimal routing. Third, the wallets should appear consistently across web and app checkouts, which is easier to manage from a single orchestration layer than by configuring each provider and surface separately.

An orchestration layer addresses all three by enabling the wallets once, presenting them consistently across surfaces, and routing the resulting transactions across providers by the same logic applied to every other transaction. For the underlying routing mechanics, see Gr4vy’s guide on intelligent payment routing.

Frequently asked questions

Should merchants accept both Apple Pay and Google Pay?

Yes, for almost any business with a broad customer base. The two wallets are locked to different device platforms, so Apple Pay reaches iPhone users and Google Pay reaches Android users, with no overlap. Accepting only one turns away the customers carrying the other device. Because neither charges the merchant a fee and both use the same acceptance infrastructure, there is little reason to support one without the other.

Do Apple Pay and Google Pay charge merchants a fee?

No. Neither wallet charges the merchant a fee to accept it. Both earn their revenue from card issuers rather than from merchants. The interchange and processing fees a merchant pays are determined by the underlying card being charged rather than by the wallet used to present it. The common belief that wallet payments cost merchants more is a misconception.

Is there a hardware difference between accepting Apple Pay and Google Pay in store?

No. Both wallets use the same NFC contactless standard, so any active NFC-enabled terminal that accepts one accepts the other. There is no per-wallet configuration in store and no hardware upgrade needed to add the second wallet once a terminal supports contactless payments.

Do digital wallets improve authorization rates?

Yes. Wallet transactions use Network Tokens with a one-time cryptogram in place of a static card number, which issuers treat as higher-trust and approve at higher rates. The tokens also update automatically when the underlying card is reissued, so wallet transactions fail less often due to expired cards. Both effects tend to push wallet authorization rates above those for manually entered cards.

What is the difference between Google Pay and Google Wallet?

They are now effectively the same thing in most markets. The standalone US Google Pay app shut down on 4 June 2024 and folded into Google Wallet. “Google Pay” today generally refers to the tap-to-pay payment feature inside the Google Wallet app. For a merchant, accepting “Google Pay” and accepting “Google Wallet” mean the same thing.

Which wallet has better merchant acceptance?

In the United States they are close, with Apple reporting roughly 85 to 90 percent US merchant acceptance and Google Pay supported at around 87 percent of US retailers, largely because both ride the same NFC terminals. Globally, Google Wallet reaches more regions and dominates in Android-heavy markets like India and much of Southeast Asia and Latin America, while Apple Pay is strongest in the US and other developed markets.

Does the merchant see the customer’s real card number with a wallet payment?

No. Both wallets use tokenization, so the merchant receives a device-specific token and a cryptogram in place of the real card number. This improves security, reduces the merchant’s exposure to card data, and is part of why wallet transactions carry a lower fraud rate.

How do merchants accept Apple Pay and Google Pay online?

Online acceptance depends on the merchant’s payment provider or orchestration layer supporting each wallet. Apple Pay on the web requires domain verification with Apple and works in Safari; Google Pay works across browsers. Both offer SDKs for native mobile apps. The merchant enables the wallets through its payment stack, which presents them at checkout and routes the tokenized transactions to an acquirer.

Do wallet payments reduce chargebacks?

They can. The biometric authentication built into both wallets provides strong cardholder verification at the moment of payment, which reduces fraud and can shift fraud liability away from the merchant on those transactions. Lower fraud and stronger authentication generally translate into reduced chargeback exposure compared with less strongly authenticated payment methods.

Does accepting Apple Pay or Google Pay change my interchange rate?

The interchange rate follows the underlying card type, with the wallet playing no part. A given card carries its interchange whether it is dipped as a chip or presented through a wallet. In some cases tokenized wallet transactions qualify for slightly different interchange treatment, and their stronger security profile can lower total fraud-related costs, but the wallet itself does not impose a separate rate.

Which wallet should a merchant prioritize in a specific country?

Weight emphasis toward the device platform that dominates the target market: Apple Pay in markets with high iPhone share such as the US and UK, Google Wallet in Android-dominant markets such as India and much of Southeast Asia and Latin America. Even in a single market, though, excluding the minority platform means turning away real customers, so accepting both remains the default recommendation.

The takeaway for merchants

The consumer framing of “Apple Pay versus Google Pay” does not translate to the merchant side, because a business is not the one choosing which wallet to carry. The customer already made that choice when they bought their phone. A merchant that wants to capture the conversion, authorization-rate, and fraud benefits of wallet payments needs to meet customers on whichever device they hold, which means supporting both wallets across every sales surface.

Once both are accepted, the questions that remain are implementation questions: are the wallets enabled consistently across web and app, are they supported by the payment providers handling the relevant traffic, and are the tokenized transactions routed to the acquirers most likely to approve them. Those are the levers that turn wallet acceptance from a checkbox into a measurable gain in conversion and approval rates.

Gr4vy’s cloud-native payment orchestration platform lets merchants enable Apple Pay and Google Pay once and present them consistently across web and in-app checkout, routing the resulting transactions across more than 400 payment providers and methods for the best authorization outcome. To see how wallet acceptance would work across your specific provider mix and markets, get in touch with our team.