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:

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

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.

Something shifted in 2025 that most retailers did not plan for. On-chain stablecoin settlement volume reached an estimated $33 trillion for the year, a figure that, according to analysis published by Spark citing public network data, surpassed the combined transaction volume of Visa and Mastercard. That number includes a large amount of trading and treasury movement rather than pure point-of-sale activity, so it overstates retail adoption. But the infrastructure that moved those trillions is now pointed squarely at merchant commerce, and the companies pointing it there are not fringe crypto startups. Stripe, PayPal, Shopify, Mastercard, and Circle all shipped merchant-facing stablecoin capabilities in the months around the turn of 2026.

For a payment team running an established card-based stack, that raises a practical question that has nothing to do with crypto ideology: does accepting stablecoins actually help the business, and if so, how does it fit alongside the cards, wallets, and local methods already in production? What follows is a merchant-side, rail-neutral look at how stablecoin payments work, the three ways to accept them, the real benefits and the real limitations, and where they fit in a modern payment architecture.

What are stablecoin payments?

A stablecoin is a digital asset whose value is pegged to a reference currency, most commonly the US dollar, so that one unit is designed to always be worth approximately one dollar. USDC, USDT, PYUSD, and EURC are among the most widely used. Stablecoin payments move value as these dollar-pegged tokens over public blockchains, settling when a block is finalized rather than when an issuing bank authorizes a charge.

That single mechanical difference (settlement on a blockchain instead of authorization through a card network) is the source of nearly every benefit and every limitation that follows. There is no issuing bank in the loop, no interchange, no card network, and no multi-day settlement cycle. There is also no chargeback mechanism of the kind card holders expect, no built-in identity layer, and no established consumer habit of paying this way outside a small cohort of crypto holders.

Stablecoins sit apart from volatile cryptocurrencies like Bitcoin in the one respect that matters for payments: price stability. A merchant that accepts one USDC expects it to be worth roughly one dollar when it settles, which removes the exchange-rate risk that made earlier attempts at Bitcoin acceptance impractical for everyday commerce.

Why stablecoins reached merchant commerce in 2026

Three developments converged to move stablecoin acceptance from theoretical to practical, and understanding them explains why the topic became unavoidable for payment teams in 2026.

Regulation caught up. The GENIUS Act, signed into US law on 18 July 2025, gave stablecoins a federal regulatory framework for the first time, establishing rules for issuance and reserves. In parallel, the EU’s MiCA framework brought stablecoin issuers and certain service providers under supervision. Regulatory clarity is what allowed regulated financial institutions to build on stablecoin rails without the compliance uncertainty that had kept them out.

The major processors integrated it. Rather than requiring merchants to adopt crypto-native infrastructure, the established players folded stablecoin settlement into their existing merchant products. Since December 2025, according to Spark’s analysis, Stripe merchants have been able to accept USDC through standard checkout, with Stripe handling the blockchain interaction and converting to fiat automatically if the merchant prefers. PayPal extended PYUSD across dozens of markets. Mastercard added settlement support for regulated stablecoins including USDC and EURC. This is the development that matters most for existing merchants, because it means adding stablecoins no longer requires abandoning the card-based workflow.

The market reached meaningful scale. Total stablecoin circulating supply reached roughly $308 billion by early 2026 according to figures cited by industry trackers, large enough that consumer and institutional holdings can sustain a genuine payment network beyond its origins as a trading instrument.

The three ways merchants can accept stablecoins

Stablecoin acceptance is not a single thing. There are three structurally different models, and they have very different implications for which customers can pay, what the merchant ends up holding, and how much the existing checkout has to change.

Model 1: Customer pays in stablecoins, merchant settles in fiat

The customer pays with stablecoins from a wallet, and a processor or gateway converts the payment to the merchant’s local currency before it lands in the merchant’s account. The merchant never holds a crypto asset. This is the model that most closely resembles ordinary card processing from the merchant’s point of view: funds arrive in dollars (or euros, or the relevant currency), reconciliation looks familiar, and the volatility question never arises because conversion happens at the moment of payment.

The limitation is on the customer side. Only customers who already hold stablecoins in a wallet can pay this way, which today is a small share of online shoppers. Industry estimates commonly put crypto ownership at roughly 3 to 5 percent of online shoppers, which caps the immediate addressable base for this model.

Model 2: Customer pays with a card, merchant settles in stablecoins

The inverse model. The customer pays with a familiar instrument (Visa, Mastercard, Apple Pay, Google Pay), and the merchant receives settlement in stablecoins instead of waiting on the traditional multi-day bank settlement cycle. This model preserves the full customer base, because customers pay exactly as they always have, while giving the merchant faster settlement and the treasury benefits of holding a dollar-pegged digital asset. It is particularly relevant for merchants with cross-border operations, fragmented settlement timelines, or treasury teams that want faster access to funds.

Model 3: Direct on-chain acceptance

The merchant accepts stablecoins directly into its own wallet with no processor in between. The customer scans a QR code or clicks a payment link, sends stablecoins from their wallet to the merchant’s, and the transaction settles on-chain in seconds for the cost of a network fee. There is no processor markup and no percentage fee, only the network transaction cost. The trade is that the merchant takes on wallet management, key security, on-chain operations, volatility exposure if it holds the asset, and the compliance work of handling crypto directly. This model suits crypto-native businesses more than established retailers.

The practical takeaway for most existing merchants: Model 1 and Model 2 are the ones that fit an existing card stack, because they preserve familiar reconciliation and either shield the merchant from holding crypto (Model 1) or preserve the existing customer experience (Model 2). Model 3 is powerful but built for a different kind of business.

The benefits, stated honestly

Stablecoin payments carry real advantages, and it is worth being precise about which are meaningful for an established merchant versus which are mostly relevant to crypto-native operations.

Faster settlement. On-chain settlement finalizes in seconds to minutes rather than the two-to-seven business days typical of card settlement. For businesses with cash-flow sensitivity or long settlement cycles, this is a genuine operational benefit.

Lower cost per transaction, in some models. Direct on-chain payments avoid interchange, assessment fees, and processor markup, carrying only a network fee. Even the processor-mediated models can, in some cases, cost less than the three fee layers of a card transaction. The size of the saving depends heavily on the model and the provider.

Cross-border efficiency. Stablecoins move the same way regardless of borders, avoiding the intermediary fees, FX spreads, and cut-off-time delays that make traditional cross-border settlement slow and expensive. This is the single strongest use case for most enterprises: not domestic checkout, but cross-border settlement, supplier payouts, and treasury movement.

No rolling reserve or fund-freeze risk in self-custody models. When a merchant holds funds in its own wallet, no intermediary can freeze them or impose a rolling reserve. This matters most to businesses that have struggled with payment processor holds.

Reaching crypto-holding customers. Studies cited across the industry suggest that crypto owners often prefer merchants that accept crypto, so acceptance can attract a specific, growing customer segment even while that segment remains a minority.

The limitations, stated just as honestly

The crypto-native content on this topic tends to bury the limitations. For a payment team making a real decision, they matter as much as the benefits.

Small customer base for direct crypto payment. If customers must pay in stablecoins (Model 1 or Model 3), only the minority who hold crypto can transact. For most consumer merchants, this makes direct stablecoin acceptance a supplementary option well short of a primary rail, at least for now.

No native chargeback mechanism. On-chain transactions are final. This eliminates chargeback fraud and the associated fees, which is a benefit, but it also removes the consumer-protection mechanism that card holders expect. For consumer commerce, the absence of a familiar dispute path is a real consideration, and it shifts the burden of dispute resolution onto the merchant’s own policies.

Volatility shielding requires deliberate design. Although stablecoins are pegged, merchants that choose to hold them rather than convert immediately take on peg risk and must design their settlement and treasury handling accordingly. Most merchants that are not crypto-native settle to fiat immediately for exactly this reason.

Accounting, tax, and compliance complexity. Handling stablecoins introduces KYB and KYC considerations, transaction monitoring, and accounting treatment that differ from card payments. Merchants that hold stablecoins rather than converting immediately face additional accounting and tax questions.

Operational maturity. Wallet operations, key management, and on-chain error handling are unfamiliar to most payment teams. Poor wallet operations create losses and disputes that card-based teams are not set up to handle, which is why the processor-mediated models are the pragmatic entry point for established merchants.

How stablecoins fit into a multi-rail payment strategy

The framing that serves an established merchant best treats stablecoins as one more payment rail, with a distinct cost, speed, and customer profile, sitting alongside cards, wallets, account-to-account payments, and local methods in the payment stack. The useful question is where that rail earns its place across the stack.

That framing is exactly what a payment orchestration layer is built to handle. Orchestration connects a merchant to many payment providers and methods through a single integration and routes each transaction across them based on cost, geography, and other factors. Adding a stablecoin rail to an orchestrated stack is a matter of connecting a provider and configuring the rules that decide when it is used, without re-architecting the checkout.

Several patterns emerge when stablecoins are treated as an orchestrated rail:

• Route cross-border settlement through stablecoins while keeping domestic transactions on cards, capturing the cross-border efficiency where it is strongest without disturbing the familiar domestic flow.
• Offer stablecoin payment as an option at checkout for the customers who want it, alongside cards and wallets, with the orchestration layer presenting it only where relevant.
• Settle in stablecoins for treasury benefit while accepting cards from customers (Model 2), with the orchestration and settlement layers handling the conversion.
• Keep reconciliation unified across card and stablecoin rails, so the finance team sees one consistent view instead of a separate crypto silo.

For the broader picture of how routing across multiple providers and methods works, Gr4vy’s guide on intelligent payment routing covers the underlying mechanism, and the guide on alternative payment methods situates stablecoins among the wider set of non-card options merchants are adding.

How stablecoin acceptance compares to card acceptance

A side-by-side view of the two, from the merchant’s perspective:

The comparison makes the strategic point clear. In consumer checkout, stablecoins work best today as an added rail with specific strengths (cross-border settlement, speed, cost in some models) and specific weaknesses (customer base, dispute handling, operational demands), which makes them a valuable addition to a multi-rail stack well before they become a wholesale substitute for cards.

Frequently asked questions

What is a stablecoin payment?

A stablecoin payment moves value as a dollar-pegged (or other currency-pegged) digital token over a public blockchain, settling when the blockchain confirms the transaction rather than when a bank authorizes a charge. Common stablecoins used in payments include USDC, USDT, PYUSD, and EURC. Because the token’s value is pegged, the merchant is not exposed to the price volatility associated with cryptocurrencies like Bitcoin.

How do merchants accept stablecoin payments?

There are three models. In the first, the customer pays in stablecoins and a processor converts to fiat so the merchant receives local currency. In the second, the customer pays with a card and the merchant receives settlement in stablecoins. In the third, the merchant accepts stablecoins directly into its own wallet with no processor. Most established merchants use one of the first two, because they preserve familiar reconciliation and either avoid holding crypto or preserve the existing customer experience.

Are stablecoin payments cheaper than card payments?

They can be, depending on the model. Direct on-chain payments avoid interchange, assessment fees, and processor markup, carrying only a network fee, which can be significantly cheaper than a card transaction. Processor-mediated stablecoin acceptance carries a provider fee that reduces but may not eliminate the saving. The cost advantage is real but varies widely by model and provider.

Do stablecoin payments have chargebacks?

No. On-chain stablecoin transactions are final and cannot be reversed the way card transactions can. This eliminates chargeback fraud and the associated fees, which benefits the merchant, but it also removes the dispute-resolution mechanism that card-paying consumers expect. Merchants accepting stablecoins for consumer purchases need their own policies for handling disputes and refunds.

Is it risky for a merchant to hold stablecoins?

Holding stablecoins introduces peg risk (the small chance the token deviates from its pegged value) and accounting, tax, and treasury considerations that differ from holding fiat. Most merchants that are not crypto-native avoid this by settling stablecoin payments to fiat immediately, which removes the holding risk. Merchants that choose to hold stablecoins usually do so for a specific treasury or cross-border reason and design their operations accordingly.

Which stablecoins are used for merchant payments?

The most widely used in merchant contexts are USDC (issued by Circle), USDT (Tether), PYUSD (PayPal’s dollar-backed stablecoin), and EURC (a euro-pegged stablecoin). Card networks and processors have added settlement support for specific regulated stablecoins, so the practical set available to a given merchant depends on which providers it works with.

Can I add stablecoin payments without changing my existing checkout?

Increasingly yes. Major processors have integrated stablecoin acceptance into their existing merchant products, so in some cases stablecoins can be enabled with little or no code change. In an orchestrated payment stack, adding a stablecoin rail is a matter of connecting a provider and configuring routing rules, instead of rebuilding the checkout.

Are stablecoin payments legal and regulated?

Stablecoins gained a US federal regulatory framework with the GENIUS Act signed in July 2025, and the EU regulates them under the MiCA framework. Regulation continues to develop, and the specific compliance obligations depend on the merchant’s jurisdiction, whether it holds stablecoins, and which providers it uses. The regulatory picture is far clearer than it was even a year earlier, which is part of why established payment companies entered the space.

Should my business accept stablecoin payments?

The strongest cases today are cross-border settlement, supplier payouts, treasury efficiency, and reaching crypto-holding customers, well ahead of any case for replacing domestic card checkout. Businesses with significant cross-border volume, slow or fragmented settlement, or high cross-border costs benefit most. For a purely domestic consumer merchant with no settlement pain, the immediate case is weaker, though the option is worth evaluating as adoption grows.

How do stablecoins fit with my existing card payments?

The most workable approach treats stablecoins as one rail among several, added alongside cards, wallets, and local methods instead of replacing them. A payment orchestration layer can route transactions across all of these based on cost, geography, and customer preference, so a merchant can use stablecoins where they are strongest (often cross-border) while keeping cards for the bulk of consumer checkout.

Where this leaves payment teams

The honest read on stablecoin payments in 2026 is that they crossed from speculative to practical, but practical does not mean universal. For an established merchant, the technology now works, the regulation exists, and the major processors have made acceptance accessible without a crypto-native rebuild. What has not changed is that most consumers still pay with cards and wallets, that direct stablecoin payment reaches only a small slice of shoppers today, and that the clearest wins are in cross-border settlement and treasury rather than domestic checkout.

That points to a measured strategy. Treat stablecoins as an additional rail with a specific and real set of strengths, add them where those strengths apply, settle to fiat unless there is a deliberate reason to hold, and keep the whole thing unified with the rest of the payment stack so the finance team is not managing a separate silo. Merchants that already route transactions across multiple providers are best positioned to do this, because adding a stablecoin rail becomes a configuration decision instead of an architectural one.

Gr4vy’s cloud-native payment orchestration platform connects merchants to a wide range of payment providers and methods through a single integration, with routing, unified reporting, and the flexibility to add new rails as they mature. If stablecoins are on your roadmap and you want to understand how they would sit alongside your existing card and local-method stack, reach out to our team for a walkthrough.

Three models dominate the conversation when a business decides how to structure its payment operations: the merchant of record (MoR), the payment facilitator (PayFac), and payment orchestration. They are often discussed as if they were competing answers to the same question, but they solve different problems, sit at different layers of the payment stack, and carry very different tradeoffs on liability, control, tax, cost, and data ownership. Choosing among them (or combining them) shapes how much operational burden a business carries, how much margin it keeps, how much control it retains over the customer relationship, and how easily it can scale across markets.

The comparison below defines all three models precisely, sets them against every dimension that matters, and offers a decision framework for choosing the right one based on business stage, growth ambition, and where the business wants to sit on the control-versus-convenience spectrum.

The three models at a glance

Before the deeper analysis, the short version of each:

• Merchant of record (MoR) is a third party that becomes the legal seller of the goods or services. The MoR’s name appears on the customer’s statement, and the MoR assumes full liability for tax, compliance, chargebacks, and fraud. The business hands over control in exchange for offloading nearly all payment and compliance complexity.
• Payment facilitator (PayFac) is a company that holds a master merchant account and onboards businesses as sub-merchants underneath it, letting them accept payments quickly without opening their own merchant accounts. The PayFac simplifies onboarding and payment acceptance but typically leaves tax and much of the compliance burden with the business.
• Payment orchestration is a technology layer that connects a business to multiple payment providers (PSPs, acquirers, fraud tools, and payment methods) through a single integration, then routes each transaction intelligently across them. The business keeps full control, ownership, and liability, and gains flexibility and optimization.

The essential distinction: MoR and PayFac are about who is responsible for the transaction and the compliance around it, while orchestration is about how transactions are routed and optimized across providers. This is why orchestration can coexist with the other two models rather than strictly competing with them.

What is a merchant of record?

A merchant of record is the legal entity authorized to sell goods or services to the customer and held responsible for the transaction. When a business sells through a third-party MoR, that MoR becomes the reseller of record: its name appears on the customer’s card statement, and it takes on the financial and legal liability for the sale.

The MoR model bundles a comprehensive set of responsibilities:

• Tax calculation, collection, and remittance across every jurisdiction where the business sells, including sales tax, VAT, and GST
• Regulatory compliance with the payment and consumer protection rules of each market
• Chargeback and dispute management, handled end to end by the MoR
• Fraud prevention and liability, absorbed by the MoR
• Payment processing through the MoR’s own provider relationships

The appeal is obvious for businesses that want to sell globally without building the tax, compliance, and payments infrastructure themselves. A SaaS company selling into 40 countries would otherwise need to register for tax in each, monitor rate changes, file returns, and manage the compliance overhead. An MoR collapses all of that into a single relationship, in exchange for a percentage of each transaction.

The tradeoff is control and margin. The MoR takes a meaningful cut (typically higher than a pure payment processing fee), owns the customer payment relationship, controls the checkout to a significant degree, and sits between the business and its transaction data. For businesses whose payment optimization, customer insight, and retention execution are competitive advantages, handing those to an MoR can be an expensive trade. Common MoR providers include Paddle, and the Apple App Store and Google Play Store operate as MoRs for apps sold through them.

What is a payment facilitator?

A payment facilitator (PayFac) is a service provider that holds a master merchant account with an acquiring bank and onboards businesses as sub-merchants underneath that master account. Instead of each business applying directly to a bank for its own merchant account (a process that can take weeks and requires underwriting, credit checks, and bank negotiation), businesses join the PayFac’s platform and begin processing payments quickly.

The PayFac model handles:

• Fast sub-merchant onboarding under the master merchant account
• Payment processing and the acquiring relationship
• Risk assessment and monitoring of sub-merchants
• Some compliance obligations, particularly around the acquiring relationship and PCI

Stripe, Square, and PayPal built their growth on the PayFac model. It is the reason a new online store can start accepting cards in minutes instead of waiting weeks for a merchant account. The model is especially common in platform payments, marketplace payments, and vertical SaaS, where a platform wants to embed payments for the businesses operating on it.

The critical limitation, and the point that most surprises businesses, is tax. A PayFac generally does not calculate, file, or remit the business’s sales tax. The business remains the legal seller and stays fully responsible for tax registration, filing, and rate management. The PayFac simplifies payment acceptance, but the compliance and tax liability largely remain with the business. A PayFac also does not, by itself, provide the multi-provider routing and optimization that orchestration delivers, because the sub-merchant processes through the PayFac’s own infrastructure.

For the distinction between the PayFac approach and a traditional payment service provider setup, Gr4vy’s guide on what a PSP does covers the underlying roles.

What is payment orchestration?

Payment orchestration is a technology layer that sits between a business’s checkout and the underlying payment providers, connecting to multiple PSPs, acquirers, fraud tools, and payment methods through a single integration and routing each transaction intelligently across them. Unlike the MoR and PayFac models, orchestration does not change who is legally responsible for the transaction. The business remains the merchant, keeps full ownership of its provider relationships and transaction data, and retains liability, while gaining flexibility and optimization.

Payment orchestration handles:

• Single-integration access to many providers, so adding a new PSP, acquirer, or payment method is a configuration change instead of an engineering project
• Intelligent transaction routing across providers based on cost, authorization rate, geography, and other factors
• Failover and redundancy, routing around a provider that is degraded or offline
• Tokenization and credential portability, so stored cards are not locked to a single provider
• Unified reporting and analytics across every provider in the stack

The orchestration model is built for businesses that treat payments as a strategic function rather than a commodity. It keeps the business in control of the customer relationship, preserves margin by enabling competition among providers, and unlocks the authorization rate improvements that come from routing each transaction to the provider most likely to approve it. For a full treatment, see Gr4vy’s guide on what a payment orchestration platform is.

The distinction from a PSP specifically (a common point of confusion) is covered in Gr4vy’s guide on the difference between payment orchestration and a PSP.

The definitive comparison

The three models across every dimension that matters for a structural decision:

The pattern across the table: the MoR model trades the most control for the most offloaded complexity, the PayFac model trades some control for speed and simplicity, and orchestration retains the most control while adding optimization and flexibility.

The control-versus-convenience spectrum

The clearest way to understand the three models is to place them on a spectrum from maximum convenience to maximum control.

Maximum convenience (MoR). The business offloads tax, compliance, chargebacks, fraud, and the legal seller role. In return, it gives up control over the customer payment relationship, accepts a higher cost, and cedes ownership of much of its transaction data. This is the right trade for businesses whose priority is entering many markets fast without building infrastructure, and whose payment operations are not a source of competitive advantage.

Middle ground (PayFac). The business gets fast onboarding and simplified payment acceptance while remaining the legal seller. It keeps more control than under an MoR but still processes through the PayFac’s infrastructure and retains tax and much compliance responsibility. This is the right trade for early-stage businesses prioritizing speed, and for platforms embedding payments for the businesses on them.

Maximum control (orchestration). The business keeps the legal seller role, full data ownership, full checkout control, and its own provider relationships, while gaining multi-provider routing, optimization, and redundancy. In return, it takes on an integration project and retains tax, compliance, and liability responsibility. This is the right trade for enterprises whose payment performance materially affects revenue and who want to preserve negotiating power across providers.

The spectrum also explains why the models are not mutually exclusive.

Can these models be combined?

Yes, and increasingly they are. The models operate at different layers, which means a business can use more than one at once.

MoR plus orchestration. A growing pattern is for businesses to use the MoR model for tax and compliance offloading in complex markets while running orchestration underneath to optimize routing and retain data visibility. Some modern MoR providers build orchestration-style infrastructure into their offering (connecting multiple processors, supporting local payment methods, and routing transactions), which blurs the line between the two. The strategic question becomes how much control the business wants to keep versus how much complexity it wants to offload.

PayFac plus orchestration. A platform operating as a PayFac for the businesses on it can run orchestration underneath to route the aggregate transaction volume across multiple acquirers, improving authorization rates and adding redundancy for all its sub-merchants at once.

The key insight: because orchestration is a technology layer rather than a legal or liability structure, it can sit underneath either of the other two models. The choice between MoR and PayFac is a question about liability and compliance structure; the choice to add orchestration is a question about routing, optimization, and control. They answer different questions.

When to choose each model

The right choice depends on business stage, growth model, and strategic priorities.

Choose a merchant of record when

• The business sells digital goods or SaaS into many countries and wants to offload global tax compliance entirely
• Payment operations are not a competitive advantage and the business would rather not build the infrastructure
• Speed of international expansion matters more than margin optimization or data ownership
• The business is small enough that the compliance overhead of selling globally would otherwise be prohibitive
• The higher per-transaction cost is acceptable in exchange for near-complete offloading of tax, compliance, and fraud liability

Choose a payment facilitator when

• The business needs to start accepting payments quickly without the delay of opening its own merchant account
• The business is a platform or marketplace wanting to embed payments for the businesses operating on it
• Transaction volumes are modest enough that the PayFac’s pricing is competitive
• Fast onboarding is the priority and the business can handle its own tax obligations
• The business wants simplified payment acceptance without building a deep payment stack

Choose payment orchestration when

• Payment performance (authorization rates, cost, conversion) materially affects revenue
• The business uses, or plans to use, more than one PSP or acquirer
• Retaining control of the customer relationship, checkout experience, and transaction data matters
• The business wants to preserve negotiating power across providers rather than being locked to one
• Redundancy and failover are important because payment downtime is costly
• The business processes enough volume that routing optimization produces meaningful returns

Common misconceptions

A few points of confusion come up repeatedly when businesses evaluate these models.

“Orchestration and MoR are alternatives to each other.” They operate at different layers. MoR is a liability and compliance structure; orchestration is a routing technology. A business can use both. The real question is how much control to keep versus how much complexity to offload.

“A PayFac handles my taxes.” Generally it does not. The business remains the legal seller under a PayFac model and stays responsible for tax calculation, filing, and remittance. This is the single most common surprise for businesses that chose a PayFac expecting MoR-style tax handling.

“An MoR gives me the best authorization rates.” Not necessarily. Authorization rate optimization comes from routing each transaction to the provider most likely to approve it, which is an orchestration capability. An MoR uses its own provider relationships, which the business does not control or optimize directly.

“Orchestration is only for very large enterprises.” Orchestration produces the largest returns at high volume, but the flexibility, redundancy, and data ownership benefits apply well below the enterprise tier. The break-even depends on volume, market complexity, and how much payment performance affects the specific business.

“Choosing one model locks me in forever.” The models can be migrated between and combined. A business might start with a PayFac for speed, add orchestration as volume grows, and use an MoR for specific complex markets. The structure should evolve with the business.

How the models affect cost and margin

Cost structure differs meaningfully across the three models, and it is one of the most important factors in the decision.

Merchant of record typically carries the highest cost, because the MoR is absorbing tax compliance, fraud liability, chargeback management, and the legal seller role, and prices accordingly. The MoR’s fee is usually a percentage of each transaction that exceeds pure payment processing costs. For businesses that would otherwise spend heavily on tax compliance infrastructure and international expansion, the all-in cost can still be favorable, but the headline per-transaction rate is the highest of the three.

Payment facilitator costs sit in the middle. The PayFac’s pricing (often a flat rate or a percentage plus fixed fee) is simple and predictable, which suits smaller businesses, but it is typically less favorable at scale than negotiated direct processing rates. As volume grows, the convenience premium of the PayFac model becomes more expensive relative to alternatives.

Payment orchestration carries a platform cost but preserves the most margin at scale, because it lets the business negotiate directly with providers, route to the lowest-cost qualified provider for each transaction, and capture the authorization rate improvements that come from intelligent routing. For high-volume businesses, the routing optimization and provider competition that orchestration enables typically more than offset the platform cost.

For a broader treatment of how payment costs break down, see Gr4vy’s guide on payment compliance and regulations and the related discussion of international card acquiring.

Frequently asked questions

What is the difference between a merchant of record and a payment facilitator?

A merchant of record becomes the legal seller of the goods or services and takes on full responsibility for tax, compliance, chargebacks, and fraud. A payment facilitator holds a master merchant account and onboards businesses as sub-merchants, simplifying payment acceptance but generally leaving the business as the legal seller responsible for its own tax and much of its compliance. The core difference is liability: an MoR assumes it, a PayFac largely does not.

Is payment orchestration the same as a merchant of record?

No. A merchant of record is a legal and liability structure where a third party becomes the seller and assumes tax and compliance responsibility. Payment orchestration is a technology layer that routes transactions across multiple providers while the business remains the merchant and keeps liability, control, and data ownership. They operate at different layers and can be used together.

Does a payment facilitator handle sales tax?

Generally no. Under a payment facilitator model, the business remains the legal seller and stays responsible for calculating, filing, and remitting its own sales tax, VAT, or GST. This is different from a merchant of record, which does handle tax across jurisdictions. The tax distinction is the most common source of confusion between the two models.

Can you use payment orchestration and a merchant of record together?

Yes. Because orchestration is a technology layer rather than a liability structure, it can operate underneath a merchant of record arrangement. A business might use an MoR to offload tax and compliance in complex markets while running orchestration to optimize routing and retain data visibility. Some modern MoR providers build orchestration-style routing into their own infrastructure.

Which model gives the best authorization rates?

Payment orchestration typically produces the best authorization rates because it routes each transaction to the provider most likely to approve it and adds retry and failover logic across multiple providers. A merchant of record uses its own provider relationships that the business does not control directly, and a payment facilitator processes through its own infrastructure, so neither offers the multi-provider routing that drives authorization optimization.

Which model is cheapest?

It depends on volume and complexity. A payment facilitator is often cheapest and simplest for low-volume businesses. A merchant of record carries the highest per-transaction cost but can be cost-effective for businesses that would otherwise build expensive global tax infrastructure. Payment orchestration preserves the most margin at higher volume because it enables direct provider negotiation and lowest-cost routing, offsetting its platform cost.

Is a payment facilitator a merchant of record?

Not usually. A payment facilitator simplifies payment acceptance under a master merchant account but leaves the business as the legal seller. A merchant of record becomes the legal seller itself. Some providers combine elements of both, and some PayFacs act as the merchant of record for their sub-merchants in specific arrangements, but the two models are structurally distinct.

What is best for a SaaS business selling globally?

Many global SaaS businesses use a merchant of record to offload the substantial burden of global tax compliance, since selling digital goods into many countries creates complex tax registration and filing obligations. However, SaaS businesses that treat payment performance and customer data as competitive advantages often prefer orchestration, sometimes combined with an MoR for the most complex markets, to retain control while still managing compliance complexity.

Does payment orchestration replace my PSP?

No. Payment orchestration sits above your PSPs and routes transactions across them. You keep your PSP relationships (and can add more), and the orchestration layer decides which one processes each transaction. This is different from replacing a PSP; orchestration coordinates multiple PSPs rather than substituting for them.

When should a business switch from a payment facilitator to orchestration?

The common trigger is scale. As transaction volume grows, the flat convenience pricing of a PayFac becomes more expensive relative to negotiated direct processing, and the lack of multi-provider routing starts to cost measurable authorization rate and redundancy benefits. Businesses often add orchestration when payment performance becomes material to revenue or when they want to add a second provider.

Do marketplaces need a merchant of record, a payment facilitator, or orchestration?

Marketplaces have used all three depending on their structure. Many operate as payment facilitators for their sellers, some use a merchant of record model, and many run orchestration underneath to route the aggregate volume across multiple acquirers for better authorization rates and redundancy. The right structure depends on who the marketplace wants to be the legal seller and how much payment optimization matters to its economics.

What to do next

The choice among merchant of record, payment facilitator, and payment orchestration is really two decisions. The first is a liability and compliance decision: how much of the tax, regulatory, and fraud burden does the business want to offload, and is it willing to give up control and margin to do so? That decision points toward an MoR (offload the most), a PayFac (offload some, gain speed), or keeping the responsibility in-house. The second is an optimization decision: does the business want to route transactions across multiple providers to improve authorization rates, reduce cost, and add redundancy? That decision points toward orchestration, which can sit underneath whichever liability structure the business chooses.

For businesses whose payment performance materially affects revenue, and who want to keep control of the customer relationship and transaction data, orchestration is the layer that delivers optimization without giving up ownership. It coexists with the other models rather than forcing an either-or choice.

Gr4vy’s cloud-native payment orchestration platform connects a business to more than 400 PSPs and payment methods through a single integration, routing each transaction intelligently while the business keeps full control, ownership, and flexibility. If you’re weighing these models for your own payment operations, contact our team for a walkthrough of where orchestration fits alongside or instead of the other approaches.

PSD3 and the Payment Services Regulation (PSR) are the most significant overhaul of European payments regulation since PSD2 came into effect in 2018. On 27 November 2025, the European Parliament and the Council reached provisional political agreement on both texts. On 23 April 2026, COREPER endorsed the trilogue agreement and the final compromise texts were published. The European Parliament’s plenary vote is expected in late May, with publication in the EU Official Journal anticipated for June or July 2026 (potentially slipping to September). The PSR will enter into force 20 days after publication and apply EU-wide approximately 21 months later, with PSD3 requiring national transposition over the same window.

For European merchants, this is the regulatory backbone that will govern how online card payments are authenticated, how Strong Customer Authentication exemptions apply, how cross-border refunds work, how open banking APIs perform, and how fraud liability is allocated for the rest of the decade. The merchants who prepare now will adapt their stacks cleanly during the transition. The merchants who treat 2028 as the deadline will discover in 2027 that the operational, contractual, and technical work required is materially larger than they had assumed.

This guide explains what PSD3 and PSR actually are, how they differ from PSD2, the timeline as it stands in mid-2026, the specific changes that affect merchants directly, and what enterprise payment teams should be doing now to prepare.

A clear definition: PSD3 and PSR in one sentence each

The Third Payment Services Directive (PSD3) is an EU Directive that updates the authorisation, supervision, and licensing framework for payment service providers and e-money institutions across the European Economic Area, requiring national transposition by each Member State.

The Payment Services Regulation (PSR) is a directly applicable EU Regulation that governs conduct of business rules for payment services, including Strong Customer Authentication, fraud liability, open banking standards, transparency obligations, and consumer protection.

Together, they replace PSD2 and the existing E-Money Directive (EMD2), creating a single supervisory and regulatory framework for European payments. The split between a directive and a regulation is itself a major structural change: where PSD2 was transposed unevenly across Member States (creating fragmentation that merchants had to navigate country by country), the PSR will apply directly and uniformly across all 27 EU members without national interpretation.

Why PSD3 and PSR exist

PSD2 was designed in the mid-2010s and came into force at a time when the payments market looked materially different. Since 2018, the European payments market has transformed: electronic payments grew from €184 trillion in 2017 to €240 trillion by 2021, open banking matured into a meaningful infrastructure layer, instant payment rails became standard, mobile wallets reached majority adoption in many markets, and fraud sophistication outpaced the controls available under the old framework.

The European Commission proposed PSD3 and PSR in June 2023 to address gaps and weaknesses that had become visible across the PSD2 implementation:

• Fragmentation across Member States. PSD2’s directive structure produced inconsistent rules across countries, with merchants and PSPs facing different interpretations of identical regulations depending on jurisdiction.
• Fraud growing faster than the controls. Authorised push payment fraud, social engineering attacks, and impersonation fraud all rose significantly. The reimbursement framework under PSD2 was uneven across Member States.
• Open banking underperforming. APIs were inconsistent in quality, poorly maintained, and frequently fell back to less reliable interfaces. Adoption was slower than the regulators had targeted.
• E-money rules duplicating payment institution rules. Maintaining two parallel licensing regimes (under PSD2 and EMD2) created unnecessary complexity for fintechs offering payment plus e-money services.
• Strong Customer Authentication scope unclear. Which exemptions applied where, how SCA interacted with merchant-initiated transactions, and how the rules applied to new transaction types all required clarification.
• Cross-border payment transparency. Currency conversion charges, transfer times, and ATM fees were not consistently disclosed.

PSD3 and PSR address each of these areas. The two instruments together represent what most legal commentators describe as a rebalancing of the European payments value chain rather than an incremental update.

The PSD3 vs PSR split: why two instruments

The single most important structural change in the new framework is that what was one directive under PSD2 is now two instruments under the new regime. The split is deliberate.

PSD3 (the Directive) covers areas where Member States legitimately retain some discretion:

• Authorisation and supervision of payment institutions and the newly-merged e-money institutions
• Capital and safeguarding requirements
• Governance, outsourcing, and exit planning obligations
• Cross-border passporting rules
• Prudential supervision

Member States must transpose PSD3 into national law within the implementation window. This allows for some local interpretation while maintaining a harmonised baseline.

PSR (the Regulation) covers areas where uniformity matters most for the single market:

• Strong Customer Authentication scope, triggers, and exemptions
• Fraud prevention obligations and reimbursement rules
• Open banking API performance standards and access rights
• Consumer information and transparency requirements
• Liability allocation between PSPs, merchants, and consumers
• IBAN-name matching obligations for credit transfers

The PSR applies directly across all Member States from the day it enters into force. There is no national transposition, no opportunity for local interpretation, and no scope for divergent implementation. For merchants operating cross-border in Europe, this is the single largest practical benefit of the new framework.

How PSD3 and PSR differ from PSD2

The differences between the new framework and PSD2 fall into seven major areas:

1. Single regulatory framework for payment and e-money institutions

The E-Money Directive (Directive 2009/110/EC) is repealed entirely. E-money institutions become a sub-category of payment institutions under PSD3, with a single licensing regime, harmonised governance requirements, and consistent supervisory expectations. Existing e-money institutions will need to apply for re-authorisation under PSD3 during the transition period.

For merchants, this primarily affects how their PSP partners are structured and supervised, but it also simplifies the picture when evaluating new providers: there is one regulatory category to assess rather than two.

2. Mandatory IBAN-name verification

For all credit transfers (not just instant payments), PSPs must verify that the payee name provided by the payer matches the name registered against the destination IBAN. Where there is a discrepancy, the PSP must issue an early warning to the payer before the transfer completes.

This is a major operational change. The mechanism is already in place under the Instant Payments Regulation for SEPA instant transfers, but PSR extends it to all credit transfers. For merchants, the practical impact is on B2B payments, refund processing, and any flow involving bank-to-bank transfers.

3. Expanded fraud liability and reimbursement

PSR significantly strengthens the obligations on PSPs to prevent fraud and reimburse victims. Key changes:

• Mandatory reimbursement for victims of impersonation fraud where the customer believed they were dealing with their bank
• Expanded liability for technical service providers and large online platforms when they fail to remove fraudulent content after notification
• Stronger obligations on PSPs to detect and prevent fraud, with detailed governance requirements
• Clearer rules on shared fraud-related data between PSPs, reducing the regulatory uncertainty that limited collaborative fraud controls under PSD2

For merchants, this changes the fraud risk allocation in subtle but important ways. PSPs will have stronger incentives to share fraud signals, which can benefit legitimate merchants whose transactions get fewer false declines. But the broader reimbursement framework also raises the bar on merchant-side fraud controls, since merchants whose flows facilitate impersonation or push-payment fraud will face greater pressure from their PSPs.

For a deeper view of fraud prevention strategy, see Gr4vy’s guide on payment fraud prevention strategies for 2026.

4. Refined Strong Customer Authentication framework

PSR retains the core SCA framework from PSD2 but clarifies and expands it. The list of actions that trigger SCA is expressly expanded to include:

• Creation or replacement of tokenised payment instruments
• Changes to spending limits
• Amendments to contact details
• Any operation that materially affects the security or risk profile of a payment relationship

The core SCA exemptions (Low Value Transaction, Merchant-Initiated Transaction, Transaction Risk Analysis, Trusted Beneficiary, Secure Corporate Payment) are retained, with the European Banking Authority continuing to develop the relevant regulatory technical standards. The framework is recognisable to anyone familiar with PSD2, but the boundaries are sharper and the application is more consistent.

For merchants, the practical impact is that the SCA exemption strategy that has worked under PSD2 will continue to work under PSR, with the additional clarity making cross-border consistency easier to achieve. Our guide on 3D Secure 2 covers the technical mechanism that satisfies most SCA obligations.

5. Stronger open banking framework

PSR significantly tightens the rules around open banking API performance and access. Key changes:

• Banks must provide dedicated APIs that meet defined performance and uptime standards
• National regulators must act “without delay” against interfaces that do not meet expected standards
• Reliance on fallback interfaces (the “screen scraping” route) is curtailed
• Standardised customer dashboards for managing open banking permissions become mandatory
• Account information service providers (AISPs) gain passporting rights, enabling cross-border service provision with a single home-state registration

For merchants offering pay-by-bank or A2A payment options, the operational reliability of open banking improves substantially. For merchants competing with banks for customer payment relationships, the regulatory playing field tilts further toward open access.

6. Expanded supervisory perimeter for technical service providers

Under PSD2, technical service providers (TSPs) operating behind the scenes for PSPs were largely outside the supervisory perimeter. PSD3 brings them in. Outsourcing arrangements with TSPs that provide SCA, fraud screening, or other critical services must be governed by detailed written agreements covering scope, roles, service levels, audit rights, and exit plans. The European Banking Authority will set further standards for these arrangements.

This change affects merchants indirectly through their PSP relationships. PSPs will require more from their TSP partners, and the operational standards merchants should expect from their payments infrastructure will rise accordingly.

7. Tighter transparency obligations

PSR strengthens consumer-facing transparency requirements:

• Upfront disclosure of currency conversion margins on cross-border payments
• Estimated transfer times for cross-border transactions
• Visible (and in some cases printed) ATM fee disclosures
• Standardised account statements

For merchants processing cross-border transactions, the disclosure obligations affect how prices are presented and how customers are informed of conversion costs.

The definitive comparison: PSD2 vs PSD3/PSR

The pattern across every row is the same: the new framework standardises what was inconsistent, strengthens what was weak, and clarifies what was ambiguous. For merchants operating in a single Member State, the changes are meaningful but manageable. For merchants operating cross-border, the harmonisation benefits are substantial.

The timeline: where things stand in mid-2026

The legislative process is now in its final stages. The key dates as of mid-2026:

The preparation window is real but not generous. For a merchant whose payment stack involves multiple Member States, multiple PSPs, and complex authentication flows, 21 months is a meaningful project timeline but not a comfortable one.

What changes specifically for merchants

The merchant-facing implications of PSD3 and PSR cluster into six areas:

1. SCA scope expansion

New trigger events for SCA include token creation and replacement, spending limit changes, and contact detail updates. Merchants whose flows touch any of these (subscription sign-up, payment method updates, account changes) need to ensure their authentication infrastructure handles the new triggers correctly.

For most enterprise merchants already operating in SCA-regulated markets, this is an incremental adjustment rather than a fundamental change. The infrastructure that handles 3DS2 authentication on initial CITs typically handles the new triggers cleanly.

2. SCA exemption application

The existing SCA exemptions (LVT, MIT, TRA, Trusted Beneficiary, Secure Corporate Payment) are retained. The European Banking Authority continues to develop the technical standards. The practical implication: SCA exemption strategy under PSR will be recognisable to anyone running it well under PSD2, with the additional benefit of more consistent application across Member States.

The MIT exemption is particularly relevant for subscription, installment, and stored-credential merchants. For the full framework, see Gr4vy’s guide on merchant-initiated and customer-initiated transactions.

3. Fraud liability shift

Mandatory reimbursement obligations on PSPs for impersonation fraud and certain other categories raise the bar on PSP fraud controls. For merchants, this generally translates into stronger fraud screening by their PSP partners, with downstream effects on false decline rates and false approval rates.

Merchants whose flows are vulnerable to impersonation fraud or push-payment fraud (B2B invoicing, high-value cross-border, certain marketplace patterns) should expect more scrutiny from PSP partners and may need to strengthen their own controls to maintain commercial terms.

4. Refund and chargeback handling

The IBAN-name verification mandate affects refund flows that use credit transfers. Refunds issued to bank accounts (rather than back to the original card) will need to clear the same name-IBAN matching that all credit transfers do, which adds verification steps but also reduces fraud exposure.

For merchants with high refund volumes or complex refund workflows, this is one of the operationally trickier changes to plan for.

5. Cross-border consistency

Because PSR applies directly across all Member States, merchants operating cross-border benefit from consistent rules without the national variation that PSD2 produced. For merchants whose European volume is concentrated in two or three countries, the benefit is moderate. For merchants operating across 10+ European markets, the consistency reduces compliance overhead meaningfully.

For more on the cross-border picture, see Gr4vy’s guide on recurring payments in Europe.

6. Marketplace and platform implications

The commercial agent exemption (the rule that allows certain marketplaces and platforms to facilitate payments without holding a payment services licence) is being clarified, with the European Banking Authority developing guidelines for consistent national application. The exemption is retained, but its scope and conditions are being refined.

For platforms and marketplaces that currently rely on the commercial agent exemption, the practical impact will not be clear until the final text is published and the EBA guidance is issued. Some platforms may find their current structures need adjustment; others will continue to operate as they do today.

PSD3/PSR for multi-PSP merchants: the orchestration angle

For merchants operating with multiple PSPs, PSD3 and PSR have specific implications that single-PSP analyses tend to miss.

Consistency across PSPs becomes legally required. Under PSD2, different PSPs in different Member States could implement the same regulation slightly differently. The PSR’s direct applicability means all PSPs operating in any EU Member State must apply the same conduct rules. For multi-PSP merchants, this means SCA application, fraud handling, refund processing, and authentication flows will be more consistent across providers than they have been historically.

The integration burden shifts to the orchestration layer. Each new SCA trigger, fraud handling requirement, and IBAN verification rule has to be implemented somewhere in the payment stack. Merchants whose stack is heavily PSP-specific will need to coordinate changes across each PSP integration. Merchants whose stack runs through an orchestration platform can implement changes once and apply them across every connected PSP.

Authentication data portability matters more. With SCA triggers expanding to cover token creation and replacement, the authentication context attached to a stored credential becomes more valuable. If that context is locked inside a single PSP’s records, switching PSPs requires re-establishing authentication relationships. If the context is maintained at the orchestration or merchant layer, it travels across PSP boundaries cleanly. For the broader pattern, see Gr4vy’s analysis of PSP tokens vs network tokens.

Fraud signal sharing benefits compounding scale. The expanded provisions for fraud-related data sharing between PSPs benefit merchants whose orchestration platform can aggregate signals across multiple PSP relationships and apply them consistently. Single-PSP merchants get the benefit of one PSP’s signal pool; orchestration-based merchants get the benefit of multiple.

Routing decisions can target the strongest fraud-control PSP for each transaction. Under the expanded liability framework, PSPs with stronger fraud controls become more attractive routing destinations for high-risk transactions. Multi-PSP merchants with intelligent routing capability can direct transactions to the PSP best positioned to handle each one. For more, see Gr4vy’s guide on intelligent payment routing.

A practical preparation roadmap

For merchants beginning to plan their PSD3/PSR readiness work, the sequence below captures the order most likely to deliver results without rushed compliance work in 2027 and 2028.

Months 1-3 (mid-to-late 2026): Audit and inventory. Map every payment flow that touches an EU-located customer, PSP, or acquirer. Document current SCA application, exemption use, fraud screening, and IBAN handling. Identify which PSP integrations would require changes under the new triggers and obligations. This audit becomes the baseline against which all subsequent work is measured.

Months 3-6 (late 2026 – early 2027): Gap analysis and partner alignment. Work through each gap identified in the audit. Engage PSPs, acquirers, and orchestration partners to understand their roadmaps for PSD3/PSR compliance. Identify which gaps the partners will close on the merchant’s behalf and which require merchant-side changes.

Months 6-12 (2027): Technical implementation. Build or configure the changes identified in the gap analysis. SCA trigger expansion, IBAN verification flows, refund workflow updates, and fraud screening upgrades all typically fall into this window. For merchants using an orchestration platform, this work is concentrated at the orchestration layer rather than spread across each PSP integration.

Months 12-18 (mid-to-late 2027): Testing and validation. End-to-end testing of the updated flows in production-like environments. Conformance testing with PSP partners. Operational team training on the new procedures (especially fraud reimbursement handling and refund verification).

Months 18-21 (2028): Production cutover and stabilisation. The PSR becomes fully applicable in this window. Live operation under the new rules with monitoring, incident response, and tuning as edge cases emerge.

Merchants who start the audit in Q3 2026 will be comfortable. Merchants who wait until late 2027 will be cutting it close.

Common preparation mistakes to avoid

A handful of patterns separate well-prepared merchants from those who struggle in the transition:

Treating it as a PSP problem rather than a merchant problem. PSPs handle a substantial share of the compliance work, but key decisions (SCA exemption strategy, fraud control posture, refund workflow design) belong to the merchant. Outsourcing the question entirely to the PSP produces inconsistent results across multi-PSP setups and limits the merchant’s strategic optionality.

Waiting for the final text before starting work. The final published text will differ from the April 2026 compromise text in minor ways, but the substantive content is now settled. Merchants who wait until the OJ publication to begin work compress their preparation window by months.

Ignoring the cross-border consistency benefit. Many merchants have built complex country-specific workarounds for PSD2 implementation differences across Member States. Under PSR, these workarounds become unnecessary. Audit them now so they can be retired during the transition rather than maintained indefinitely.

Underestimating the IBAN verification scope. The mandatory IBAN-name matching applies to all credit transfers across the board, including bank flows that previously did not require such verification. Merchants with non-card payment flows (refunds via bank transfer, B2B settlement, marketplace payouts) need to plan for verification steps that did not exist under PSD2.

Skipping the fraud control review. The expanded reimbursement obligations on PSPs will translate into PSP-side scrutiny of merchant fraud controls. Merchants whose fraud posture has not been audited recently should expect more questions from PSP partners as the new rules approach.

Failing to align internal teams. Compliance, security, payments engineering, finance, and customer support all touch PSD3/PSR-affected flows. Without explicit coordination, individual teams make assumptions that conflict with each other’s plans.

Frequently asked questions

What is PSD3?

PSD3 (the Third Payment Services Directive) is an EU Directive that updates the authorisation, supervision, and licensing framework for payment service providers and e-money institutions across the EU. It replaces parts of PSD2 and the E-Money Directive (EMD2). PSD3 requires national transposition by each Member State, with a transposition window of 18-21 months after publication.

What is the PSR?

The Payment Services Regulation (PSR) is a directly applicable EU Regulation that governs conduct of business rules for payment services, including SCA, fraud liability, open banking, and consumer transparency. Unlike a directive, the PSR applies uniformly across all EU Member States without national transposition, which is its single most important structural feature.

When do PSD3 and PSR take effect?

The texts are expected to be published in the EU Official Journal in June or July 2026 (potentially slipping to September). The PSR enters into force 20 days after publication and applies fully approximately 21 months later (Q1-Q4 2028). PSD3 requires national transposition over a similar window.

What is the difference between PSD3 and PSR?

PSD3 is a Directive covering authorisation, supervision, and licensing rules where Member States retain some discretion in transposition. PSR is a Regulation covering conduct of business rules where uniformity matters most for the single market. The split allows for local flexibility on supervisory matters while ensuring consistent application of customer-facing rules across all Member States.

Does PSD3 replace PSD2?

Yes. PSD3 and PSR together repeal and replace PSD2 and EMD2. The frameworks that have governed European payments since 2018 are being superseded by the new package.

Does PSD3 change SCA?

PSR (the regulation part of the package) retains the core SCA framework from PSD2 and refines it. The list of actions that trigger SCA is expanded to include token creation and replacement, spending limit changes, and contact detail updates. The core exemptions (LVT, MIT, TRA, Trusted Beneficiary, Secure Corporate Payment) are retained, with the EBA continuing to develop the technical standards.

Will PSD3 affect 3D Secure?

Yes, indirectly. 3DS2 is the dominant technical mechanism for satisfying SCA on card-not-present transactions, and PSD3/PSR refine the SCA framework that 3DS2 supports. Merchants should expect their 3DS2 implementation to handle the expanded SCA triggers (new token creation, spending limit changes, etc.) once the new rules apply. The protocol itself is not changing.

How does PSR affect cross-border payments in the EU?

PSR applies directly across all Member States, eliminating the cross-Member-State variation that PSD2 produced. For merchants operating in multiple EU countries, the rules will be consistent rather than country-specific. Mandatory IBAN-name verification on all credit transfers (including cross-border) adds a verification step but also reduces fraud exposure on bank-to-bank flows.

What is mandatory IBAN-name verification?

Under PSR, PSPs must verify that the payee name provided by the payer matches the name registered against the destination IBAN for all credit transfers. Where there is a discrepancy, the PSP must warn the payer before the transfer completes. This is already mandatory for SEPA instant transfers under the Instant Payments Regulation; PSR extends it to all credit transfers.

What happens to e-money institutions under PSD3?

The E-Money Directive (EMD2) is repealed. E-money institutions become a sub-category of payment institutions under PSD3, with a single licensing regime. Existing e-money institutions must apply for re-authorisation under PSD3 during the transition period.

Will PSD3 affect open banking?

Yes, significantly. PSR tightens the requirements for open banking API performance and uptime, requires national regulators to act “without delay” against poorly-performing interfaces, and curtails reliance on fallback interfaces. AISPs gain passporting rights, enabling cross-border service provision with a single home-state registration. Customer dashboards for managing open banking permissions become mandatory.

Will PSD3 apply to UK merchants?

Not directly. The UK is no longer in the EU and is not bound by PSD3 or PSR. However, UK merchants serving EU customers will need to comply with PSD3/PSR for those transactions, and UK PSPs operating in the EU under passporting will need to align their EU operations with the new framework. The UK has its own ongoing review of payment services regulation, with some divergence from the EU framework expected.

How does PSD3 affect merchant fraud liability?

PSR expands fraud reimbursement obligations on PSPs, particularly for impersonation fraud and certain other categories. This generally translates into stronger fraud screening by PSPs (with downstream effects on false decline rates) rather than direct changes to merchant fraud liability. However, merchants whose flows facilitate impersonation or push-payment fraud may face stronger scrutiny from PSP partners.

What do merchants need to do to prepare?

The practical preparation work falls into five phases over roughly 18 months: audit current flows against the new rules, conduct gap analysis with PSPs and orchestration partners, implement technical changes (SCA triggers, IBAN verification, refund workflows), test end-to-end before the deadline, and execute the production cutover when PSR becomes applicable. Merchants who start the audit in 2026 will be comfortable; those who wait until 2027 will be working under time pressure.

What to do next

PSD3 and PSR represent the most significant regulatory shift in European payments since PSD2 came into effect. The headline changes (single regulatory framework, mandatory IBAN-name matching, expanded fraud liability, stronger open banking) attract the most attention, but the structural shift to a directly-applicable regulation is what will produce the largest practical benefits for merchants operating cross-border in Europe.

For most enterprise merchants, the preparation work is substantial but not unprecedented. The infrastructure that was built for PSD2 compliance is the starting point. The SCA framework that handled the 2019-2021 transition handles most of the PSR’s SCA changes cleanly. The fraud controls that have evolved since PSD2 came into effect are the foundation for the expanded reimbursement framework. The work involves adjusting, refining, and harmonising existing systems instead of rebuilding from scratch.

The merchants who emerge from the transition in the strongest position will share three characteristics. Their payment infrastructure will be flexible enough to absorb the new triggers, obligations, and verification steps without rebuilding. Their PSP and acquirer relationships will be aligned with the new framework instead of being locked into PSD2-era assumptions. And their cross-border operations will benefit from the harmonisation that PSR delivers, with the country-specific workarounds of the PSD2 era retired during the transition.

Gr4vy’s cloud-native payment orchestration platform handles PSD3/PSR compliance work centrally across more than 400 connected PSPs and payment methods. SCA triggers, exemption application, IBAN verification, and fraud control coordination all operate at the orchestration layer instead of being spread across each PSP integration. For merchants planning their preparation roadmap, this concentrates the implementation work in one place across every provider relationship.

If you’re evaluating your current PSD2 stack against the new requirements or want to understand how the transition could be unified across your existing PSP relationships, contact our team for a stack review and preparation plan tailored to your current architecture.

3D Secure 2 (3DS2) is the authentication protocol that decides whether most of your card-not-present transactions get approved silently, get challenged with extra friction, or get declined entirely. It governs how Strong Customer Authentication is satisfied across Europe, the UK, India, Japan, and now Asia-Pacific markets after the April 2026 Visa and Mastercard enforcement milestone. For European merchants, it has been mandatory for years. For everyone else, it is becoming the global standard for online card payment security.

The merchants who understand 3DS2 well capture meaningful authorization rate lifts, shift chargeback liability to issuers on authenticated transactions, and avoid the conversion drop that plagued the older 3DS1 protocol. The merchants who treat it as a compliance checkbox leak revenue at every step: unnecessary challenges, false declines, missed exemptions, and chargeback losses that should have been the issuer’s problem.

This guide explains what 3DS2 is, how the protocol actually works, the difference between frictionless and challenge flows, how SCA exemptions stack on top, the global regulatory picture as it stands in 2026, and what enterprise merchants should be doing to optimize authentication performance across multiple PSPs and acquirers.

A clear definition: 3DS2 in one sentence

3D Secure 2 (3DS2) is a real-time card authentication protocol that allows the issuing bank to verify a cardholder’s identity during a card-not-present transaction by exchanging rich contextual data with the merchant’s payment infrastructure, with the issuer deciding whether to approve the transaction frictionlessly, challenge the cardholder for additional verification, or decline.

Three elements define the protocol:

A data exchange. The merchant’s 3DS infrastructure sends over 100 data elements to the issuer at the moment of authorization, including device fingerprint, transaction history, IP address, billing and shipping consistency, merchant category, and transaction amount. The issuer uses this data to assess risk.

A real-time decision by the issuer. Based on the data and its own risk model, the issuer decides one of three outcomes: approve silently (the frictionless flow), approve after a customer challenge, or decline.

A liability shift on authenticated transactions. When an issuer authenticates a transaction through 3DS2, the chargeback liability for fraud disputes shifts from the merchant to the issuing bank. This is the single most commercially significant aspect of the protocol for enterprise merchants.

For a deeper look at how this fits into the broader authentication picture, see Gr4vy’s guide on payment authentication.

3DS1 vs 3DS2: what actually changed

To understand why 3DS2 matters, it helps to know what 3DS1 did badly. The original 3D Secure protocol launched in 1999 (as Verified by Visa) and authenticated cardholders through static passwords and full-page browser redirects. It worked technically, but it produced one of the worst conversion impacts of any payment technology in the modern era.

The problems with 3DS1:

• Static password authentication. Customers forgot the passwords they had set up years earlier, leading to abandonment at the authentication step.
• Disruptive full-page redirects. The customer was sent away from the merchant’s checkout to an issuer-controlled authentication page, often with inconsistent branding that triggered phishing concerns.
• No mobile optimization. The protocol was designed for desktop browsers and did not work well in mobile apps, where it required clunky iframes or popups.
• Limited data exchange. Only a handful of fields could be passed to the issuer, leaving the issuer to make authentication decisions with limited context.
• Activation-during-shopping flows. Cardholders who had not yet enrolled in 3DS were forced into enrollment during checkout, often abandoning the transaction.

3DS2 (also called EMV 3-D Secure, formally maintained by EMVCo and used in current network programs like Visa Secure and Mastercard Identity Check) was redesigned to fix these problems. The differences:

3DS1 has been sunset by the major card schemes. Current implementations use EMV 3DS version 2.2 or 2.3.x, with version 2.3 adding updates targeted at mobile-native authentication and decoupled authentication scenarios.

How 3DS2 actually works: the four-component protocol

A 3DS2 transaction involves four interoperating components that communicate in real time during the authentication request. Understanding these components is essential for diagnosing authentication problems and optimizing performance.

1. The 3DS Server (sometimes called the 3DS Requestor) sits inside the merchant’s payment infrastructure (or their PSP’s, or their orchestration platform’s). It collects the transaction data, formats the authentication request, and sends it to the Directory Server.

2. The Directory Server (DS) is operated by the card scheme (Visa, Mastercard, American Express, JCB, Discover). It routes the authentication request to the appropriate issuer’s Access Control Server based on the card BIN.

3. The Access Control Server (ACS) is operated by the issuer (or their authentication vendor). It applies the issuer’s fraud and risk model to the transaction data, decides the outcome, and returns the response.

4. The 3DS SDK (for mobile transactions) is integrated into the merchant’s iOS or Android app. It collects device and behavioral data and submits the authentication request natively, avoiding the web-view friction that mobile 3DS1 created.

The flow during a transaction:

1. The customer reaches the merchant’s checkout and submits the payment
2. The 3DS Server packages 150+ data elements about the transaction (device fingerprint, IP, billing/shipping addresses, transaction amount, merchant category, customer history)
3. The Directory Server routes the request to the right issuer’s ACS
4. The ACS applies the issuer’s risk model in milliseconds
5. The ACS returns one of three outcomes: frictionless authentication (approve silently), challenge required (ask the cardholder for verification), or authentication failed
6. If a challenge is required, the customer completes a biometric, OTP, or in-app prompt
7. The authentication result is returned to the merchant, who then submits the authorization request with the authentication context attached
8. The issuer authorizes (or declines) the underlying payment

All of this happens in seconds. For the majority of transactions, the customer experiences nothing visible.

Frictionless vs challenge flow: where the data quality investment pays off

The single most important strategic concept in 3DS2 is the distinction between frictionless and challenge flows. The issuer decides which one to use based on the data it receives. Better data produces more frictionless approvals; worse data produces more challenges and more drop-offs.

Frictionless flow

The issuer evaluates the transaction data, judges the risk acceptable, and approves the authentication without any customer interaction. The customer notices nothing. The merchant gets the liability shift. This is the outcome every merchant should be optimizing for.

The data elements that increase the likelihood of a frictionless decision include:

• Device data: browser fingerprint, device ID, screen resolution, time zone, IP address
• Behavioral data: time on page, previous transaction history with the merchant, account age, number of purchases in the last 24 hours
• Order data: shipping address, delivery timeframe, digital vs physical goods flag, gift indicator
• Merchant data: Merchant Category Code (MCC), acquirer BIN, requestor name
• Transaction data: amount, currency, frequency

A returning customer on a recognized device, transacting with a familiar merchant for a normal amount, will almost always receive frictionless authentication. A new customer on an unfamiliar device, with mismatched billing and shipping addresses, transacting for an unusual amount, will likely face a challenge.

The implication for payment teams is direct: incomplete data integrations generate unnecessary challenges. If your 3DS Server is omitting device fingerprinting fields, missing account history, or sending stale shipping addresses, your issuers are challenging transactions they would otherwise approve frictionlessly. Authentication rates drop, and revenue with them.

Challenge flow

The issuer decides the risk warrants additional verification and prompts the cardholder to complete an authentication challenge. The challenge is usually a biometric prompt (fingerprint, Face ID), an OTP sent via SMS or in-app push, or a banking app confirmation.

Challenge flows serve a real purpose: they protect high-risk transactions from fraud while still permitting legitimate purchases to proceed. The problem is that challenges produce drop-off. Industry data suggests 10-30% of customers abandon at the challenge step depending on the implementation quality, the customer’s familiarity with their bank’s authentication method, and the device.

The merchants who minimize unnecessary challenges through better data quality, more frictionless eligibility, and smart use of exemptions consistently achieve higher net authorization rates than those who challenge everything.

Failed authentication

The third possible outcome is that the authentication fails entirely. Common reasons:

• The customer enters incorrect challenge data (wrong OTP, failed biometric)
• The issuer’s ACS times out or returns an error
• The cardholder is not enrolled in 3DS at all
• The transaction is flagged as definitively fraudulent

Failed authentication typically results in a declined transaction, though some merchants configure their workflows to retry through a different authentication path or to fall back to non-3DS processing in markets where that is permissible.

SCA and the regulatory picture in 2026

Strong Customer Authentication (SCA) is a regulation. 3DS2 is a protocol. The two are often used interchangeably, but they are distinct.

SCA is a regulatory requirement that says electronic payments above a defined threshold must be authenticated using two of three factors: something the cardholder knows (password, PIN), something they have (phone, hardware token), or something they are (biometric). It was introduced in Europe through PSD2’s Regulatory Technical Standards, took effect in 2019-2021 depending on the country, and has been fully enforced (no soft-decline grace period) since 2022.

3DS2 is the dominant technical mechanism for satisfying SCA on card-not-present transactions. Other authentication paths exist, but for most online card payments in SCA-regulated markets, 3DS2 is the path that gets used.

The 2026 regulatory picture by market:

Europe and UK. SCA is fully enforced. Non-authenticated card-not-present transactions get declined by issuers unless they qualify for a specific exemption (more on those in the next section). PSD3 and the Payment Services Regulation (PSR) are in late-stage trilogue between the European Commission, Council, and Parliament as of mid-2026, with the consolidated text expected to be adopted in the second half of 2026 and to apply 18 months after publication. PSD3 will refine rather than replace the SCA framework, but new 3DS implementations should anticipate its direction.

Asia-Pacific. Both Visa and Mastercard set April 2026 as the critical enforcement and fine-escalation milestone for issuers and acquirers in the APAC region. Markets including India, Japan, Singapore, and Australia have aligned to global 3DS2 standards, with India operating its own SCA-equivalent rules through the Reserve Bank of India.

Mastercard Identity Check set October 2025 as the hard deadline for all acquirers in the EEA to be compliant with the current Identity Check program. From October 2026, additional Mastercard mandates relating to transaction tracking come into effect (see Gr4vy’s guide on the Mastercard Transaction Link Identifier for the full timeline).

United States. SCA is not currently mandated, but 3DS2 is widely supported and increasingly adopted for liability shift on high-risk transactions. The US Payments Forum publishes ongoing guidance for US merchants implementing 3DS2 selectively.

For European subscription businesses specifically, recurring payments interact with SCA in important ways. Our guide on recurring payments in Europe covers the compliance and conversion implications in detail.

SCA exemptions: how to reduce friction without losing compliance

Not every transaction needs to go through a 3DS2 challenge. PSD2 and similar regulations include several exemptions, and using them well is one of the highest-impact authentication optimizations available.

The five main SCA exemptions:

1. Transaction Risk Analysis (TRA)

The acquirer or issuer determines, based on real-time risk scoring, that the transaction is low risk and qualifies for SCA exemption. TRA is the most commercially valuable exemption because it can be applied to a large share of standard ecommerce transactions, but it requires the acquirer to maintain a low fraud rate (below specific thresholds defined by PSD2).

TRA thresholds are tied to fraud rates:

• Acquirer fraud rate below 0.13%: TRA exemption applies to transactions up to €100
• Acquirer fraud rate below 0.06%: TRA exemption applies to transactions up to €250
• Acquirer fraud rate below 0.01%: TRA exemption applies to transactions up to €500

This is why acquirer choice matters. Acquirers with clean fraud books unlock TRA on higher transaction values for their merchants. Acquirers with elevated fraud rates lose TRA eligibility, with measurable conversion impact.

2. Low Value Transaction (LVT)

Transactions below €30 are exempt from SCA, provided the cardholder has not made more than five LVT-exempted transactions or accumulated more than €100 in LVT exemptions since their last full SCA authentication.

LVT is useful for low-AOV businesses (digital goods, microtransactions, parking, transit) but the cumulative limits prevent it from being a blanket solution.

3. Merchant-Initiated Transaction (MIT)

MITs are exempt from SCA when properly classified, provided the original CIT that established the stored-credential relationship underwent SCA authentication. This is the exemption that makes subscription billing, installments, and unscheduled credential-on-file payments work in SCA-regulated markets without re-authenticating the customer for every charge.

For the full framework, see Gr4vy’s guide on merchant-initiated and customer-initiated transactions.

4. Trusted Beneficiary

The cardholder can add a specific merchant to a “trusted list” maintained by their issuer, allowing future transactions with that merchant to bypass SCA. This is rarely used for general ecommerce because it requires customer action to set up, but it has applications in B2B and high-frequency commerce.

5. Secure Corporate Payment

Lodged-card programs, virtual cards, and corporate procurement payments that meet PSD2’s secure corporate payment process criteria can be exempted. This is mostly relevant to travel and B2B procurement rather than B2C ecommerce.

The exemption that produces the biggest authorization lift for most merchants is TRA. Combining TRA with MIT classification on recurring billing typically eliminates most challenge flows in a properly-implemented stack, while maintaining full SCA compliance.

Liability shift: what actually shifts and what does not

The liability shift is one of the most commercially significant aspects of 3DS2 implementation, but it is often misunderstood. The rules are specific.

What does shift: When a transaction is authenticated through 3DS2 (whether frictionless or challenge) and the cardholder subsequently disputes the transaction as fraudulent, the chargeback liability transfers from the merchant to the card-issuing bank. The merchant is not responsible for the fraud loss.

What does not shift:

• Non-fraud disputes. If the customer disputes a transaction for non-fraud reasons (product not received, item not as described, billing errors), 3DS2 authentication does not shift liability. The merchant remains responsible for those disputes through the standard chargeback process.
• Unenrolled cards. If the cardholder’s card is not enrolled in 3DS2 and the transaction proceeds without authentication, no liability shift applies.
• Technical failures. If the 3DS infrastructure times out or fails for technical reasons and the merchant processes the transaction anyway, the liability shift typically does not apply.
• Bypass cases. If the merchant or PSP chooses to bypass 3DS2 (for example, by applying an SCA exemption), the liability shift is replaced by the exemption’s own rules.
• Friendly fraud beyond standard fraud disputes. Some forms of first-party fraud (where the legitimate cardholder claims a transaction was fraudulent when it was not) can be defended even on 3DS-authenticated transactions, but the dispute process and burden of proof differ.

For enterprise merchants processing meaningful CNP volume, the liability shift typically represents six- to seven-figure annual savings on chargeback losses. The shift is real, measurable, and one of the strongest financial cases for properly implementing 3DS2.

Where 3DS2 fits in the multi-PSP picture

Most coverage of 3DS2 treats it as a single-PSP integration question: which 3DS server to use, how to configure the SDK, how to handle the response. For enterprise merchants running multi-PSP setups, the picture is more nuanced.

Three architectural patterns exist:

Pattern 1: PSP-managed 3DS. Each PSP handles its own 3DS authentication. The merchant integrates with each PSP’s 3DS server separately. Different PSPs may implement 3DS slightly differently, with different data field handling, different challenge UX, and different exemption application logic. The result is inconsistent authentication performance across providers and operational complexity scaling with each PSP added.

Pattern 2: Standalone 3DS server. The merchant uses a dedicated 3DS server provider (separate from any single PSP) and routes authentication through it before submitting authorization to whichever PSP processes the transaction. This decouples authentication from payment processing but adds another vendor relationship and integration point.

Pattern 3: Orchestration-managed 3DS. A payment orchestration platform handles 3DS authentication centrally, applying consistent data field handling, exemption logic, and challenge UX across every PSP it routes to. The merchant configures the 3DS rules once, and the platform applies them regardless of which acquirer processes the authorization.

The third pattern is the cleanest fit for multi-PSP merchants. Authentication performance becomes consistent. Exemption logic is applied uniformly. Data quality is controlled in one place rather than depending on each PSP’s integration. And critically, the 3DS authentication context can be carried forward through routing decisions, including failover and retry scenarios.

For more on how this works in practice, see Gr4vy’s guides on intelligent payment routing and how to increase payment approval rates in 2026.

How 3DS2 interacts with retries and decline recovery

When a transaction fails authentication or is declined after authentication, the retry logic that follows interacts with 3DS in important ways.

Soft declines after successful authentication. If 3DS2 authenticates the transaction but the subsequent authorization is soft-declined (insufficient funds, network timeout), the authentication context typically remains valid for a retry within a defined window (usually 24-72 hours). The merchant can retry without re-authenticating, preserving both the liability shift and the absence of friction.

Authentication failures. If 3DS2 authentication itself fails, retrying immediately rarely succeeds because the issuer’s risk decision will not change. The standard pattern is to either fall back to non-3DS processing where regulations permit, prompt the customer to update their card details, or escalate to customer outreach.

Exemption-based retries. A transaction that was challenged at the first attempt may be retried as an exempted transaction if the merchant’s acquirer supports TRA exemption and the transaction qualifies. This is one of the more sophisticated retry patterns and requires workflow logic to evaluate exemption eligibility before each retry.

For the full retry framework, see Gr4vy’s guide on subscription payment decline recovery.

Common 3DS2 mistakes and how to avoid them

A handful of patterns separate well-implemented 3DS2 setups from troubled ones:

Sending incomplete data. The single largest source of unnecessary challenges is missing or stale data fields. Issuers challenge transactions when they cannot confidently assess risk; incomplete data forces them into that position. Audit your 3DS data field coverage against the EMVCo specification and fix gaps before optimizing anything else.

Treating 3DS as a binary on/off. Some merchants enable 3DS for every transaction; others disable it entirely. Both extremes leave revenue on the table. The optimal pattern is rule-based application: 3DS applied where SCA requires it or where the liability shift is valuable, exempted via TRA where the risk profile permits, and bypassed where regulations allow and the fraud cost is acceptable.

Implementing 3DS at the PSP level rather than the workflow level. Each PSP applies 3DS slightly differently. Without a common orchestration layer, the same transaction can be authenticated frictionlessly by one PSP and challenged by another, producing inconsistent performance across the stack.

Missing the MIT-CIT linkage. For recurring billing, the SCA exemption on subsequent MITs depends on the original CIT having been properly authenticated. Implementations that skip SCA on the initial sign-up CIT find themselves unable to claim the MIT exemption on renewals, with every renewal then subject to authentication that cannot complete (the customer is not present).

Ignoring the mobile experience. 3DS2 on mobile through web views produces measurably worse results than native SDK implementation. Apps that rely on browser-based 3DS see higher abandonment than apps using the native iOS or Android SDKs.

Failing to monitor authentication performance. 3DS2 performance varies by issuer, geography, card type, and transaction context. Without segmented monitoring (frictionless rate by issuer, challenge completion rate by device, false decline rate by transaction value), problems hide in aggregate metrics and never get diagnosed.

Treating challenges as inherent friction rather than fixable. When challenges happen, the data the merchant sent was insufficient to convince the issuer otherwise. The challenge is a signal that something about the merchant’s data quality, fraud history, or exemption strategy is suboptimal. Treating challenges as a feedback loop rather than an inevitability is what separates high-authorization merchants from average ones.

Frequently asked questions

What is 3D Secure (3DS2)?

3D Secure 2 (3DS2) is a real-time card authentication protocol that allows the issuing bank to verify a cardholder’s identity during a card-not-present transaction. It exchanges rich contextual data with the merchant’s payment infrastructure, and the issuer decides whether to approve the transaction frictionlessly, challenge the cardholder for additional verification, or decline. Successful 3DS2 authentication shifts chargeback liability for fraud disputes from the merchant to the issuing bank.

What is the difference between 3DS and 3DS2?

3DS1 (the original protocol from 1999) used static passwords and disruptive full-page redirects, exchanging only a handful of fields with the issuer. It produced high abandonment and poor mobile experience. 3DS2 (the current standard maintained by EMVCo) exchanges over 150 data elements per transaction, uses risk-based authentication, supports biometrics and native mobile SDKs, and approves most transactions frictionlessly without customer interaction. 3DS1 has been sunset by the major card networks; current implementations use EMV 3DS 2.2 or 2.3.x.

What is the difference between 3DS2 and SCA?

3DS2 is a technical protocol. SCA (Strong Customer Authentication) is a regulatory requirement. SCA mandates that electronic payments be authenticated using two of three factors (something you know, have, or are). 3DS2 is the dominant technical mechanism for satisfying SCA on card-not-present transactions, but it is not the only one. The two are often conflated but they describe different things: one is the regulation, the other is one of the technologies that complies with it.

Is 3DS2 required for all transactions?

No. 3DS2 is required where SCA regulations mandate it (currently Europe, UK, India, Japan, and increasingly Asia-Pacific markets) and is recommended where the liability shift on authenticated fraud is commercially valuable. Even in SCA-regulated markets, several exemptions allow specific transactions to bypass 3DS2 challenges while remaining compliant. In the US and other markets without SCA mandates, 3DS2 is used selectively for high-risk transactions rather than universally.

What is frictionless authentication?

Frictionless authentication is the 3DS2 outcome where the issuer evaluates the transaction data, judges the risk acceptable, and approves the authentication without requiring any customer interaction. The customer notices nothing; the merchant gets the liability shift. Most modern 3DS2 transactions should resolve frictionlessly when the merchant sends complete, high-quality data. Frictionless rates of 90% or higher are achievable for well-implemented stacks.

Why do some 3DS2 transactions get challenged?

A challenge happens when the issuer’s risk model judges that the transaction warrants additional verification before approval. Common triggers include: unusual transaction amounts, mismatches between billing and shipping addresses, unfamiliar devices, new customers without transaction history, transactions in high-risk merchant categories, and incomplete data sent by the merchant. Improving data quality typically reduces challenge rates significantly.

What is the liability shift?

When a transaction is authenticated through 3DS2 (whether frictionless or challenge) and the cardholder subsequently disputes it as fraudulent, the chargeback liability transfers from the merchant to the issuing bank. The merchant is not responsible for the fraud loss. The shift applies only to fraud disputes; non-fraud chargebacks (item not received, billing errors, etc.) remain the merchant’s responsibility even on 3DS-authenticated transactions.

What is TRA exemption?

Transaction Risk Analysis (TRA) is an SCA exemption that allows the acquirer or issuer to bypass 3DS2 challenges on transactions judged to be low risk in real time. TRA eligibility is tied to the acquirer’s fraud rate: acquirers with cleaner fraud books can exempt transactions up to higher thresholds (€100, €250, or €500 depending on the fraud band). For most merchants, TRA is the most commercially valuable exemption available and the strongest reason to evaluate acquirer fraud performance during PSP selection.

Are MITs subject to 3DS2?

Properly classified merchant-initiated transactions (MITs) are exempt from SCA, provided the original customer-initiated transaction (CIT) that established the stored-credential relationship underwent SCA authentication. This is the exemption that makes subscription billing, installments, and unscheduled credential-on-file payments work in SCA-regulated markets without re-authenticating the customer for every charge. The full framework is covered in Gr4vy’s guide on MIT vs CIT.

Does 3DS2 work on mobile apps?

Yes. EMV 3DS2 provides native iOS and Android SDKs that allow authentication to happen directly inside the mobile app, avoiding the web-view friction that affected 3DS1 on mobile. Native SDK implementation typically produces higher frictionless rates and lower challenge abandonment than web-based 3DS on mobile. Mobile-first businesses should always use the native SDK rather than browser-based 3DS through a web view.

How does 3DS2 affect authorization rates?

Implemented well, 3DS2 typically improves net authorization rates by reducing fraud-related declines and unlocking the liability shift on authenticated transactions. Implemented poorly (with incomplete data, unnecessary challenges, or missing exemption logic), it can reduce authorization rates by producing challenge abandonment and false declines. The difference between well-implemented and poorly-implemented 3DS2 can be 5-15 percentage points of authorization rate on the affected volume.

Will 3DS2 hurt my conversion rate?

Properly implemented, 3DS2 should not meaningfully hurt conversion. Most transactions resolve frictionlessly with no customer-visible step. Challenge rates can be minimized through complete data integration and smart exemption use. Modern 3DS2 implementations with native mobile SDKs, biometric challenges, and TRA exemption strategies typically achieve conversion impacts under 1-2% on the affected volume, well below 3DS1’s typical 5-15% impact.

What is the difference between EMV 3DS 2.2 and 2.3?

EMV 3DS 2.3 (released in 2023, with version 2.3.1 in 2024) adds improvements over 2.2 in several areas: stronger mobile-native authentication, support for decoupled authentication (where the customer authenticates asynchronously through a banking app), better handling of secure remote commerce integrations, and additional data fields. Most modern implementations use 2.2 or 2.3.x; 2.3 adoption is growing but is not yet universal across all issuers.

How does 3DS2 interact with the Mastercard TLID mandate?

The Mastercard Transaction Link Identifier (TLID), which takes full effect in October 2026, is separate from 3DS2 authentication but interacts with it on stored-credential transactions. When the original CIT is authenticated through 3DS2 with SCA, the authentication context flows forward to subsequent MITs through the TLID and related fields, preserving both the SCA exemption and the chain-of-consent that issuers use to approve MIT renewals. For details on TLID specifically, see Gr4vy’s Mastercard TLID guide.

What to do next

3DS2 is one of the highest-impact authentication optimizations available to any merchant with meaningful card-not-present volume. The merchants who treat it as a configurable workflow (rich data, exemption strategy, multi-PSP consistency, native mobile SDKs) consistently outperform those who treat it as a compliance checkbox.

For most enterprise merchants, the work falls into three categories: ensuring data field coverage is complete and current, applying SCA exemptions where regulations and acquirer fraud rates permit, and unifying 3DS implementation across PSPs so authentication performance is consistent regardless of routing decisions.

Gr4vy’s cloud-native payment orchestration platform handles 3DS2 implementation centrally across more than 400 connected PSPs and payment methods. Rich data fields are managed at the orchestration layer rather than per-PSP. Exemption logic is applied consistently. The authentication context flows forward through routing, retry, and failover decisions, preserving both the liability shift and the SCA exemption on related transactions.

If you’re evaluating your current 3DS2 setup or want to understand how authentication could be unified across your existing PSP relationships, contact our team for a stack review and integration plan tailored to your current architecture.

Every card transaction is classified by the card networks as either customer-initiated (CIT) or merchant-initiated (MIT). The distinction sounds technical, but it determines how the issuing bank treats the transaction, whether Strong Customer Authentication is required, how decline rates behave, what fees apply, and whether the merchant is exposed to chargeback liability. Misclassified transactions decline more often, trigger unnecessary authentication friction, and increase compliance risk. Correctly classified transactions process cleanly and benefit from rules designed specifically for their category.

For subscription businesses, marketplaces, and any merchant running card-on-file or recurring billing, the CIT-MIT framework is the single most important set of rules to get right. It governs everything from when 3D Secure is required to how the new Mastercard Transaction Link Identifier propagates across renewals.

This guide explains what CITs and MITs are, the eight MIT use cases the card networks formally recognize, the indicators that must accompany each one, how SCA exemptions work, and what merchants need to do to keep their transactions correctly classified across multiple PSPs and acquirers.

A clear definition: CIT and MIT in one sentence each

A customer-initiated transaction (CIT) is a payment where the cardholder is actively present and participating in the transaction at the moment it happens, providing card details, authorizing the charge, or completing authentication in real time.

A merchant-initiated transaction (MIT) is a payment that the merchant triggers without the customer’s active involvement at the moment of the charge, based on a prior agreement with the cardholder that authorized the merchant to do so.

The distinction comes down to who initiates the authorization at the moment it occurs, regardless of who benefits from the transaction. Both transaction types flow through the same card networks, but the networks apply different rules to each.

How CITs and MITs differ across every dimension

The defining mechanic across all these differences is the same: a CIT establishes the consent and the credential relationship, and every subsequent MIT references that original CIT to inherit its authorization context. Get the link right and the chain works. Get it wrong and the chain breaks, with every MIT in the broken chain treated as a fresh, suspicious, fully-authenticatable transaction.

The eight MIT use cases recognized by the card networks

Visa formalized the modern MIT framework in 2017. Mastercard updated theirs in late 2021 to include eight specific use cases, broadly aligned with Visa’s framework. Every MIT must be classified as one of these eight types, and the classification affects how the transaction is processed:

1. Recurring payments

Scheduled, fixed-frequency payments of a fixed or variable amount, agreed to in advance. The classic example is a monthly subscription. Visa’s indicator for recurring CIT storage is R (credential stored for subsequent recurring MITs).

2. Installment payments

Scheduled payments of a known total amount, split into a defined number of installments. Common in BNPL and large-purchase financing. Visa’s indicator is I (credential stored for subsequent installment MITs).

3. Unscheduled credential-on-file (UCOF)

Payments triggered by an event rather than a schedule, against a stored credential. Examples include account top-ups, automatic refills, and one-tap repeat purchases initiated by the merchant based on a stored agreement. Visa’s indicator is C (credential stored for unscheduled subsequent MITs or for subsequent CITs).

4. Resubmission

A merchant-initiated retry of a transaction that previously declined for specific reasons (typically insufficient funds), submitted under the original authorization context. Must reference the original CIT’s network transaction ID.

5. Delayed charge

A charge submitted after the original CIT, typically for incremental services or additional costs that were authorized as part of the original agreement. Common in hospitality (minibar charges added after checkout) and rental services (additional usage fees).

6. No-show

A charge applied when a customer fails to honor a reservation, with prior authorization from the original booking CIT. Standard in hotels, restaurants, car rentals, and any reservation-based business.

7. Reauthorization

A new authorization request for a transaction whose original authorization has expired or whose amount needs adjustment, against the same stored agreement. Common in travel and hospitality for extended stays.

8. Incremental authorization

An additional authorization on top of an existing one, to increase the authorized amount as services accumulate. Common in fuel pumps, hotels (incidentals), and any transaction with growing or uncertain final amounts.

Each of these eight types has a specific transaction indicator that must be sent with the authorization request. Sending the wrong indicator (or no indicator) can cause the issuer to decline the transaction, treat it as a fresh CIT requiring authentication, or flag it for fraud review.

How CIT to MIT actually works: the consent chain

Every MIT depends on a prior CIT that established the consent and the credential storage. The chain works in three phases:

Phase 1: Initial CIT (consent capture)

The customer reaches the merchant’s checkout, enters card details, and explicitly agrees to terms that authorize the merchant to use the stored credential for future transactions. In SCA-regulated regions, the merchant must perform Strong Customer Authentication on this CIT (typically through 3D Secure 2 with a challenge if the issuer requires it).

The merchant must:

• Capture explicit consent (separate from general terms and conditions)
• Identify the type of stored credential the consent covers (recurring, installment, unscheduled, or general CIT storage)
• Submit the appropriate Credential-on-File (COF) indicator in the authorization request
• Receive and store the network transaction ID (sometimes called network transaction reference or NTID) returned in the authorization response
• For Mastercard, also capture and store the Transaction Link Identifier (TLID)

Phase 2: Credential storage

The card is stored in a secure vault, typically with network tokenization layered on top to handle automatic credential lifecycle updates. The stored credential is linked to:

• The customer’s account
• The original CIT’s network transaction ID
• The Mastercard TLID (where applicable)
• The COF indicator showing what type of future transactions are authorized

This metadata is what makes future MITs work. Without it, every renewal looks like a fresh, suspicious card-not-present transaction.

Phase 3: Subsequent MITs

When the merchant initiates a future charge (subscription renewal, installment, top-up, etc.), the authorization request includes:

• The stored credential (often a network token)
• The MIT type indicator (one of the eight use cases above)
• The original CIT’s network transaction ID (or a previous MIT’s network transaction ID, depending on the scheme)
• For Mastercard, the TLID retained from the original CIT

The issuer sees the chain: “this MIT is part of an installment plan authorized in CIT X, processed Y days ago, with this customer.” The issuer treats it as a low-risk transaction governed by prior consent and approves it without requiring fresh authentication.

If any link in this chain breaks (missing network transaction ID, wrong MIT indicator, lost TLID), the issuer loses the context. The transaction looks like a fresh card-not-present charge with no consent history, and gets treated accordingly: higher decline rates, fraud flags, and in SCA regions, demands for re-authentication that cannot be satisfied because the customer is not present.

For more on Mastercard’s TLID specifically and how it propagates across the chain, see Gr4vy’s guide on the Mastercard Transaction Link Identifier mandate.

SCA exemptions: why MIT classification matters in Europe

Under PSD2 in Europe (and similar regulations in the UK, Japan, and a growing list of jurisdictions), most electronic payments require Strong Customer Authentication. The MIT framework provides a critical exemption: properly classified MITs are out of scope for SCA, because the authentication happens once on the original CIT and is carried forward through the MIT framework.

For an MIT to qualify for SCA exemption, two conditions must be met:

1. The original CIT must have undergone SCA authentication, typically via 3D Secure 2 with the challenge mandated flag set
2. Every subsequent MIT must include the correct COF indicator identifying the transaction type and referencing the original CIT

If either condition fails, the MIT loses its exemption status and the issuer is entitled to decline it or demand re-authentication.

This is why correct MIT classification is not optional for European subscription businesses. A misclassified MIT in an SCA-regulated market is a transaction that will decline more often, trigger 3DS challenges that cannot complete (the customer is not present), and create chargeback exposure that the merchant cannot defend.

The same logic applies to Japan’s SCA mandate, the upcoming PSD3/PSR rules in Europe, and the gradual rollout of SCA-equivalent requirements in other markets. Markets that do not have explicit SCA mandates still benefit from correct MIT classification because issuers in those markets use the same indicators to inform their risk decisioning.

The network transaction ID and why it is the most critical field

Across both Visa and Mastercard, the network transaction ID (Visa Transaction ID, Mastercard scheme transaction ID) is the single most important field in the MIT chain. It is the value the issuer uses to confirm that the current MIT belongs to a previously-established stored credential relationship.

A few important properties:

• Generated by the network during the original CIT authorization. The merchant does not create it; the merchant receives it in the authorization response and stores it.
• Required on every subsequent MIT. For Visa, the value from any prior MIT in the chain can be used. For other schemes, the value from the original CIT (or the relationship-establishment transaction) is required.
• Persistent across the lifetime of the stored credential. Even years after the original CIT, the same network transaction ID is referenced on the latest subscription renewal.
• Not the same as the merchant’s own transaction reference. Internal transaction IDs are useful for merchant operations but have no role in network-level CIT/MIT linkage.

For Mastercard transactions, the Transaction Link Identifier (TLID) introduced in 2024-2026 supplements the existing scheme transaction ID with a stronger, network-generated linkage value. From October 23, 2026, merchants must include the stored TLID in every economically-related MIT. The TLID does not replace the network transaction ID; both are required during the transition period.

How to flag a transaction correctly: the indicators

Correct MIT classification requires the merchant’s authorization request to include the right combination of indicators. The exact field names vary by PSP, but the underlying network requirements are the same:

For most modern PSPs and orchestration platforms, these indicators are handled at the integration layer rather than being passed explicitly by the merchant’s application. The merchant configures the transaction type once (subscription, installment, etc.) and the platform translates the configuration into the correct combination of network indicators for each authorization request.

For a deeper view of how the tokenization layer interacts with MIT classification, see Gr4vy’s guide on PSP tokens vs network tokens.

The multi-PSP problem: how MIT chains break when providers switch

For single-PSP merchants, MIT classification is operationally straightforward. The PSP captures the original CIT, returns the network transaction ID, stores it alongside the merchant’s customer reference, and submits it on every subsequent MIT.

For multi-PSP merchants, the chain becomes fragile. If an original CIT is processed through Acquirer A and a subsequent renewal is routed through Acquirer B, the network transaction ID and TLID need to be portable across the boundary. Three failure modes are common:

Failure 1: Acquirer-locked transaction ID storage. If the network transaction ID is stored inside Acquirer A’s records rather than at the merchant or orchestration layer, Acquirer B cannot reference it on the renewal. The MIT loses its CIT linkage and is treated as a fresh card-not-present transaction.

Failure 2: Inconsistent indicator application. Different PSPs implement MIT indicators slightly differently. The same logical transaction (a subscription renewal) might be flagged correctly through one PSP and incorrectly through another. The issuer sees inconsistent signals and decisions vary.

Failure 3: Lost chain during PSP migration. When a merchant migrates from one PSP to another, the stored credential relationships and their associated network transaction IDs need to migrate with them. Without explicit migration, the renewal volume on the new PSP starts as if every customer were a brand new acquisition with no consent history.

The solution to all three failure modes is to maintain the network transaction ID, TLID, COF indicator, and MIT classification at the orchestration or merchant layer rather than inside any single PSP’s records. The orchestration platform captures the metadata from whichever PSP processes the original CIT and propagates it to whichever PSP processes the subsequent MITs.

The MIT framework was designed by Visa and Mastercard with the assumption that the merchant would maintain the chain metadata, but most early implementations defaulted to letting the acquirer handle it. As multi-PSP setups have become standard for enterprise merchants, the architectural correction has become important.

Agentic commerce: a new category in the MIT framework

The rise of agentic commerce introduces a new question into the CIT/MIT framework. When an AI agent like ChatGPT or Gemini initiates a purchase on behalf of a customer, who initiated the transaction?

The card networks have not yet published comprehensive guidance on this question, but the operational consensus is forming around two principles:

Initial agent setup is a CIT. When the customer first authorizes an AI agent to make purchases on their behalf, providing consent and going through Strong Customer Authentication, that transaction is a CIT in the classical sense. The customer is present, providing credentials, and authorizing future activity.

Subsequent agent-initiated purchases are typically classified as MITs, with the agent’s instructions treated as part of the merchant-initiated chain. The specific MIT type depends on the use case: a scheduled agent purchase resembles a recurring MIT, while an on-demand agent purchase resembles an unscheduled COF.

The protocols emerging from Mastercard, Visa, OpenAI, Stripe, and others (including the Agentic Commerce Protocol and Universal Commerce Protocol) are formalizing this classification with new transaction indicators specific to agent-initiated flows. Merchants accepting agentic commerce should plan to support agent-specific MIT indicators alongside the existing eight use cases.

For a deeper view, see Gr4vy’s guide on making your checkout AI-agent-ready.

Common misclassification mistakes and how to avoid them

A handful of patterns consistently produce misclassified transactions and the avoidable declines they cause:

Treating a customer-initiated repeat purchase as an MIT. A returning customer logging in and clicking “buy again” is a CIT, even though the card was stored. The transaction is initiated by the customer at the moment it happens. Flagging it as an MIT can cause the issuer to apply different rules than it should, with unpredictable approval outcomes.

Treating a delayed merchant-initiated capture as an MIT. A customer who completes a CIT at checkout but whose charge is captured the next day is still a CIT. The latter capture happens against the original authorization, which was customer-initiated. The capture timing does not change the classification.

Missing the COF indicator on the original CIT. If the original CIT does not declare that credentials are being stored for future MITs, the chain cannot be established. Every subsequent MIT will lack the proper consent reference. This is one of the most common implementation mistakes.

Sending the wrong MIT type indicator. A recurring monthly subscription submitted with an installment indicator (or vice versa) creates inconsistency between what the issuer expects and what arrives. Decline rates rise even though the customer would have approved the transaction if it had been classified correctly.

Reusing one MIT indicator across all subsequent transactions regardless of purpose. Some merchants default all MITs to “recurring” because it covers the largest share of their volume. A no-show fee classified as recurring confuses the issuer’s risk model. Each MIT should carry the indicator that matches its specific purpose.

Losing the network transaction ID during PSP migration or routing changes. The chain breaks silently. Renewal authorization rates drop, but the cause is hidden in the indicator metadata rather than in any visible error. Audit migrations specifically to confirm the chain remains intact.

Skipping SCA on the initial CIT in regulated markets. Without SCA on the CIT, subsequent MITs do not qualify for SCA exemption. Every renewal becomes subject to authentication requirements that cannot be satisfied without the customer present. The result is a slow accumulation of declines on what should be a frictionless renewal flow.

Implementation checklist: making MIT classification work

Setting up correct MIT classification requires consistent handling across the entire payment stack. A practical checklist:

1. Identify every transaction in your stack as CIT or MIT. Map every flow that creates an authorization request and document which classification applies. Renewals, top-ups, no-show fees, delayed captures, and reauthorizations all need explicit classification.

2. For each MIT, identify the specific use case (recurring, installment, UCOF, resubmission, delayed charge, no-show, reauthorization, or incremental). The classification drives the indicator that must be sent.

3. Update CIT authorization requests to declare stored credential intent. Use the appropriate COF indicator (R, I, C, or other depending on the scheme) to tell the issuer the credential is being stored.

4. Capture and store the network transaction ID from every CIT response. This is the value that links subsequent MITs back to the original consent. Store it alongside the customer’s credential reference.

5. For Mastercard transactions, also capture and store the TLID in preparation for the October 23, 2026 mandate.

6. Include the network transaction ID (and TLID for Mastercard) in every subsequent MIT. The exact field names vary by PSP, but the values are required.

7. Ensure SCA is properly applied to CITs in regulated markets. Without authentication on the CIT, MIT exemptions do not apply.

8. Validate the chain across all your PSPs and acquirers. If you operate multi-PSP, verify that the network transaction ID, TLID, and indicators flow correctly across provider boundaries.

9. Monitor authorization rates and decline reasons by transaction type. A drop in MIT approval rates often points to misclassification or a broken chain rather than fundamental issues with the underlying credentials.

10. Document the classification rules in your operations runbook. New transaction types, edge cases, and integration changes should all be reviewed against the framework.

Frequently asked questions

What is the difference between a CIT and an MIT?

A customer-initiated transaction (CIT) is a payment where the cardholder is actively involved at the moment of the charge, providing card details or authenticating in real time. A merchant-initiated transaction (MIT) is a payment that the merchant triggers without the cardholder’s active involvement, based on a prior agreement established during an earlier CIT. The distinction determines authentication requirements, decline behavior, chargeback handling, and SCA exemption status.

Why does CIT vs MIT classification matter?

Card networks apply different rules to each category. CITs require Strong Customer Authentication in SCA-regulated regions; MITs are exempt when properly flagged. Issuers use the classification to inform their risk decisioning, which affects authorization rates. Misclassified transactions decline more often, can trigger unnecessary authentication requests, and may create chargeback liability that the merchant cannot defend.

What are the eight types of MITs?

The card networks recognize eight MIT use cases: recurring payments, installment payments, unscheduled credential-on-file (UCOF), resubmission, delayed charge, no-show, reauthorization, and incremental authorization. Each use case has a specific transaction indicator that must accompany the authorization request to properly classify the transaction.

Do MITs require Strong Customer Authentication?

No, MITs are exempt from SCA when properly flagged, provided the original CIT that established the stored-credential relationship underwent SCA authentication. This is one of the primary reasons subscription businesses in Europe rely on the MIT framework: it allows recurring transactions to proceed without re-authenticating the customer for every renewal.

Is a subscription renewal a CIT or an MIT?

A subscription renewal is an MIT when the merchant triggers the renewal automatically based on the subscription schedule. The original sign-up (where the customer entered card details and agreed to terms) was the CIT. Every subsequent automatic renewal is a recurring MIT that references back to that original CIT.

What is the difference between MIT and Credential-on-File (COF)?

Credential-on-File refers to the stored card data, which is a prerequisite for MITs but is not itself a transaction classification. A stored credential can be used for both subsequent CITs (when the customer returns and clicks “use my saved card”) and MITs (when the merchant triggers a transaction against the stored credential). The COF indicator at the original CIT declares what types of future transactions the stored credential authorizes.

How does the Mastercard TLID relate to MIT classification?

The Mastercard Transaction Link Identifier (TLID) is a scheme-generated identifier that links the original CIT to all subsequent MITs at the network level. It supplements the existing network transaction ID with a stronger, more consistent linkage value. From October 23, 2026, merchants must include the stored TLID on every economically-related MIT authorization request.

Can I use the same network transaction ID across multiple MITs?

For Visa, you can use the network transaction ID from any prior MIT in the chain when submitting a new MIT. For other schemes, you typically need to reference the ID from the original CIT or the relationship-establishment transaction. Most modern PSPs and orchestration platforms handle this automatically based on the configured transaction type.

What happens if I misclassify a transaction?

Misclassified transactions can decline at higher rates because the issuer’s risk model receives inconsistent signals. In SCA-regulated regions, a misclassified MIT can lose its authentication exemption and be subject to challenge requests that cannot be satisfied without the customer present. Chargeback liability can also shift because MIT-specific dispute codes do not apply to misclassified transactions.

Do CIT and MIT rules apply to all card networks?

Yes, all major card networks (Visa, Mastercard, American Express, Discover) recognize the CIT-MIT distinction, though the specific indicators, use case definitions, and technical requirements vary slightly by scheme. Visa formalized the modern framework in 2017; Mastercard updated theirs in late 2021. American Express and Discover apply similar logic through their closed-loop systems.

How does CIT vs MIT work for agentic commerce?

When an AI agent like ChatGPT initiates a purchase on behalf of a customer, the initial setup (where the customer authorizes the agent and authenticates) is treated as a CIT. Subsequent agent-initiated purchases are typically classified as MITs, with the specific MIT type depending on the use case. The agentic commerce protocols emerging from Mastercard, Visa, and major AI platforms are formalizing this classification with new indicators specific to agent-initiated flows.

How do I store the data needed for MIT classification?

Store the original CIT’s network transaction ID (and Mastercard TLID where applicable), the COF indicator declaring what types of future transactions are authorized, the credential reference (typically a network token), and the customer’s consent record. This metadata should live at the merchant or orchestration layer rather than inside any single PSP’s records, particularly for multi-PSP setups where MITs may be routed through a different acquirer than the original CIT.

What is the network transaction ID?

The network transaction ID (sometimes called Visa Transaction ID, Mastercard scheme transaction ID, or NTID) is a value generated by the card network at the time of authorization and included in the response. It serves as the reference that links subsequent MITs back to the original CIT. The merchant does not create it; the merchant receives it and stores it for use on future transactions.

What to do next

Correct MIT classification is the foundation of every successful card-on-file and subscription business. Get it right, and authorization rates on renewals stay high, SCA exemptions apply cleanly, and chargeback defenses hold up. Get it wrong, and the symptoms appear gradually: declining renewal approval rates, mysterious authentication challenges on transactions that should be exempt, and chargeback losses on transactions that should have been defensible.

For most merchants, the work falls into two categories. The classification logic and indicator application can usually be handled at the PSP or orchestration layer, which is where it belongs architecturally. The harder problem is making sure the chain metadata (network transaction IDs, TLIDs, COF indicators, consent records) is stored at the merchant or orchestration layer rather than inside any single PSP’s records, so that it remains portable across PSP boundaries.

Gr4vy’s cloud-native payment orchestration platform handles MIT classification, network transaction ID propagation, and TLID management automatically across more than 400 connected PSPs and payment methods. The chain stays intact across routing decisions, PSP migrations, and multi-acquirer setups, with no merchant-side application code required to maintain it.

If you’re evaluating your current MIT classification setup or want to understand how chain metadata could be unified across your existing PSP relationships, contact our team for a stack review and integration plan tailored to your current architecture.

Mastercard is changing how transactions are tracked across the payment lifecycle. The Transaction Link Identifier (TLID) is a new, scheme-generated reference that links every authorization, capture, refund, chargeback, and subsequent merchant-initiated transaction back to its originating cardholder-initiated payment. From October 23, 2026, merchants must include the stored TLID in every economically-related transaction (recurring billing, subscription renewals, installments, unscheduled credential-on-file charges). Non-compliance fees begin in January 2027.

The change is operationally simple to implement, but it carries real consequences for subscription businesses, marketplaces, and any merchant running multi-PSP setups where stored credentials need to remain portable. This guide explains what TLID is, the exact technical specification, the dates that matter, how it differs from the Trace ID it replaces, and what enterprise merchants need to do now to stay ahead of the deadline.

What is the Mastercard Transaction Link Identifier?

The Mastercard Transaction Link Identifier is a unique, scheme-generated 22-character alphanumeric identifier that Mastercard assigns to every card authorization and includes in the authorization response. The identifier persists across every related message in the transaction lifecycle (captures, refunds, voids, chargebacks) and across every economically-related transaction (subscription renewals, installments, unscheduled MITs) under the same stored-credential agreement.

In simpler terms: when a cardholder makes their first payment with a merchant and authorizes that merchant to store the card, Mastercard generates a TLID. That same TLID is then carried forward into every subsequent transaction linked to that stored credential. The merchant stores it once, and reuses it on every related charge.

A few important characteristics:

• Scheme-generated by Mastercard. The TLID comes from Mastercard directly, included in the authorization response. Merchants do not create it; they receive it and store it.
• 22 characters, alphanumeric, case-sensitive, may include hyphens and underscores. (Some industry articles have reported a 36-character length, which appears to be confusion with the canonical UUID format. The Mastercard specification, as reflected in Stripe, Adyen, and Worldpay documentation, is 22 characters.)
• Globally unique. TLIDs are unique across all of Mastercard’s infrastructure, eliminating the duplication risk that affected the older Trace ID.
• Consistent across all Mastercard acceptance brands, including Maestro.
• Not PCI-sensitive. TLIDs can be stored in standard databases alongside customer payment profiles, without requiring a PCI-compliant vault.

Why Mastercard is introducing TLID

Until now, Mastercard transactions have been tracked across the lifecycle using the Trace ID (also known as the scheme transaction ID or previous_payment_id), which is generated by the acquirer rather than by Mastercard itself. The Trace ID has worked, but it carries a structural weakness: because each acquirer generates its own values, duplicates can occur across different acquiring relationships, and the same transaction can carry different Trace IDs in different parts of the chain.

The TLID solves this at the network level. Because Mastercard itself generates the identifier and propagates it across every message in the lifecycle, there is no risk of duplication, no acquirer-to-acquirer translation problem, and no ambiguity about whether two transactions are related.

The benefits Mastercard cites for the change:

• Consistent transaction identification across all Mastercard platforms and acceptance brands
• Matching and linking of all messages across the full transaction lifecycle
• Improved fraud detection by making it harder to obscure related transactions
• Reduction in authorization-related chargebacks through clearer traceability
• Better support for merchant-initiated transactions, including subscriptions and installments
• Operational efficiency gains for issuers, acquirers, and merchants doing investigative work

For merchants, the practical benefits show up in three areas: faster dispute resolution (TLID makes it trivial to link a chargebacked MIT to the original CIT where the cardholder consented), cleaner reconciliation (every transaction in a lifecycle shares the same TLID), and better authorization rates on MITs (issuers see the chain of consent more clearly).

The four key dates merchants need to track

The Mastercard rollout happens in four phases. Missing any of them creates either compliance risk or operational disruption.

The window that matters most for most merchants is between June 2 and October 23, 2026: that is when the TLID actually starts arriving on new transactions, and when merchants need to have their storage and integration ready. Merchants who wait until October 2026 to start the work face real risk of missing the deadline, because integration testing, schema changes, and conformance work do not happen overnight.

How TLID works: lifecycle vs economically-related transactions

The TLID applies to two distinct categories of transactions, and the rules differ slightly for each.

Lifecycle transactions

A lifecycle transaction is any message that is part of the same authorization event: the capture that follows the original authorization, the partial or full refund issued against it, a void or reversal, and any chargeback messages.

For lifecycle transactions, the TLID generated at the original authorization is automatically propagated across all related messages by the acquirer or PSP. The merchant typically does not need to do additional work, because the integration handles it transparently. The October 17, 2025 mandate covers this category.

Economically-related transactions

An economically-related transaction is a separate authorization that is logically tied to an earlier one through a stored-credential agreement. The classic example is a subscription: the customer’s first payment is a CIT where they authorize the merchant to charge the card on a recurring schedule. Every subsequent renewal is a separate MIT authorization, but it is economically related to that initial CIT.

For these transactions, the merchant has to do the work of storing the TLID from the original CIT and submitting it with every subsequent MIT. This is the integration burden the October 23, 2026 mandate creates.

The same pattern applies to:

• Installment payments following an initial purchase
• Buy Now, Pay Later (BNPL) schedule charges following the authorization
• Unscheduled credential-on-file payments (top-ups, on-demand purchases against a stored card)
• Free-to-paid conversions where a free trial becomes a paid subscription
• Variable recurring payments where the amount or timing differs each cycle

In every case, the TLID retained from the original CIT travels with every subsequent MIT, creating a verifiable chain at the network level.

The four main use cases for TLID

The strategic value of TLID becomes visible in four specific use cases that affect day-to-day merchant operations.

1. Faster, cleaner dispute resolution

When a cardholder raises a dispute on a subscription renewal claiming they did not authorize the recurring charge, the merchant traditionally has to assemble evidence linking that MIT to the original CIT where consent was given. This typically involves PAN matching, timestamp correlation, system trace IDs, and sometimes manual investigation across multiple systems.

With TLID, the chain is verifiable at the network level. The TLID on the disputed MIT traces directly back to the TLID on the original CIT, providing scheme-generated proof of the stored-credential relationship. Disputes that previously required hours of investigation can be resolved in minutes, and the success rate on representment typically improves because the evidence is cleaner and more defensible.

2. Cleaner reconciliation and transaction tracking

Every lifecycle event for a transaction shares the same TLID. The original authorization, the capture, any partial refunds, and any chargebacks all carry the same identifier. This makes reconciliation between authorization and clearing records significantly faster, and makes it trivial to assemble a complete transaction timeline for any specific charge.

For finance teams doing month-end close, the time savings are meaningful. For customer support teams investigating duplicate-charge complaints or refund timing questions, the lookup becomes a single-query operation rather than a multi-system investigation.

3. Linking authentication to subsequent payments

When the original CIT was submitted with Strong Customer Authentication (SCA) data, which is common for European transactions under PSD2 and similar regulations in Japan and other jurisdictions, that authentication context can carry forward to subsequent MITs through the TLID. Issuers see the chain of consent and authentication, which typically improves authorization rates on the renewals.

This matters most for subscription businesses operating in SCA-regulated markets, where MIT authorization rates can be 5-10 percentage points higher when the chain to the authenticated CIT is visible.

4. Multi-PSP credential portability

For merchants using multiple PSPs, the TLID enables a critical capability: an MIT can be processed through one PSP while referencing a CIT that was processed through a different PSP. Because the TLID is scheme-generated rather than acquirer-generated, it remains valid across acquirer boundaries.

This is the angle most coverage of TLID misses, and it matters specifically for enterprise merchants running orchestration-based architectures. Routing a subscription renewal through whichever acquirer is currently performing best, even if the original authorization went through a different one, requires the underlying chain-of-consent reference to be portable. The Trace ID was not. The TLID is.

For a deeper view of how multi-PSP routing benefits subscription and card-on-file businesses, see Gr4vy’s guide on intelligent payment routing.

What merchants need to do: the implementation checklist

The good news is that TLID implementation is operationally simple. Most merchants can complete the work in a week or two of engineering effort. The checklist:

1. Confirm your acquirer is passing TLID. All major acquirers (Stripe, Adyen, Worldpay, Checkout.com, Braintree, and others) have published their TLID handling specifications. Verify with your account manager that TLIDs are appearing in authorization responses for your Mastercard transactions.

2. Update your database schema. Add a field to your customer payment profile records that can store a 22-character alphanumeric string. The field can be a standard VARCHAR column; no encryption or PCI-compliant storage is required.

3. Capture TLID on every CIT authorization response. When you process the initial Customer-Initiated Transaction (typically the first payment with a new stored credential), parse the TLID from the authorization response and store it alongside the customer’s token or card reference.

4. Submit TLID with every economically-related MIT. When processing subscription renewals, installments, BNPL charges, or any other MIT against a stored credential, include the previously-stored TLID in the authorization request.

5. Plan for older stored credentials. Cards stored before your integration captured TLIDs will not have one. For these, the standard approach is to submit a new MIT, receive the TLID back from Mastercard via your acquirer in the authorization response, store it, and use it for all future transactions. Mastercard recommends using an undisputed MIT from at least three months prior as the basis for the new TLID lineage.

6. Continue passing Trace ID in parallel. Mastercard has not yet sunset the Trace ID, and merchants should plan to store and pass both Trace ID and TLID for the foreseeable future. The Trace ID sunset is expected eventually but no date has been announced.

7. Test conformance with your acquirer. Most major acquirers offer test environments where merchants can validate their TLID handling before going live. Run end-to-end tests covering CIT capture, MIT submission with TLID, and dispute flows before the October 2026 deadline.

Acquirers that include orchestration platforms typically handle most of this transparently. For merchants using Gr4vy, the TLID capture, storage, and propagation across all connected PSPs and acquirers is handled automatically through the platform.

The multi-PSP angle: why orchestration matters here

For single-PSP merchants, TLID implementation is straightforward: the PSP returns the TLID, the merchant stores it, the merchant passes it back on MITs. The flow lives inside one provider relationship.

For multi-PSP merchants, the picture is more complex. A TLID generated through Acquirer A on the original CIT needs to be available to Acquirer B if a subsequent MIT is routed through it. The TLID itself is scheme-generated and globally valid, but the merchant’s integration has to make it available across all the PSP connections that might handle related transactions.

Three implementation patterns exist for this:

Pattern 1: Single-PSP-per-customer. The merchant routes every transaction for a given customer through the same PSP. The TLID lives inside that PSP’s records and is reused on MITs. This works but defeats the purpose of multi-PSP routing, because the merchant cannot dynamically route a renewal through whichever PSP is currently performing best.

Pattern 2: Merchant-managed TLID storage. The merchant stores the TLID in their own database, separate from any single PSP. When routing an MIT through any PSP, the merchant includes the stored TLID in the request. This works but requires the merchant to build the storage and propagation logic themselves, and to ensure every PSP integration handles the field correctly.

Pattern 3: Orchestration-managed TLID. The orchestration platform captures the TLID from whichever PSP processes the original CIT, stores it in a provider-agnostic vault, and automatically includes it in subsequent MITs regardless of which PSP routes them. The merchant’s application code does not need to handle TLID directly; the orchestration platform manages the full lifecycle.

The third pattern is the cleanest architectural fit for multi-PSP merchants and is the model Gr4vy’s platform implements. The TLID is captured at the orchestration layer when the original CIT is processed, stored alongside the merchant token, and automatically propagated to subsequent MITs across any connected PSP. The merchant does not need to manage TLID storage in their own database or update their application code to handle the field.

This becomes especially important for merchants planning migrations between PSPs or adding additional providers, because the TLID needs to remain valid across the migration. Acquirer-managed TLIDs that live inside a single PSP’s records create the same portability problem as PSP-locked tokens. Orchestration-managed TLIDs do not.

How TLID relates to network tokens

A common question is how TLID relates to network tokenization (Visa Token Service, Mastercard Digital Enablement Service). The short answer: they are complementary technologies that solve different problems.

Network tokens replace the stored PAN with a network-issued credential. They handle credential security and lifecycle (automatic updates when cards are reissued). They do not, by themselves, provide a way to link related transactions across the payment lifecycle.

TLIDs provide the lifecycle linkage. They identify which transactions are related to which, and which MITs flow from which CITs. They do not change how credentials are stored.

For a card-on-file or subscription transaction processed through Mastercard, the modern best-practice stack uses both: a network token to represent the credential, and a TLID to identify the relationship between transactions. For more on tokenization patterns, see Gr4vy’s guide on network tokenization vs PSP tokenization.

Common implementation mistakes to avoid

A handful of patterns separate smooth TLID rollouts from troubled ones:

Underestimating the schema work. While the TLID itself is just a 22-character string, the work of updating customer payment profile records, propagating the field through application code, and updating analytics and reporting systems can extend across multiple teams. The integration is technically simple but organizationally non-trivial.

Treating TLID as PCI-sensitive. Some teams default to storing any payment-related field in their PCI vault. TLIDs are not PCI-sensitive and storing them in the vault adds operational overhead without any compliance benefit. Standard database storage alongside customer profiles is the correct approach.

Skipping the back-migration plan for legacy credentials. Cards stored before TLID capture went live will not have one, and merchants need a plan for generating TLIDs for these credentials. The standard approach (issue a new MIT, capture the returned TLID, use it going forward) works but should be scheduled before the October 2026 deadline rather than reactively after.

Locking TLID storage to a single PSP. Storing the TLID inside one PSP’s records rather than at the orchestration or merchant layer creates exactly the portability problem TLID was designed to solve. Multi-PSP merchants should store TLIDs in their own database or in an orchestration platform that propagates them across all connected PSPs.

Confusing the 22-character spec with 36-character UUID. Several published articles on TLID report a 36-character length, likely confusing the TLID with standard UUID formatting. The Mastercard specification is 22 characters. Building database schemas around the wrong length creates avoidable rework.

Waiting until October 2026 to start. The integration is straightforward but it is not zero-effort. Schema changes, application updates, conformance testing with acquirers, and back-migration of legacy credentials all take time. Most merchants who start in the second half of 2026 will be cutting it close to the October 23 deadline.

Frequently asked questions

What is the Mastercard Transaction Link Identifier (TLID)?

The TLID is a 22-character alphanumeric identifier that Mastercard automatically generates for every card authorization. It links the original cardholder-initiated transaction (CIT) to all related lifecycle messages (captures, refunds, chargebacks) and all economically-related merchant-initiated transactions (subscription renewals, installments, unscheduled MITs) under the same stored-credential agreement.

When does the TLID mandate take effect?

The rollout happens in four phases: October 17, 2025 covered lifecycle transactions and is already in effect. June 2, 2026 begins TLID generation for economically-related transactions and requires acquirers to ensure merchants retain TLIDs from CITs. October 23, 2026 requires merchants to actively include the stored TLID in every MIT authorization request. January 31, 2027 begins formal compliance assessments and non-compliance fees.

How is TLID different from the Trace ID?

The Trace ID (also called scheme transaction ID) is generated by the acquirer and can be duplicated across acquirer boundaries. The TLID is generated by Mastercard at the network level and is globally unique. TLID is intended to eventually replace Trace ID, but Mastercard has not yet announced a sunset date for the Trace ID, and merchants should plan to store and pass both for the foreseeable future.

Is TLID a UUID?

The TLID functions like a unique identifier but uses a 22-character alphanumeric format (including hyphens and underscores) rather than the canonical 36-character hyphenated UUID format. Several published articles have reported a 36-character length, which appears to be a confusion with standard UUID formatting. The official specification, as reflected in major PSP documentation, is 22 characters.

Where do I store the TLID?

The TLID is not PCI-sensitive and can be stored alongside customer payment profiles in standard database tables. Most implementations add a VARCHAR(22) field to the table that holds customer card references. No encryption or vault-grade storage is required.

What happens if I do not include the TLID on MITs after October 2026?

In the near term, Mastercard is not declining transactions for missing TLID. However, Mastercard has signaled it may flag data integrity issues, and non-compliance fees begin in January 2027. Issuers may eventually decline MITs that do not carry the expected TLID. The safest interpretation of the mandate is that TLID submission becomes operationally required, with both compliance fees and downstream authorization rate risks for merchants who skip it.

Does TLID apply to non-Mastercard transactions?

No. TLID is a Mastercard-specific identifier and applies to all Mastercard acceptance brands including Maestro. Visa, American Express, and Discover have not announced similar identifiers as of mid-2026. Each network maintains its own transaction reference scheme.

Will I need to manage TLID separately for each PSP?

If you operate with a single PSP, that PSP typically handles TLID storage and propagation transparently. If you operate with multiple PSPs, you have two practical options: store TLIDs in your own database and pass them through each PSP integration, or use an orchestration platform that captures and propagates TLIDs across all connected PSPs automatically.

What happens to TLIDs for cards stored before the mandate?

For credentials stored before your integration started capturing TLIDs, the standard approach is to submit a new merchant-initiated transaction against the stored credential, receive the TLID back from Mastercard via your acquirer, store it, and use it on all subsequent transactions. Mastercard recommends using an undisputed MIT from at least three months prior as the basis for the new TLID lineage.

Does TLID replace network tokens?

No. TLID and network tokens serve different purposes. Network tokens (from Visa Token Service, Mastercard Digital Enablement Service, and equivalents) replace the stored PAN with a network-issued credential that handles security and automatic lifecycle updates. TLID is a separate identifier that links related transactions across the lifecycle. The modern stack uses both: network tokens for credential representation and TLIDs for transaction linkage.

Can I use TLID for refunds and chargebacks?

Yes. The TLID generated at the original authorization is included in all lifecycle messages, including captures, refunds, voids, and chargebacks. Merchants do not need to take additional action for these, because the TLID propagation happens automatically in the lifecycle phase that became active in October 2025. For refund authorizations specifically, Mastercard requires the TLID to be provided in the authorization response in clearing.

How long does TLID implementation take?

For most merchants, the engineering work takes a week or less. The bigger time investments are in cross-team coordination (database schema changes, application updates, analytics updates), conformance testing with acquirers, and the back-migration plan for legacy stored credentials. Most enterprise merchants should plan for 4-8 weeks of total project time from kickoff to production-ready.

How does Gr4vy handle TLID?

Gr4vy captures the TLID from the original CIT authorization response automatically, stores it in the provider-agnostic vault alongside the merchant token, and propagates it to subsequent MITs across any connected PSP. Merchants using Gr4vy do not need to update their application code, database schemas, or PSP integrations individually to handle TLID, because the orchestration platform manages the full lifecycle. This is especially valuable for multi-PSP merchants whose MITs may be routed through a different acquirer than the original CIT.

What to do next

The TLID mandate is one of the cleaner scheme changes in recent memory: low integration complexity, real operational benefits, and a meaningful improvement in how subscription and card-on-file transactions are tracked across the network. The work is straightforward, but the timeline matters. Merchants starting in mid-2026 will be comfortable; merchants starting in October 2026 will be at risk of missing the deadline.

For merchants with single-PSP setups, the practical first step is confirming with your account manager that TLID handling is configured in your acquirer’s integration and updating your customer profile schema to store the field. For merchants with multi-PSP setups, the question is whether to build TLID propagation across each PSP integration individually or to let an orchestration platform handle it centrally.

Gr4vy’s cloud-native payment orchestration platform manages TLID capture, storage, and propagation automatically across more than 400 PSPs and payment methods. The TLID flows from the original CIT through every subsequent MIT regardless of which acquirer processes the renewal, preserving the chain of consent that Mastercard’s mandate is designed to enforce.

If you’re evaluating how to handle the TLID mandate across your existing PSP relationships or want a walkthrough of how Gr4vy implements TLID propagation in a multi-PSP setup, contact our team for a stack review and integration plan tailored to your current architecture.

Last updated May 21st 2026

Around half of online merchants now use more than one payment provider. That shift, more than any other in the last five years, is what created the category called payment orchestration and the technology layer at the center of it. The term is still used loosely. People confuse payment orchestration with a gateway, ask whether it replaces a PSP, and want to know what actually changes inside a business the day a payment orchestrator goes live. Below, the answers in the order a payments leader asks them.

TL;DR

• Payment orchestration is a technology layer that connects multiple PSPs, acquirers, and payment methods through a single integration, routing every transaction to the provider best suited to handle it.
• It typically lifts authorization rates by 2 to 3 percentage points, reduces processing costs, and removes months of engineering work when adding new payment methods or markets.
• The case for payment orchestration sharpens once a business is processing roughly $1M per month, selling into two or more countries, or using two or more PSPs.
• Gr4vy is the only payment orchestration platform built on dedicated single-tenant cloud instances with edge localization capabilities. Unlike shared SaaS environments, every merchant operates on its own isolated infrastructure, deployed in-region to support performance, resiliency, and regulatory requirements. This Infrastructure-as-a-Service model enables data localization for markets where payment data cannot leave the country, helping enterprises meet strict sovereignty and compliance mandates without sacrificing flexibility or scale.

What is payment orchestration?

A payment orchestrator is the software layer that sits between your checkout and every payment provider you use, process each transaction, decides which provider should handle it, sends it on, and brings the result back. The customer sees a single checkout. Your team sees one dashboard. The complexity of multiple PSPs, acquirers, payment methods, and fraud tools is absorbed inside the orchestration layer.

A payment orchestrator does not authorize payments, move money, or own a merchant account. Its role is to coordinate the providers that do, deciding which one is best suited to each individual payment based on rules you set and conditions it sees in real time.

That distinction matters commercially. A PSP earns more when more transactions flow through its own pipes. Payment orchestration earns nothing from routing one provider over another, which is why a well-designed orchestrator can route transactions away from underperforming providers without any conflict of interest. The neutrality is the product.

The five jobs of a payment orchestration platform

Payment orchestration handles five jobs across every transaction.

It processes  the transaction request from your checkout and applies any pre-routing logic you have configured (3D Secure, fraud screening, business rules).

It routes the transaction to the optimal provider based on cost, expected approval rate, geography, card BIN, provider uptime, or any combination of criteria your team specifies.

It handles failover when a provider returns a soft decline or times out, attempting the transaction through a backup provider before the customer sees a failure.

It stores payment credentials in a provider-agnostic Vault, so tokens work across every connected PSP and customers do not have to re-enter details when you switch or add providers.

It consolidates reporting across every provider into a single dashboard: settlements, fees, decline reasons, chargebacks, refunds, all attributable to provider, market, payment method, or card type.

Each capability is useful on its own. They become substantially more useful as a coherent system, which is the point of choosing a serious platform rather than assembling the equivalent yourself.

How does payment orchestration work?

Walk through what happens between a customer clicking “pay” and a settlement appearing in your finance dashboard.

The customer reaches checkout and selects a payment method. The payment orchestration layer receives that selection along with contextual information: country, currency, basket value, card BIN if relevant. Before deciding anything else, the merchant decides which payment methods to show the customer in the first place, because the right methods depend on the customer’s market. A shopper in São Paulo expects Pix. A shopper in Amsterdam expects iDEAL. Showing the wrong set of methods is itself a leading cause of checkout abandonment.

Once the method is selected, the payment orchestration platform applies your pre-routing logic. This usually includes 3D Secure rules, fraud screening, and any business-level constraints. The platform then evaluates which provider should handle the transaction as per the merchant setup, sends it there, and waits for the response.

If the transaction succeeds, authorization and settlement proceed through the chosen provider in the normal way. If it fails, payment orchestration can attempt the transaction through an alternative provider before returning a decline. This failover mechanism is the single capability most directly responsible for recovered revenue.

All transaction data, regardless of which provider ultimately handled the payment, flows back to the orchestration dashboard. Your finance team sees a single source of truth.

Payment orchestrator vs payment gateway vs PSP

The three layers are often confused. The cleanest mental model is this: a gateway moves data, a PSP moves money, an orchestrator moves decisions.

A payment gateway captures payment information from the checkout, encrypts it, and transmits it to a processor or acquirer for authorization. It does not decide which provider to use. It follows a predetermined path.

A payment service provider (PSP) is a bundled solution combining gateway functionality, a merchant account, payment processing, and often fraud protection and reporting. You get an integrated stack from a single vendor, and you cannot optimize across providers because you only have one.

A payment orchestrator sits above gateways and PSPs and coordinates between them. It connects to multiple providers through a single API and routes each transaction to the optimal destination based on the rules you set. For a deeper breakdown, see payment orchestration vs payment gateway vs payment processor.

The three conditions that break a single-PSP setup

A single-PSP setup is the right answer for many businesses. It only stops working when one of three things happens.

Geographic expansion. A PSP that performs well in one market may have weaker acquiring relationships, slower decline recovery, or no native support for local payment methods elsewhere. Merchants entering Brazil, India, or the Nordics quickly find that the provider that served them well at home is not the right answer in those markets.

Scale. As volume grows, the gap between a good authorization rate and a great one converts into seven-figure numbers. A merchant processing $200 million a year cannot afford to ignore a two-point approval-rate gap between providers, even if both are technically functional.

Operational drag from multiple providers. Many merchants reach a multi-PSP setup organically, adding a second provider for redundancy or a third for a new market. Each integration was a reasonable choice in isolation. Taken together, they create fragmentation: different APIs, different reconciliation timelines, different reporting formats, different ways of representing a chargeback. Finance teams stitch together exports at month-end. Engineering teams maintain integrations whose original authors have left the company.

This is the situation payment orchestration resolves. Everything runs on the same rules and shows up in the same dashboard.

Payment orchestration: new sources of revenue

The business case for payment orchestration is more than productivity. 

Higher authorization rates. Routing each transaction to the provider most likely to approve it lifts authorization rates by two to three percentage points in most deployments, with more fragmented multi-PSP estates seeing larger gains. Within four months of moving to a dual-acquirer setup, Australian retailer Baby Bunting measured a 2.8% authorization uplift that contributed to record online sales above $120 million. On $100 million of annual volume, a single percentage point of recovered approvals is roughly $1M of revenue, recovered without any change in customer acquisition spend. On $500 million it is $5M. At enterprise scale, two or three points of authorization uplift is a strategic line item.

Lower processing costs. Smart routing sends each transaction to the lowest-cost provider that can authorize it, which compounds across millions of transactions. Local acquirers in each market reduce cross-border fees and FX leakage. Mattilda, a Latin American education payments platform, posted a 60% reduction in payment costs after consolidating collections across multiple acquirers this way. For platform businesses, the cost reduction story is often as significant as the revenue uplift.

Faster speed to market. Adding a new payment method or a new market used to mean months of engineering. With a coordinating layer above the providers, both become configuration changes in a dashboard. A platform with hundreds of pre-built provider connections can enable a new local payment method in days.

Reduced engineering overhead. Engineering capacity that used to maintain three or four PSP integrations gets returned to product work. This is consistently the orchestration benefit engineering leaders rate highest when asked retrospectively, partly because it shows up as work that no longer happens.

Recovered revenue from failed payments. Failover, dynamic retries, Network Tokens, and Account Updater each recover transactions that single-PSP setups would lose. Industry research puts the recoverable share of failed-payment revenue as high as 14%, depending on the merchant’s profile.

Unified reporting. Two thirds of multi-PSP merchants lack a unified view across providers. Roughly 30% of payment failures go unresolved because of the resulting visibility gap. Reconciliation, fee analysis, and provider benchmarking all become possible the moment data from every provider runs through one platform.

When do you need payment orchestration?

The answer comes from the setup, not from the size. A subscription business doing modest monthly volume across five countries faces the same fragmentation, the same provider-specific approval-rate variance, and the same reconciliation overhead as a much larger single-market merchant. The smaller business often needs orchestration sooner, because the complexity is already there.

The case sharpens whenever any of three conditions appears: a second market, a second PSP, or a meaningful approval-rate gap between regions. Larger volume amplifies the return on every percentage point of recovered approvals, but it does not gate access to the underlying benefits. Smaller merchants with the right setup capture them too.

Beyond volume, the conditions that consistently signal a payment orchestration-shaped problem are these. Multiple providers already in the stack, particularly across regions. Cross-border operations where approval rates vary noticeably by market. Subscription or recurring billing exposing the business to involuntary churn. Concerns about vendor lock-in, particularly where switching PSPs is a multi-quarter migration.

There are conditions where payment orchestration is not the right move yet. A single PSP, single market, single payment method, and modest volume. No one to own payments operations. A platform replatforming that needs to finish first.

The threshold is not a fixed number. The right question is whether multiple providers, multiple markets, or multiple payment methods are already creating operational drag, or will within twelve months.

What payment orchestration does not solve

The vendor pitch for payment orchestration tends to be uniformly positive. The reality is more mixed, and most failed implementations come from underestimating four things.

It does not negotiate your PSP contracts for you. Routing transactions across multiple providers gives you leverage, but the leverage only converts into better rates if someone uses it. Merchants who add an orchestration layer without then renegotiating PSP terms typically leave the largest portion of available savings on the table. The orchestrator hands you the data and the optionality. Acting on both is still a job.

It does not eliminate the need for someone to own payments. A payment orchestration platform replaces engineering work with configuration work, which is much faster but not zero. Routing rules need to be defined, tested, and revisited. Provider performance needs to be reviewed. New payment methods need to be activated and monitored. Businesses that bought into orchestration expecting it to run itself usually end up with a powerful platform that nobody is steering.

It does not fix a checkout that has other problems. If the checkout itself has friction unrelated to payment routing, broken mobile flows, missing local payment methods that exist in the orchestrator but were never enabled, or a confusing form layout, the orchestration layer will not solve those problems. A 30% checkout abandonment rate driven by UX issues will not move because the underlying transactions started routing more intelligently.

It does not remove all risk of a payments incident. A well-architected orchestrator reduces single-points-of-failure dramatically, but it introduces one new dependency. If the orchestration platform itself goes down, every connected provider becomes inaccessible at once. The mitigation is at the architecture level, and it is one of the reasons the multi-tenant versus dedicated instance question matters. A platform built on dedicated cloud instances per customer has a much smaller blast radius than a multi-tenant platform where one incident affects every customer simultaneously.

The trade-offs are real, but they are also manageable. Merchants who implement payment orchestration with clear-eyed expectations about what it does and does not do consistently capture more of the available upside than merchants who treat it as a one-time fix.

Multi-tenant vs dedicated instance: the architecture trade-off most buyers miss

Two payment orchestration platforms can offer the same features and run on very different infrastructure. The distinction matters in 2026, particularly for merchants in regulated industries or markets with strict data residency requirements.

Multi-tenant payment orchestration runs on shared infrastructure across the platform’s customers. One set of servers, databases, and APIs serves all merchants. The benefits are speed and cost. The trade-off appears under specific conditions: traffic spikes from one merchant can affect performance for others, data sovereignty cannot be fully guaranteed, and the platform’s blast radius covers every customer at once.

Dedicated instance payment orchestration runs each customer on its own isolated cloud environment. Gr4vy is the only  payment orchestration platform built this way. Each merchant’s orchestration layer, Vault, dashboard, and routing logic runs on infrastructure that nobody else shares. Data residency can be guaranteed by region. Performance does not depend on other tenants. The blast radius shrinks dramatically.

For enterprises in financial services, healthcare, regulated sectors, or any business where data sovereignty is a board-level concern, dedicated instance is often the requirement that disqualifies multi-tenant platforms outright.

How much does payment orchestration cost?

Pricing varies by platform and is typically based on processed volume, with custom enterprise pricing above certain thresholds. Most payment orchestration platforms add a per-transaction or platform fee on top of existing PSP fees.

At Gr4vy, pricing is tied to infrastructure rather than transaction volume alone, reflecting our Infrastructure-as-a-Service and single-tenant architecture. Every merchant operates on its own dedicated orchestration instance, with isolated infrastructure designed for greater control, resiliency, security, and regulatory flexibility. This model aligns our platform with the operational realities of enterprise payments, where infrastructure ownership, performance, and compliance are critical business requirements rather than shared SaaS resources.

At scale, the fee is offset by authorization-rate uplift, processing cost reductions, and reduced engineering overhead. The total cost of ownership of payment orchestration tends to fall, not rise, once it is in place. The Gr4vy ROI calculator gives a per-business estimate based on processed volume, current approval rates, and provider mix.

Is payment orchestration PCI compliant?

Yes, when the platform is properly certified. Look for PCI DSS Level 1, SOC 2 Type II, and ISO 27001. One of the secondary benefits of payment orchestration is that the merchant’s own PCI scope is reduced, because sensitive card data lives inside the platform’s tokenization Vault rather than across multiple systems.

Where payment orchestration is heading next

Payment orchestration began as a way to coordinate multiple integrations through a single API. The capabilities have grown well beyond that. Machine learning now optimizes routing decisions based on issuer response patterns the platform can detect across millions of transactions. Network Tokenization has moved from a card-network capability to a feature most payment orchestration platforms expose natively.

The most significant shift in the next two years is agentic commerce. AI agents are starting to initiate and complete purchases on behalf of consumers, often inside conversational interfaces like ChatGPT. The payments infrastructure required for agent-driven transactions differs from the infrastructure required for human checkouts. Gr4vy is the first payment orchestration platform to launch a dedicated Agentic Development Kit for this purpose, enabling its merchants to process agentic commerce payments.

Frequently asked questions

Is a payment orchestrator the same as a payment gateway?

No. A gateway transmits transaction data between the checkout and a processor. A payment orchestrator sits above gateways, PSPs, and acquirers, coordinating across all of them and providing a unified view of payment performance.

Is a payment orchestrator the same as a PSP?

No. A PSP processes payments and owns the merchant account. A payment orchestrator does not process payments. It decides which PSP should handle each transaction and can use multiple PSPs in parallel.

Do I need to replace my existing PSPs to use payment orchestration?

No. Payment orchestration sits on top of existing providers. PSP relationships, contracts, and merchant accounts stay in place. The platform coordinates how transactions flow across them.

How many providers do I need before payment orchestration makes sense?

Two or more is the practical threshold. The case for payment orchestration sharpens quickly as more providers are added.

Can payment orchestration help with recurring payments and subscriptions?

Yes. Centralized tokenization keeps recurring payments active when a merchant switches providers. Network Tokens, Account Updater, and dynamic retries recover the failed recurring charges that single-PSP setups lose to involuntary churn.

What is the difference between multi-tenant and dedicated instance payment orchestration?

Multi-tenant payment orchestration runs on shared infrastructure across all customers. Dedicated instance payment orchestration runs in a private cloud environment per customer. The trade-off is cost and time to deploy versus data sovereignty, blast-radius isolation, and configuration depth.

Payments have moved from a back-office cost line to one of the most consequential systems an online business operates. The merchants pulling away from their competition in 2026 are the ones treating it that way: measuring authorization rates the way they measure conversion, treating provider relationships as negotiable, and building the infrastructure to route transactions intelligently across multiple paths instead of accepting whatever a single PSP produces. Payment orchestration is the layer that makes that posture practical.

Gr4vy was built specifically for businesses ready to take that step. Talk to our team about your stack.