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

Dimension	PSD2 (current)	PSD3 + PSR (incoming)
Legal structure	Single directive, transposed nationally	Directive (PSD3) plus directly-applicable Regulation (PSR)
Harmonisation across Member States	Inconsistent	Uniform (for PSR conduct rules)
Payment and e-money licensing	Separate regimes	Single regime under PSD3
SCA framework	Established	Retained, expanded, clarified
IBAN-name verification	Optional for non-instant transfers	Mandatory for all credit transfers
Fraud reimbursement	Limited, uneven by Member State	Expanded, mandatory for impersonation fraud
Open banking API performance	Loosely defined	Strictly defined, regulator-enforced
Technical service provider oversight	Limited	Brought into scope
AISP passporting	National registration	EU-wide single registration
Cross-border transparency	Partial	Comprehensive
Penalties for non-compliance	Member-State discretion	Harmonised, with maximum thresholds

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:

Date	Stage	What it means
28 June 2023	European Commission publishes PSD3 and PSR proposals	Legislative process begins
November 2025	Trilogue political agreement reached	Substantive content settled
22 April 2026	COREPER endorses trilogue texts	Council preparatory approval
23 April 2026	Final compromise texts published	Text available for review
5 May 2026	ECON Committee vote (Parliament)	Committee-stage approval
Late May 2026	Parliament plenary vote	Final Parliament approval
June-September 2026	Legal-linguistic review	Final wording fixed across all official languages
Q2/Q3 2026	Publication in EU Official Journal	The starting point for all subsequent deadlines
20 days after publication	PSR enters into force	The regulation is legally operational
21 months after publication	PSR fully applicable	Full compliance required (Q1-Q4 2028)
18-21 months after publication	PSD3 national transposition deadline	Member States must have transposed PSD3 into national law

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:

Dimension	3DS1 (legacy)	3DS2 (current)
Data exchanged	Handful of fields	150+ data elements per transaction
Default flow	Challenge for every transaction	Frictionless (silent) for most transactions
Mobile experience	Web-only, poorly adapted	Native in-app SDKs
Authentication method	Static passwords	Biometrics, OTP, in-app prompts
Risk assessment	Limited	Risk-based authentication using rich data
Customer perception	Friction, abandonment	Mostly invisible
Liability shift	Yes, on authenticated transactions	Yes, on authenticated transactions

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

Dimension	Customer-Initiated Transaction (CIT)	Merchant-Initiated Transaction (MIT)
Customer presence at authorization	Yes, actively involved	No, processed without participation
Strong Customer Authentication required	Yes (in SCA-regulated regions)	No, exempt when properly flagged
3D Secure	Applied at the time of transaction	Performed once on initial CIT, then carried forward
Decision authority	Customer authorizes each transaction	Customer authorized in advance
Common examples	Online checkout, one-click repeat purchase, manual recurring confirmation	Subscription renewal, installment payment, account top-up, no-show fee
Risk profile	Higher fraud risk per transaction	Lower risk, governed by prior consent
Chargeback liability	Standard rules apply	Specific MIT chargeback codes
Authorization rates	Variable, dependent on 3DS, fraud, AVS	Often higher when properly classified
Required indicators	Standard CIT flag	MIT type indicator plus original transaction reference
Network transaction ID propagation	Generated at CIT	Must be passed forward from CIT

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:

Field	What it indicates
Initiator	Customer (CIT) or Merchant (MIT)
Stored Credential indicator	First storage, subsequent use, or no stored credential involved
Credential Type	Recurring, installment, unscheduled COF, or general subsequent CIT
MIT use case	One of the eight recognized types (recurring, installment, UCOF, resubmission, delayed charge, no-show, reauthorization, incremental)
Network Transaction ID	The value from the original CIT or prior MIT in the chain
Mastercard TLID	(Mastercard transactions) The Transaction Link Identifier from the original CIT
POS Entry Mode	Indicates the transaction was processed using stored credentials

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.

Date	Phase	What changes
October 17, 2025	Lifecycle phase	Mastercard requires acquirers and merchants to pass the TLID from the original authorization response into all subsequent lifecycle messages (captures, refunds, reversals, chargebacks)
June 2, 2026	Retention phase	Mastercard begins generating TLIDs for economically-related transactions (MITs, BNPL, installments). Acquirers must ensure merchants retain the TLID from card-not-present CITs and Account Status Inquiry (ASI) requests where credentials are stored
October 23, 2026	Active population phase	Merchants must include the stored TLID in every economically-related MIT authorization request so Mastercard can link it back to the original CIT
January 31, 2027	Compliance assessment	Mastercard begins assessing fees for non-compliance with TLID data mandates. Formal compliance is required by December 1, 2026

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.

Capability	Payment gateway	PSP	Payment orchestrator
Connects to multiple providers	Yes	No	Yes
Single API integration	Per provider	Single provider	Yes, across all providers
Intelligent routing across providers	No	Limited to internal options	Yes
Automatic failover	Yes	No	Yes
Centralized reporting across providers	No	No	Yes
Provider-agnostic tokenization	No	No	Yes
Switch providers without re-integration	No	No	Yes
Owns merchant account	No	Yes	No
Processes payments directly	No	Yes	No

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.

(Updated – June 2026)

The complexity of managing digital transactions has grown exponentially as businesses expand their reach globally. Payment orchestration offers an advanced solution for companies, acting as a centralized layer that simplifies the management of multiple payment providers, enhances security protocols, and optimizes payment routing. This article provides a comprehensive overview of payment orchestration, why it’s vital in the digital commerce landscape, and the benefits it brings to businesses looking to streamline their payment infrastructure and meet modern customer demands.

What is payment orchestration?

Payment orchestration meaning: refers to the process of managing diverse payment methods, providers, and processes through a single, integrated platform. It’s a solution that goes beyond the basic functionality of traditional payment gateways by offering businesses enhanced flexibility and control over their payment operations. A payment orchestration platform connects companies to multiple payment service providers (PSPs), gateways, fraud prevention systems, and financial services, allowing seamless payment management.

Understanding payment orchestration meaning

In today’s landscape, businesses are increasingly dealing with multiple payment methods, including cards, digital wallets, and buy now, pay later (BNPL) options. With 1,050+ payment methods available globally, it’s essential for companies to offer the flexibility to accommodate customer preferences across different regions. Payment orchestration enables this flexibility by integrating with numerous PSPs, allowing businesses to support various payment methods without needing separate integrations for each one. This orchestration layer ensures businesses can operate more efficiently, meet customer expectations, and adapt to changing payment trends.

Why payment orchestration is essential for modern businesses

For businesses operating internationally, a payment orchestration platform is invaluable. It helps manage and optimize payments across different currencies, regions, and regulatory environments, creating a seamless payment experience for customers and reducing operational burdens. Unlike traditional payment solutions, which often limit businesses to a few options, a payment orchestration platform gives companies the ability to adapt rapidly to shifting payment trends and regulatory requirements.

Payment orchestration is particularly beneficial in enhancing transaction success rates. For example, with multiple payment options integrated, businesses can avoid transaction failures by automatically redirecting transactions to an alternative provider if the primary one is down or overloaded. This infrastructure redundancy is essential in reducing payment failures and increasing customer satisfaction.

Learn more about how Gr4vy’s payment orchestration platform can streamline your payment processes.

How does payment orchestration work?

Payment orchestration operates as a centralized layer that connects businesses to various payment providers, routing transactions based on set criteria such as cost, success rate, and compliance. It also handles critical aspects like compliance, security, and real-time monitoring. Here’s a breakdown of the main components of payment orchestration.

Key components of a payment orchestration layer

1. API and SDK integrations: Payment orchestration platforms provide comprehensive APIs and SDKs, allowing businesses to connect to multiple PSPs, alternative payment methods (APMs), and fraud tools through a single integration. This reduces the complexity and time needed for setup, enabling businesses to adapt quickly to market needs.
2. Dynamic routing: Dynamic routing is a key feature that assesses each transaction in real-time and directs it to the provider with the highest approval rate or the lowest transaction fees. This routing process reduces transaction failures and optimizes costs, benefiting both the business and the end-user.
3. Compliance management: Compliance is a significant concern for businesses operating internationally. Payment orchestration platforms are PCI DSS compliant, ensuring data security and simplifying the process of meeting global and regional regulatory standards, which is especially critical as data protection laws evolve.
4. Centralized management dashboard: With a centralized dashboard, businesses gain visibility into all transaction data. This allows them to monitor trends, track performance metrics, and identify areas for improvement, making data-driven decisions that optimize payment flows and enhance efficiency.

Multi-provider routing and real-time transaction management

One of the main advantages of payment orchestration is its ability to support multiple providers and manage transactions in real-time. By connecting with multiple providers, orchestration platforms offer smart routing that chooses the best provider based on specific criteria. This capability ensures that payments are processed through the most efficient route, reducing downtime and failures.

For example, if a primary payment provider experiences an issue, payment orchestration platforms can reroute the transaction to an alternative provider. This failover routing helps maintain transaction success rates and provides customers with a reliable, seamless experience. Real-time management also allows businesses to monitor transactions and address issues as they arise, improving both operational efficiency and customer satisfaction.

Meaning of payment orchestration for businesses

Payment orchestration provides several advantages for businesses, particularly as the global ecommerce market grows—projected to reach $5.8 trillion in 2023. These benefits range from reduced costs to improved user experience, making payment orchestration a valuable tool in any digital business’s payment strategy.

Cost reduction and efficiency

Payment orchestration can significantly lower transaction fees by enabling businesses to route payments to providers with the lowest costs. High-volume merchants, in particular, can take advantage of this optimization to negotiate better rates based on volume and route transactions accordingly, reducing the cost per transaction.

Simplifying global payment operations

For businesses that operate across multiple countries, payment orchestration provides an efficient way to manage international transactions. The platform supports over 1,050 different payment methods, giving companies the flexibility to offer region-specific payment options and reduce the barriers to global market entry. By simplifying these operations, businesses can better serve international customers and navigate complex regulatory landscapes with ease.

Enhanced customer experience and conversion rates

Customer experience is a crucial factor in transaction success. Studies show that 44% of UK consumers will abandon a purchase if their preferred payment method isn’t available. By integrating various payment methods and reducing payment failures, payment orchestration platforms enhance the customer journey, resulting in higher conversion rates and lower cart abandonment rates. This flexibility not only improves customer satisfaction but also directly impacts revenue.

Explore how Gr4vy’s payment orchestration solutions can improve customer experience.

Infrastructure redundancy and failover routing

Payment orchestration platforms offer failover routing, which automatically redirects transactions to an alternate provider if the primary one is unavailable. This infrastructure redundancy helps reduce failed payments, ensuring customers can complete their purchases without interruption. By increasing the likelihood of successful transactions, businesses can build stronger customer loyalty and maintain consistent revenue streams.

Payment orchestration meaning: Real-world applications

Payment orchestration is highly beneficial across various industries, with specific use cases in ecommerce, SaaS, and digital marketplaces. Each of these sectors benefits from the flexibility and scalability that orchestration provides.

Ecommerce: simplified global payments

Ecommerce businesses often operate in multiple regions, dealing with different currencies, payment preferences, and compliance requirements. Payment orchestration supports local payment methods, dynamic currency conversion, and real-time routing, allowing ecommerce companies to meet regional demands efficiently. By offering a seamless payment experience, orchestration platforms help ecommerce companies reduce cart abandonment and improve conversion rates.

SaaS platforms: improving subscription success rates

For SaaS providers, reliable recurring billing is essential to revenue stability. Payment orchestration assists with consistent billing cycles by managing retries and offering failover routing. If a primary payment provider experiences an outage, the orchestration platform can automatically route the transaction to an alternative provider, reducing subscription cancellations due to payment failures.

Digital marketplaces: supporting multiple payment methods

Digital marketplaces that serve a diverse customer base benefit from the versatility of payment orchestration, which enables them to support a wide range of payment options like BNPL and cryptocurrencies. This inclusivity attracts a broader audience, improving customer acquisition and retention rates. Furthermore, payment orchestration streamlines the process of managing payouts to sellers, which is essential in multi-seller environments.

Key trends in payment orchestration for 2026 and beyond

The landscape of payment orchestration continues to evolve, with several key trends shaping its future. These trends underscore the importance of adopting a platform that is adaptable and scalable.

AI-enhanced payment routing and decision-making

Artificial intelligence is transforming payment orchestration, enabling platforms to make more informed routing decisions by analyzing transaction data patterns. AI can optimize payment routing by predicting the likelihood of transaction success, adapting to changes in provider performance, and reducing failed transactions. This intelligent decision-making increases approval rates and minimizes the cost impact of failed payments.

Regional compliance and security innovations

As ecommerce becomes more global, compliance with regional data protection laws and anti-fraud regulations is increasingly critical. Payment orchestration platforms are adopting automated compliance checks and implementing enhanced security protocols. In 2022, global ecommerce fraud reached $41 billion, underscoring the importance of effective fraud prevention. By centralizing compliance and security measures, orchestration platforms help businesses protect customer data and avoid regulatory penalties.

Expanding alternative and local payment methods

The demand for alternative payment methods (APMs) like digital wallets, QR payments, and real-time payments, which grew by 42.2% YoY in 2023, continues to rise. Payment orchestration platforms are integrating more of these options, allowing businesses to cater to customer preferences and improve the payment experience. This trend is essential for companies looking to expand internationally and accommodate diverse payment habits.

Learn more about compliance and fraud prevention features with Gr4vy.

How to choose the right payment orchestration platform

Selecting a suitable payment orchestration platform is critical to improving payment operations, reducing costs, and aligning with customer preferences. Here are key factors to consider:

• Scalability: A scalable platform supports business growth, accommodating new payment methods and expanding to additional regions as needed.
• Flexibility: Choose a platform that allows customization of workflows, routing rules, and integrations to meet your unique business needs.
• Security: The platform should be PCI DSS compliant and offer robust fraud detection, safeguarding customer data and reducing the risk of breaches.
• Support for multiple payment methods: Look for a platform that supports a wide range of payment methods, including digital wallets and local payment solutions.
• Centralized dashboard and analytics: An ideal payment orchestration platform should offer comprehensive analytics to track transaction performance, enabling you to identify trends and optimize payment flows.

Explore Gr4vy’s platform and features to meet your payment orchestration needs.

FAQs about payment orchestration meaning

What is the meaning of payment orchestration?

Payment orchestration is a solution that consolidates multiple payment providers, fraud detection tools, and alternative payment methods into one streamlined platform, simplifying payment processes.

How does payment orchestration differ from a PSP?

Unlike PSPs that provide limited payment options, payment orchestration platforms integrate with multiple PSPs, gateways, and security tools, allowing for greater flexibility and control.

Can payment orchestration reduce transaction fees?

Yes, payment orchestration can help businesses route transactions based on fee optimization, reducing overall transaction costs and improving profitability.

What are the benefits of payment orchestration for ecommerce?

For ecommerce businesses, payment orchestration enhances global payment handling, supports local payment preferences, and reduces failed transactions, leading to better customer experiences and increased conversion rates.

Is payment orchestration secure?

Most payment orchestration platforms ensure PCI compliance and incorporate fraud prevention measures, securing customer data and preventing unauthorized transactions.

Payment orchestration is transforming the way businesses handle transactions, providing a centralized, optimized, and secure way to manage diverse payment methods and enhance customer experience. By adopting a payment orchestration platform, companies can simplify complex processes, reduce costs, and build a flexible payment infrastructure that supports growth in today’s digital-first economy.Ready to elevate your payment process? Contact Gr4vy today to learn how our payment orchestration platform can streamline your operations with efficient, secure payment solutions.

The choice between hosted checkout and API checkout shapes how a payment stack handles every transaction. It determines PCI compliance burden, conversion potential, branding flexibility, mobile experience, how quickly new payment methods can be added, and whether the merchant can route across multiple PSPs without rebuilding. For enterprise merchants, the decision is also rarely binary, with most production payment stacks ending up using a combination of integration methods for different surfaces and transaction types.

Learn the five practical integration patterns merchants choose between in 2026 (hosted checkout, hosted fields, full API, mobile SDK, and payment links), compare them across every dimension that matters, to make a decision framework based on merchant profile, technical capacity, and business priorities. The framing throughout assumes a multi-PSP, orchestration-aware payment stack rather than a single-provider integration, because that is increasingly the architecture that most enterprise merchants operate under.

The five integration patterns at a glance

Before the deeper analysis, the short version of each option:

• Hosted checkout redirects the customer to a payment page hosted by the PSP or orchestration platform. Customers leave the merchant’s site for the payment step. Fastest to deploy, lowest PCI scope, lowest branding control.
• Hosted fields embeds secure payment input fields inside the merchant’s own checkout page. Customers stay on the merchant’s site, but card data is captured inside iframes served by the PSP or vault provider. Best balance of control and compliance.
• Full API integration uses REST APIs and SDKs to handle every aspect of the payment flow. Maximum control and branding flexibility, highest PCI compliance burden.
• Mobile SDK provides native iOS and Android components that handle in-app payment collection. Optimized for mobile-first experiences with biometric authentication and digital wallets.
• Payment links generate shareable URLs that route to a pre-configured payment page. Used for invoicing, social commerce, B2B billing, agentic flows, and any scenario where the buyer is not present at a traditional checkout.

The choice is not strictly between “hosted” and “API.” Modern payment stacks combine these patterns based on which surface the transaction is happening on, which PSP will process it, and what the business priorities are at that touchpoint.

What is hosted checkout?

A hosted checkout solution sends the customer to a payment page hosted on the PSP’s or orchestration platform’s infrastructure. The merchant’s site redirects to the hosted page, the customer completes payment there, and the customer returns to the merchant’s site after the transaction is finished or canceled.

The merchant never sees or stores card data. The PCI compliance burden is mostly absorbed by the PSP or platform, which means the merchant typically qualifies for a simpler PCI Self-Assessment Questionnaire (SAQ A) rather than a full PCI DSS audit. Setup time is hours to days for most platforms, and the integration is usually configuration-driven rather than code-heavy.

Where hosted checkout works well:

• Merchants with limited engineering bandwidth or compressed time-to-launch requirements
• Subscription businesses where checkout happens infrequently and the brand impact of a redirect is acceptable
• Smaller merchants whose volume does not justify investment in custom payment UX
• B2B sales flows where the buyer expects to leave the marketing site to complete a purchase
• Markets where the PSP’s hosted page already supports a strong selection of local payment methods

The limitations of hosted checkout:

• Customers experience a domain change during the payment step, which can introduce trust friction. Approximately 70% of checkout abandonment stems from trust concerns during transitions, according to industry research, making the redirect a measurable conversion cost in some segments.
• Branding control is limited to whatever customization the PSP allows (typically logo, colors, and some copy adjustments)
• Conversion rate optimization is harder because the merchant does not control the entire checkout funnel
• Complex payment flows (split payments, escrow, conditional captures) often cannot be expressed inside a hosted page
• Multi-PSP routing requires the hosted page itself to be PSP-agnostic, which is only true for orchestration platforms

For a deeper view of how to optimize the checkout experience regardless of integration model, see Gr4vy’s guide on checkout optimization strategies.

What is API checkout?

A full API integration uses REST APIs, server SDKs, and client-side JavaScript to build the entire payment flow inside the merchant’s environment. The customer never leaves the merchant’s site, no redirect happens, and every pixel of the payment experience is under the merchant’s control.

The trade-off is responsibility. With full API integration, card data flows through the merchant’s infrastructure, which means the merchant typically operates under PCI DSS SAQ D requirements (the most comprehensive Self-Assessment Questionnaire) and must maintain a PCI Level 1 compliant environment if transaction volumes exceed scheme thresholds. The compliance overhead is significant, with annual costs that can run from $100,000 to several hundred thousand dollars for enterprise merchants.

Where API checkout works well:

• Enterprise merchants with established payments engineering teams and budget for PCI compliance
• Marketplaces and platforms with complex payment flows that hosted pages cannot accommodate
• Brands where checkout is a meaningful part of the customer experience and the conversion impact of full UX control justifies the engineering investment
• Subscription, usage-based, and recurring businesses where billing logic is tightly coupled to product logic
• Mobile-heavy businesses where native integration through SDKs is essential

The limitations of full API checkout:

• The engineering investment is substantial, with implementation timelines typically running 3-6 months for a comprehensive integration
• PCI DSS audit scope is significantly broader, with all associated cost and operational overhead
• The merchant takes on responsibility for fraud screening, 3D Secure orchestration, error handling, and security patching of the payment surfaces
• Adding new payment methods requires development work for each one, slowing time-to-market for international expansion
• Ongoing maintenance burden is meaningful, since payment APIs evolve and the merchant’s integration has to evolve with them

Hosted fields: the underserved middle option

Most articles compare hosted checkout to full API integration as if those were the only two choices. There is a third option that combines most of the advantages of each: hosted fields.

A hosted fields integration embeds secure iframes inside the merchant’s own checkout page, with each iframe controlled by the PSP or vault provider. The customer sees what appears to be the merchant’s checkout page, but the actual card-number, expiration, and CVV inputs are running inside iframes hosted on the PSP’s domain. Card data flows directly from the customer’s browser to the PSP, never touching the merchant’s servers.

The result is PCI scope reduction similar to a hosted page (SAQ A in most implementations) combined with branding control similar to a full API integration. The customer never sees a domain change. The merchant designs the checkout page exactly as they want it. The card-input fields look and feel native to the merchant’s brand, with only the PSP-controlled inputs being technically separate.

Where hosted fields work well:

• Enterprise merchants who want to minimize PCI scope while preserving full UX control
• Brands where checkout is a measurable conversion driver and even a redirect would be costly
• Multi-PSP setups where the hosted fields can be swapped dynamically based on routing decisions
• International expansion scenarios where compliance overhead in new markets needs to be contained

The trade-offs:

• Implementation complexity sits between hosted checkout and full API, with timelines typically 1-3 months
• Browser compatibility and iframe handling require more QA than a redirect-based hosted page
• Some PSPs implement hosted fields differently, which means switching providers can require front-end work
• The PCI scope reduction depends on correct implementation; misconfigured iframes can pull additional pages into PCI scope

For merchants in the middle of the size and complexity spectrum, hosted fields is often the strongest answer and is increasingly the default pattern enterprise orchestration platforms recommend.

Mobile SDKs: the in-app integration path

A separate but related question is how to handle payments inside native mobile apps. Three options exist: redirect to a hosted page via a web view, embed hosted fields via a web view, or use a native mobile SDK provided by the PSP or orchestration platform.

Mobile SDKs are designed specifically for in-app payment collection. They provide native iOS and Android components that match platform design conventions, integrate with biometric authentication (Touch ID, Face ID, fingerprint), handle Apple Pay and Google Pay natively, and avoid the web-view friction that hosted pages create on mobile.

Where mobile SDKs are essential:

• Apps with significant transaction volume where the in-app experience materially affects conversion
• Subscription apps where biometric reauthorization is a meaningful retention signal
• Apps targeting markets where digital wallets are dominant (Apple Pay in the US, Google Pay across Android markets, regional wallets globally)
• Any app where Apple Pay or Google Pay needs to be a primary payment method

The compliance posture of mobile SDKs varies by implementation. Most modern mobile SDKs from major orchestration platforms keep card data inside the SDK’s secure context, avoiding direct exposure to the merchant’s app code, which maintains a reduced PCI scope similar to hosted fields.

For a deeper look at mobile-specific patterns, see Gr4vy’s guide on mobile checkout best practices.

Payment links: the asynchronous integration path

The fifth integration pattern is payment links, which are shareable URLs that route to a pre-configured payment page. The merchant generates a link through an API or dashboard, sends it via email, SMS, chat, or any other channel, and the recipient completes payment when they choose.

Payment links work alongside hosted checkout and API integration rather than replacing them, handling the cases where a traditional checkout flow does not fit:

• Invoicing and B2B billing: send the link in the invoice email, the buyer pays when ready
• Social commerce: share the link in Instagram DMs, WhatsApp, or social posts
• Voice and phone commerce: read the link to a customer over the phone or send via SMS
• Agentic flows: the AI agent generates a payment link for the buyer to authorize asynchronously
• Pop-up and event commerce: sales surfaces where embedding a checkout is impractical

Industry data suggests payment links can unlock 7% or more additional revenue for merchants who add them to their stack, by serving transaction scenarios that traditional checkout patterns cannot address. They are also the simplest integration path: a single API call generates a fully functional payment page.

The definitive comparison

The five integration patterns across every dimension that matters for a merchant evaluation:

Dimension	Hosted checkout	Hosted fields	Full API	Mobile SDK	Payment links
Customer experience	Redirect to PSP page	Stays on merchant site, fields in iframes	Fully native to merchant site	Native in-app	Recipient-driven, asynchronous
PCI scope	SAQ A (minimal)	SAQ A (minimal)	SAQ D (full)	SAQ A typically	SAQ A (minimal)
Branding control	Limited	High	Full	Native to platform	Configurable, PSP-hosted
Time to deploy	Hours to days	1-3 months	3-6 months	1-3 months	Hours
Engineering effort	Low	Medium	High	Medium-High	Very low
Conversion potential	Lower (redirect friction)	High	Highest	Very high in-app	High for fit use cases
Multi-PSP routing	Requires orchestration	Yes, via orchestration	Yes, requires routing layer	Yes, via orchestration	Yes, via orchestration
Mobile experience	Acceptable	Good (with mobile-optimized fields)	Good	Best	Excellent (recipient device-native)
Apple Pay / Google Pay	Limited customization	Yes	Yes	Native	Yes
Custom payment flows	Limited	Possible	Full flexibility	Full flexibility	Limited to single transactions
3D Secure handling	Managed by PSP	Managed by PSP	Merchant-implemented	Managed by SDK	Managed by PSP
Best for	Fast launch, low-volume, simple flows	Most enterprise checkouts	Complex platforms, marketplaces	Mobile-first businesses	Invoicing, B2B, async commerce

The pattern that emerges from the table: hosted fields is the strongest default for most enterprise merchants, with mobile SDK for native app surfaces, payment links for asynchronous use cases, and full API only where the complexity genuinely justifies the overhead.

When to choose hosted checkout

Choose hosted checkout when one or more of these apply:

• You are launching quickly. The hours-to-days deployment time is unmatched, and getting payments live is more important than optimizing them.
• You have limited engineering bandwidth. Hosted checkout requires the least ongoing maintenance and shifts most of the operational burden to the PSP or orchestration platform.
• Your PCI compliance posture is the priority. SAQ A is significantly less expensive and less operationally demanding than SAQ D, and hosted pages achieve this cleanly.
• Your transactions are infrequent or one-off. Subscription renewals, donation flows, ticket sales, and similar use cases where the checkout is not the brand experience.
• The PSP’s hosted page already supports your needed payment methods. International expansion is significantly faster when local methods are included in the hosted page by default.
• You operate in regulated industries where reducing data handling responsibility is a strategic priority. Healthcare, financial services, and government often default to hosted patterns specifically to limit PCI scope.

When to choose full API

Choose full API integration when one or more of these apply:

• Checkout is a meaningful part of the brand experience. Luxury retail, premium subscription services, and DTC brands where even a domain change is a measurable conversion cost.
• You operate a marketplace or platform with complex payment flows. Split payments, escrow, conditional captures, marketplace payouts, and other patterns that hosted pages cannot express.
• You have an established payments engineering team and budget for PCI compliance. SAQ D is workable but expensive, and the team has to be set up to maintain it.
• You need granular control over the payment UX at every step. Custom fraud screening, conditional 3D Secure, dynamic field validation, and similar capabilities that require code-level access.
• You are building agentic commerce flows where the agent needs deep API access. Protocol-level integrations with ChatGPT, Gemini, and other agent platforms typically require full API access. For details, see Gr4vy’s guide on how to make your checkout AI-agent-ready.

When to choose hosted fields (the most common enterprise answer)

For most enterprise merchants, hosted fields is the right default. Choose this pattern when:

• You want PCI scope reduction without sacrificing UX control. Hosted fields achieve SAQ A while keeping customers on the merchant’s site
• Your annual card volume is between $20M and several billion. This range benefits most from the balance hosted fields strike
• You operate across multiple PSPs. Hosted fields can be swapped dynamically based on routing decisions, which is the orchestration pattern most enterprise stacks use
• You want to A/B test checkout designs without backend redeploys. Hosted fields integrate cleanly with experimentation platforms
• You are migrating from a hosted checkout to gain branding control without taking on full PCI scope. This is the most common evolution path from hosted to full API

How orchestration changes the integration decision

The choice between hosted, hosted fields, and full API is often presented as a one-time decision tied to a specific PSP. With payment orchestration, the framing changes meaningfully.

An orchestration layer sits between the merchant’s checkout (whatever its integration model) and the underlying PSPs. The merchant can implement hosted fields once through the orchestration platform, and the platform routes the resulting transactions across multiple PSPs based on configurable rules. The integration model becomes a property of the merchant’s checkout, decoupled from the PSP relationships sitting underneath.

This is meaningful in three ways:

1. Integration choice is no longer locked to PSP choice. A merchant can use hosted fields with Stripe and Adyen simultaneously, with the orchestration platform deciding which PSP processes each transaction. Switching providers does not require rebuilding the checkout.

2. Different integration models can coexist. The web checkout might use hosted fields, the mobile app might use a mobile SDK, and the B2B invoicing might use payment links. All three run on the same underlying PSP relationships and the same routing rules.

3. Migration paths become smoother. A merchant that starts with hosted checkout can migrate to hosted fields without changing their PSP relationships. A merchant on hosted fields can selectively migrate to full API for specific transaction types without rebuilding everything.

This is the architecture Gr4vy’s Checkout product was built around. Hosted checkout, hosted fields, REST APIs, mobile SDKs, plugins, and payment links all sit on top of the same orchestration platform, with routing logic that connects to more than 400 PSPs and payment methods through a single integration.

PCI compliance implications

The PCI compliance burden differs significantly across integration patterns, and the differences directly affect operational cost and audit complexity.

SAQ A is the simplest Self-Assessment Questionnaire. It applies when the merchant fully outsources cardholder data handling to a PCI DSS-validated third party, with the merchant’s own systems never seeing, processing, or transmitting card data. Hosted checkout, well-implemented hosted fields, payment links, and most mobile SDKs qualify for SAQ A. The annual compliance overhead is typically a few thousand dollars and a couple of weeks of internal work.

SAQ A-EP applies when the merchant’s website or mobile app affects the security of the payment page, even though the merchant does not directly handle card data. Some hosted fields implementations fall into this category if the integration code is not isolated from sensitive elements. The compliance burden is higher than SAQ A but still significantly less than SAQ D.

SAQ D is the most comprehensive Self-Assessment Questionnaire, applicable when the merchant directly handles, processes, or transmits cardholder data. Full API integrations almost always fall into SAQ D. The annual compliance cost is meaningful, typically $100,000 to several hundred thousand dollars for enterprise merchants, plus the operational overhead of maintaining a PCI Level 1 compliant environment.

PCI DSS 4.0.1 (the current standard) tightened several requirements around stored card data, third-party script integrity, and authentication. Merchants who operated under SAQ D in 2024 should reassess whether their current architecture still represents the most efficient PCI posture, because the gap between SAQ A and SAQ D has widened. For a deeper view, see Gr4vy’s analysis of PCI DSS compliance and payment orchestration.

Migration paths: how integrations evolve

Most merchants do not stay on the integration they started with. The typical evolution looks like:

Stage 1: Hosted checkout (years 0-2). Fast launch, simple needs, limited engineering capacity. Most merchants begin here.

Stage 2: Hosted fields (years 2-5). As volume grows, the branding limitations and conversion impact of redirect become measurable. Migrating to hosted fields preserves PCI scope reduction while recovering UX control.

Stage 3: Hosted fields plus mobile SDK (years 3-7). Mobile share of revenue grows, and the in-app experience becomes a meaningful conversion driver. Adding a mobile SDK alongside the web hosted fields integration becomes standard.

Stage 4: Hosted fields plus mobile SDK plus payment links (years 4+). B2B, social, voice, and agentic use cases emerge. Payment links handle the asynchronous and non-traditional checkout scenarios that the rest of the stack cannot address.

Stage 5: Selective full API (years 5+, only where justified). Complex payment flows that hosted fields cannot express get migrated to full API. This is rarely a wholesale migration; instead, specific transaction types move to API while the bulk of the volume remains on hosted fields.

The merchants who manage this evolution best are the ones who started with an orchestration platform from the beginning, because the platform decouples the integration model from the PSP relationships and makes each migration step a configuration change rather than a rebuild.

Common integration mistakes to avoid

A handful of patterns separate well-implemented payment stacks from troubled ones:

Choosing full API integration too early. The PCI compliance overhead is significant, and the engineering team that ships the integration is often not the team that has to maintain it long-term. Most merchants under $20M in annual card volume do not yet need the level of control that full API provides, and the operational drag becomes a problem before the strategic value materializes.

Locking the integration model to a single PSP. A hosted page implementation tied to one PSP becomes a multi-month rebuild when the merchant wants to add or switch providers. Implementing through an orchestration platform from the start preserves the flexibility to add PSPs without rebuilding the integration.

Treating mobile as a secondary surface. In most B2C categories, mobile is the majority of revenue. Implementing a web-only integration first and adding mobile later typically produces a worse mobile experience than building mobile-native from the start. The order of priority should reflect where revenue actually comes from.

Skipping hosted fields and going straight from hosted to full API. Many merchants overshoot. The full API integration produces more flexibility than they need, with more PCI scope and engineering overhead. Hosted fields is the right destination for most enterprise checkouts, and the migration from hosted page to hosted fields is significantly faster than the migration from hosted page to full API.

Underestimating the ongoing maintenance burden. Payment integrations are not one-time projects. APIs evolve, security requirements tighten, new payment methods emerge, and the integration has to evolve with them. The team needs to be sized for ongoing maintenance over the long term, with initial implementation being only the first phase of a continuous commitment.

A practical decision matrix

Combining merchant profile with integration choice produces the following starting recommendations:

Merchant profile	Recommended integration	Why
Small or new business (under $1M annual card volume)	Hosted checkout	Fast launch, lowest overhead, focus engineering on product
Growing mid-market merchant ($1-20M)	Hosted checkout, planning migration to hosted fields	Capture volume now, plan UX investment when conversion impact becomes measurable
Enterprise ecommerce ($20M-$1B)	Hosted fields plus mobile SDK	Best balance of UX, PCI, and flexibility
Mobile-first enterprise	Mobile SDK plus hosted fields for web	Match the surface where revenue concentrates
Marketplace or platform	Full API where complexity demands it, hosted fields elsewhere	Complex payment flows require code-level control
B2B with invoicing	Hosted fields plus payment links	Match the buying patterns of B2B customers
Subscription business	Hosted fields plus mobile SDK plus payment links	Cover web, app, and recovery flows
Agentic commerce participant	Full API for agent surfaces, hosted fields for human surfaces	Protocol-level integration requires direct API access

These are starting points to guide further evaluation. The actual decision depends on the specific business priorities, the team’s capabilities, and the existing payment infrastructure. Many enterprise merchants operate combinations of these patterns simultaneously, with each transaction routed through whichever integration best fits the customer surface and the merchant’s priorities at that touchpoint.

Frequently asked questions

What is the difference between hosted checkout and API checkout?

Hosted checkout redirects the customer to a payment page hosted on the PSP’s or orchestration platform’s infrastructure, with the merchant never touching card data. API checkout uses REST APIs and SDKs to handle the entire payment flow inside the merchant’s environment, with the merchant taking on full responsibility for the payment UX and PCI compliance. Hosted checkout is faster to deploy and has lower PCI scope; API checkout offers maximum control and branding flexibility.

Which has higher conversion: hosted checkout or API checkout?

API checkout typically achieves higher conversion because customers stay on the merchant’s site throughout the payment process, avoiding the trust friction that a domain change introduces. Industry research suggests approximately 70% of checkout abandonment stems from trust concerns during transitions, making the redirect in hosted checkout a measurable conversion cost. However, well-implemented hosted fields (a hybrid pattern) achieve conversion close to full API while keeping PCI scope similar to hosted checkout.

Are hosted checkout and hosted payment page the same thing?

Yes, the terms are used interchangeably. Both refer to a payment page hosted on the PSP’s or orchestration platform’s infrastructure, with the customer redirected from the merchant’s site to complete the transaction.

What is the PCI compliance difference between hosted and API checkout?

Hosted checkout typically allows merchants to qualify for PCI DSS SAQ A, the simplest Self-Assessment Questionnaire, because card data never touches the merchant’s systems. API checkout almost always requires SAQ D, the most comprehensive Questionnaire, because the merchant directly handles cardholder data. The annual compliance overhead can differ by an order of magnitude, with SAQ A typically costing a few thousand dollars and SAQ D often costing $100,000 or more for enterprise merchants.

What are hosted fields?

Hosted fields are secure iframes embedded inside the merchant’s own checkout page, with each iframe controlled by the PSP or vault provider. Customers see what appears to be the merchant’s checkout, but the actual card-input fields are technically hosted on the PSP’s domain. The pattern combines PCI scope reduction similar to a hosted page with branding control similar to full API integration, which is why it is increasingly the default for enterprise checkouts.

Can I switch from hosted checkout to API checkout later?

Yes, and most merchants do. The typical evolution is from hosted checkout to hosted fields to selective full API, with mobile SDKs and payment links added along the way. The migration is significantly easier if the merchant started with an orchestration platform, because the underlying PSP relationships do not need to change when the integration model evolves.

Does API checkout support more payment methods than hosted checkout?

Not necessarily. Both patterns can support the same payment methods; the difference is how the merchant configures them. Hosted checkout often includes a pre-built selection of methods that the PSP supports, making international expansion faster. API checkout requires the merchant to integrate each method individually, which produces more flexibility but slower time-to-market for new methods.

How long does it take to integrate hosted checkout vs API checkout?

Hosted checkout typically deploys in hours to days. Hosted fields integrations take 1-3 months. Full API integrations take 3-6 months for a comprehensive implementation. Mobile SDK integrations take 1-3 months. Payment links can be live in hours.

Is hosted checkout less secure than API checkout?

No, the two are equally secure when properly implemented. Both rely on tokenization, encryption, and the underlying PSP’s security infrastructure. The PCI scope is different (hosted checkout reduces the merchant’s compliance burden) but the actual security posture of a well-implemented integration in either model is comparable.

Can I use multiple integration types at once?

Yes, and this is the most common pattern for enterprise merchants. Web checkout might use hosted fields, the mobile app might use a mobile SDK, B2B invoicing might use payment links, and complex marketplace transactions might use full API. An orchestration platform makes this practical because the underlying PSP relationships and routing rules are shared across all the integration surfaces.

What about iframes specifically: are they the same as hosted fields?

Hosted fields are a specific implementation of iframes for payment-input collection. The terms are sometimes used interchangeably, but “hosted fields” usually refers specifically to the pattern where individual card-input fields are isolated in iframes inside an otherwise merchant-controlled checkout page. Other iframe patterns exist (full-page iframe checkouts, redirect iframes) and have different trade-offs.

Does mobile SDK count as hosted or API?

Neither, exactly. Mobile SDKs are a separate integration pattern designed for in-app collection. Most modern mobile SDKs keep card data inside the SDK’s secure context (avoiding direct exposure to the merchant’s app code), which preserves PCI scope similar to hosted fields, while providing the native in-app experience that web-view-based hosted pages cannot match.

Are payment links a replacement for checkout pages?

No, they work as a complementary capability. Payment links handle asynchronous and non-traditional payment scenarios (invoicing, social commerce, voice, agentic flows) that traditional checkout patterns cannot serve. Most merchants who add payment links use them alongside their primary checkout to extend reach into new transaction types.

What to do next

The hosted vs API choice is less binary than most articles present it. The realistic question for most enterprise merchants is which combination of integration patterns best serves which transaction surface, with hosted fields as the default for most web checkouts, mobile SDK for native apps, payment links for asynchronous and B2B scenarios, and full API reserved for the specific cases where complex payment flows justify the overhead.

The architectural decision that matters most is whether all of these integration surfaces share the same underlying PSP relationships and routing rules. Merchants who run each integration on its own dedicated PSP integration multiply their operational complexity, fragment their analytics, and lock themselves into multiple parallel vendor relationships. Merchants who run their integrations on top of an orchestration platform share PSP relationships, share routing logic, and share analytics across every customer surface.

If you’re evaluating which integration pattern fits your current stack or thinking about evolving from hosted checkout to hosted fields, mobile SDK, or any other surface, contact our team for a walkthrough of how Gr4vy’s Checkout product supports all five integration patterns through a single orchestration platform.

A payment workflow is a configurable set of rules that controls how each transaction is processed: which provider it routes to, when and how it retries on failure, what payment methods appear at checkout, which fraud screening applies, and what happens at every decision point in between. Instead of hardcoding these decisions into the merchant’s payments service, modern payment workflows live in a rules engine, where they can be inspected, tested, and adjusted without engineering work.

Most merchants already run payment workflows of some kind. The question is whether those workflows live in code (where every change is a release cycle) or in a configuration layer (where every change is a few minutes of work). For enterprise merchants, the answer to that question shapes how quickly they can respond to provider outages, optimize authorization rates, add new payment methods, and adapt to changing customer behavior across markets.

This guide explains what payment workflows actually are, how they differ from generic business automation, the six core workflow patterns every merchant should understand, how to design and govern them, and how to evaluate whether your current setup is built for the pace your business needs to move at.

Payment workflows in one sentence

A payment workflow is a configurable, rule-based path that determines how a payment transaction is processed at every step, from the moment a customer reaches checkout to the moment funds are confirmed.

Three elements define a payment workflow:

Triggers: the event that activates the workflow. Common triggers include a customer reaching checkout, a transaction being declined, a card being added to a stored vault, a fraud signal firing, or a scheduled subscription renewal coming due.

Conditions: the criteria the workflow evaluates to decide what to do next. Conditions can include transaction amount, currency, customer geography, card BIN range, payment method, cart contents, customer history, time of day, or any custom metadata the merchant chooses to pass through.

Actions: what the workflow actually does when the conditions match. Actions include routing the transaction to a specific PSP, retrying with different parameters, applying or bypassing 3D Secure, displaying specific payment methods, calling a fraud provider, or escalating to dunning.

Together, these three elements describe a complete decision tree for any transaction. A workflow engine evaluates triggers, conditions, and actions in real time, producing different outcomes for different transactions based on the rules the merchant has configured.

How payment workflows differ from business workflows

The term “workflow” gets used loosely. A great deal of content in the workflow automation category refers to accounts receivable, invoice approvals, purchase orders, employee onboarding, or general business process automation. These are useful capabilities, but they are not payment workflows in the sense most merchants need.

Payment workflows are specifically the rules that govern how a transaction moves through a payment infrastructure. They differ from general business workflows in four ways:

They operate at transaction speed. A business workflow approving an invoice might take hours or days. A payment workflow has to evaluate, decide, and act in the few hundred milliseconds between a customer tapping “pay” and the issuer returning an authorization response. The performance constraints are completely different.

They span multiple providers. A payment workflow can route to one of several PSPs, fall over to a backup acquirer, query an external fraud provider, refresh a network token, and capture analytics tags, all in a single transaction. Business workflows tend to operate inside a single application; payment workflows operate across the merchant’s entire payment stack.

They are deeply rule-bound by external parties. Card networks (Visa, Mastercard, Amex, Discover), regulators (PCI DSS, PSD2/SCA, GDPR), and individual issuers all set rules that payment workflows must respect. A retry workflow that violates Visa’s Acquirer Monitoring Program can trigger penalties; a checkout workflow that mishandles Strong Customer Authentication can fail audits.

They directly affect revenue. Every payment workflow decision (which PSP, which retry timing, which fraud rule) has a measurable impact on authorization rates, conversion, and recovered revenue. Business workflows generally improve efficiency; payment workflows improve top-line performance.

The distinction matters because the tools and platforms that handle business workflows are usually not well-suited to payment workflows, and vice versa. Most enterprise merchants run them on different infrastructure for this reason.

How payment workflows work end-to-end

The mechanics of a payment workflow are best understood by walking through a single transaction.

When a customer reaches checkout, the merchant’s frontend calls the workflow engine with the transaction context: the cart, the customer’s location, the currency, the customer’s stored credentials if any, and any metadata the merchant attaches. The workflow engine evaluates the relevant trigger (“checkout reached”) against its rules. Based on the conditions (geography, cart value, customer history), it decides which payment methods to display, in which order, with which terms.

The customer chooses a payment method and enters their details (or the agent passes a delegated token, or the customer authorizes a stored credential). The merchant’s payment infrastructure passes the transaction to the workflow engine again, this time with the trigger “transaction initiated.”

The engine evaluates the routing rules. Based on the card’s BIN range, the transaction’s geography, the amount, the time of day, and the historical performance of relevant acquirers, the engine selects a PSP and submits the authorization request. If the transaction succeeds, the workflow records the result and the flow completes.

If the transaction fails, the engine evaluates retry rules. Soft declines may trigger an immediate retry through an alternate PSP, a scheduled retry for the next pay cycle, or a refresh of the underlying network token. Hard declines bypass retries entirely and may trigger customer outreach instead.

If the transaction looks fraud-suspicious, the engine may step up to 3D Secure, route to a specialized fraud provider, or escalate to manual review. Each of these decisions happens inside the same workflow engine, evaluated in real time against the merchant’s configured rules.

The same workflow engine handles subscription renewals, agent-initiated transactions, refund flows, and any other event that touches the payment stack. The workflow becomes the single layer where merchants control how payments behave, regardless of which PSP, which channel, or which transaction type is involved.

The six core payment workflow patterns

Most merchants’ payment workflows are combinations of six patterns. Each one solves a specific problem and is most powerful when combined with the others.

1. Intelligent routing workflows

Routing workflows decide which PSP, acquirer, or payment method handles each transaction. The decisions are based on card type, BIN range, geography, currency, transaction amount, historical performance, and cost. A typical rule set might route US Visa Signature transactions through Acquirer A, European Visa transactions through Acquirer B, and high-value cross-border transactions through whichever local acquirer has the strongest authorization rate for the customer’s country.

The revenue impact is meaningful: merchants implementing intelligent routing typically see 2-10% improvements in authorization rates, with cross-border transactions sometimes achieving 16% gains when routed through local acquirers. For a deeper look, see Gr4vy’s guide on intelligent payment routing.

2. Retry workflows

Retry workflows decide what happens when a transaction fails. They classify the decline (soft vs hard, by reason code), determine whether and when to retry, and choose the retry path (same PSP, alternate PSP, network token refresh, account updater). Different decline reasons get different timing and routing.

A well-designed retry workflow recovers 50-65% of failed payments, compared to 30% or less from static retry schedules. For the full framework on designing these, see Gr4vy’s deep-dive on payment retry logic.

3. Failover workflows

Failover workflows handle the case when a primary PSP or acquirer is degraded or offline. The workflow detects the failure (through health checks, error rate spikes, or response time monitoring), routes incoming transactions to a backup provider, and reverts when the primary recovers. The customer never sees the outage.

This pattern is increasingly considered essential infrastructure rather than optional resilience. Payment outages have been estimated to cost businesses tens of billions of dollars annually in lost sales, and a single-PSP setup with no failover offers no protection against any of it.

4. Fraud and risk workflows

Fraud workflows apply different risk treatments to different transactions. Low-risk traffic (returning customers, low values, trusted geographies) moves through a frictionless flow. Higher-risk transactions are routed to a dedicated fraud provider, stepped up through 3D Secure, or escalated to manual review. The workflow tunes the friction level transaction by transaction rather than applying a single rule to all of them.

The trade-off most merchants navigate is between blocking fraud and minimizing false declines. A well-designed fraud workflow reduces both at the same time, by applying friction only where the signal warrants it.

5. Dynamic checkout workflows

Dynamic checkout workflows personalize the payment experience based on the customer’s context. Different countries see different local payment methods. High-value carts see Buy Now Pay Later options. Specific merchant categories see digital wallets prioritized. The same checkout displays differently to different customers, with the rules evaluated in real time from cart and session data.

Dynamic checkout improves conversion by surfacing the most relevant payment options for each customer, reducing the cognitive load of choice and the friction of switching methods. Static checkouts that show the same options to everyone consistently underperform dynamic ones in head-to-head tests.

6. Authentication and 3DS workflows

Authentication workflows decide when and how to apply Strong Customer Authentication (SCA) or 3D Secure. The decisions are based on transaction amount, customer behavior, issuer requirements, regional regulations (PSD2 in Europe, others elsewhere), and risk signals. Frictionless 3DS handles most authenticated transactions invisibly; challenge flows kick in only when the signal warrants the friction.

A well-designed 3DS workflow protects fraud-prone transactions while letting the rest of the volume through without the conversion impact that blanket 3DS application causes.

These six patterns rarely live in isolation. A complete payment workflow stack combines all of them: routing for the initial attempt, retry rules for failures, failover for provider outages, fraud rules for risk transactions, dynamic checkout for personalization, and 3DS workflows for authentication. They interact, often within a single transaction.

Workflow examples: what rules actually look like

The abstract definitions matter less than how workflows actually get configured. Here are five concrete rule examples that illustrate the pattern in practice.

Routing rule. “If card BIN starts with 4 (Visa), transaction amount is over $500, and customer geography is France, route to Acquirer A. Otherwise, route to Acquirer B.” This kind of rule lives at the top of most routing workflows and is adjusted as merchants learn which acquirers perform best for which segments of their volume.

Retry rule. “If decline reason code is 51 (insufficient funds), retry after 3 days through the same PSP. If first retry fails, retry after 7 days through an alternate PSP with the network token. If second retry fails, trigger dunning email.” The timing-by-reason approach is what separates smart retries from static ones.

Failover rule. “If Acquirer A response time exceeds 5 seconds for three consecutive transactions, automatically route the next 1,000 transactions to Acquirer B. Check Acquirer A every 60 seconds. Resume primary routing when response times normalize.”

Dynamic checkout rule. “If customer geography is Brazil and cart value is under R$500, display PIX as the primary payment method, with cards as secondary. If cart value is over R$500, display PIX and Boleto as primary, with installments offered on cards.”

Fraud rule. “If transaction amount exceeds $1,000, customer’s IP geography does not match billing address country, and the customer has no transaction history, route to fraud provider X for additional screening. If transaction matches all three criteria but customer has more than 5 successful past transactions, bypass additional screening.”

A typical enterprise merchant runs dozens to hundreds of rules like these, organized into named workflows that handle specific transaction types or scenarios. The visual rules engine of a modern workflow platform lets payments teams build, test, and adjust these without engineering tickets.

No-code vs hardcoded workflows: the architectural choice

The single biggest architectural decision in payment workflows is whether the rules live in code or in configuration.

Hardcoded workflows are implemented inside the merchant’s payments service. Each rule is part of the application code, deployed through the normal release cycle. Changing the rule requires a developer to write the change, a code review, a deployment, and any associated testing. A simple routing adjustment can take days; a meaningful rule overhaul can take weeks.

No-code workflows live in a configuration layer outside the application code. The rules are stored as data, evaluated by a workflow engine, and managed through a visual interface. Changes are deployed in minutes. Payments teams configure rules directly; engineering involvement is limited to the integration layer and special-case logic that genuinely requires custom code.

The performance difference is significant. Merchants who move from hardcoded to no-code workflows typically see deployment timelines compress from weeks to hours, and A/B testing of payment rules becomes routine instead of exceptional. The strategic case is that payment optimization is a continuous activity, and the architecture has to support continuous iteration through frequent small adjustments instead of infrequent batched releases.

Some specific capabilities only become practical with no-code workflows:

• Testing a new PSP without rebuilding the entire payment integration
• Adjusting routing rules in response to a partner’s outage within minutes
• A/B testing retry timing across customer segments
• Localizing the checkout for new markets without engineering work
• Tagging and routing agent-initiated transactions separately from human ones, then refining the rules as performance data accumulates

This is the architectural pattern Gr4vy’s Workflows product was built around. Rules sit in a no-code engine, all six workflow patterns are supported, and changes deploy instantly. Engineering effort is reserved for the underlying integrations rather than the day-to-day optimization work.

Designing payment workflows: a practical framework

Most workflow design problems can be approached with six questions. Document the answers before implementing any rules, and revisit them quarterly.

1. What outcomes are we optimizing for? Authorization rate, cost per transaction, conversion at checkout, fraud loss, customer experience, or some combination. Different outcomes lead to different rules, and being explicit about the priority order prevents conflicting workflows.

2. What signals do we have access to? Card data (BIN, type, network), transaction data (amount, currency, geography, time), customer data (history, segment, account age), session data (device, IP, cart contents), and external data (fraud scores, risk signals). The richer the signal set, the more granular the rules can be.

3. What providers and partners are in play? PSPs, acquirers, fraud providers, vault services, network tokenization, and any other components the workflow may need to coordinate. A workflow design that assumes one PSP is different from one that needs to choose between several.

4. What is the testing and rollout strategy? New rules should be validated in shadow mode before going live, A/B tested across customer segments where possible, and monitored for unexpected behavior in the first 24-48 hours after activation. Workflows that go live without staged rollout produce more incidents than they recover revenue.

5. Who has authority to change which rules? Routing changes might sit with payments engineering, fraud rules with security, dynamic checkout with marketing, and retry rules with finance. Governance has to be explicit before the workflow engine becomes a source of disputes.

6. What is the rollback plan? Every rule change should have a clear path back. Most workflow platforms support versioning and instant revert; even with that capability, the team should know how to use it before the first incident.

These six questions cut through most of the implementation noise. The merchants who answer them upfront produce workflow architectures that scale; the merchants who do not tend to end up with rule sprawl, conflicting logic, and unclear ownership.

Common payment workflow patterns by industry

Different industries lean on different workflow combinations. A few representative examples:

Subscription businesses. Heavy emphasis on retry workflows and dunning. Network tokens and account updater services are usually in scope. Routing tends to be simpler (subscription billing volumes are predictable) but retry rules are detailed, with decline-reason-specific timing being the differentiator. Failover matters because a multi-day outage during billing cycles can wipe out a quarter’s net retention.

Marketplaces and platforms. Complex routing across sub-merchants, with each sub-merchant potentially needing different PSP relationships, fee structures, and payout flows. Dynamic checkout rules are often per-sub-merchant. Fraud workflows have to account for both the platform’s risk and the sub-merchant’s risk independently.

Travel and hospitality. High average order values, heavy cross-border traffic, and complex authorization patterns (pre-authorizations, captures, partial refunds). 3DS and authentication workflows are especially important. Failover is critical because outages during high-volume booking windows are exceptionally expensive.

Digital goods and SaaS. Strong emphasis on dynamic checkout for global reach, network tokens for retention, and retry workflows for recurring billing. Fraud workflows tend to be permissive on first-time small transactions and tighten as account value grows.

Physical retail and ecommerce. Routing optimization across acquirers is usually the highest-impact workflow. Dynamic checkout matters in markets with diverse local payment preferences. Retry workflows are less critical than in subscription but still meaningful.

Agentic commerce. A new category where the workflow has to identify agent-initiated transactions separately from human ones, apply different fraud rules, route through different fraud providers, and tag the transaction for separate analytics. For a deeper look, see Gr4vy’s guide on how to make your checkout AI-agent-ready.

The specific rule sets vary by industry, but the six core patterns apply to all of them.

Measuring workflow performance

A workflow engine without measurement is a configuration system without feedback. The metrics that matter most:

Authorization rate by workflow path. If routing workflows are sending different transactions to different paths, each path’s authorization rate should be measurable independently. The merchants who optimize routing well are the ones who can see which paths are winning.

Recovery rate by retry workflow. Soft decline categories should each have a measurable recovery rate. Tracking only the aggregate retry recovery hides the optimization opportunities specific to each decline reason.

False decline rate. Fraud workflows should be measured on false declines (legitimate transactions blocked) as much as on fraud blocked. Reducing one at the expense of the other does not improve net revenue.

Conversion at checkout. Dynamic checkout workflows should be measured on conversion rates by segment, so the impact of personalization decisions is visible.

Provider performance during failover events. Backup providers’ performance during failover is its own metric and should be monitored independently from primary provider performance.

Time-to-deploy for workflow changes. This is a meta-metric, but a useful one. Teams operating on workflow engines should be deploying changes in hours; teams operating on hardcoded workflows often see weeks. The gap is one of the strongest indicators of which architecture a team is actually running.

Common workflow mistakes and how to avoid them

Several patterns separate well-implemented workflow systems from troubled ones:

Rule sprawl. Over time, workflow rules tend to accumulate. New rules get added without retiring old ones, and the engine ends up evaluating hundreds of conditions that may conflict or duplicate. Periodic audits to consolidate, retire, and rationalize rules are essential.

Lack of staged rollout. Activating new rules directly in production, especially routing changes, is how teams cause outages. Shadow mode (evaluate the rule but do not act on it) and A/B testing should be standard practice.

Hardcoded rules masquerading as workflows. Some merchants run a “workflow engine” that is actually a thin wrapper over hardcoded logic. The test is whether non-engineering team members can change rules in minutes through a visual interface. If they cannot, the workflow engine is not delivering its core value.

Insufficient observability. Workflows that cannot be measured cannot be optimized. The metrics above belong on standard dashboards, with custom reports reserved for one-off investigations.

Treating workflows as set-and-forget. Card networks update interchange tables, issuers change risk thresholds, customer behavior shifts, and providers gain or lose capabilities. Workflow rules that worked last year may be suboptimal this year. Continuous review is part of the operating model.

Conflicting workflow logic. When multiple workflows operate on the same transaction (a routing rule, a fraud rule, and a retry rule all firing), the order of evaluation and conflict resolution has to be explicit. Implicit ordering produces unpredictable behavior.

Frequently asked questions

What are payment workflows?

Payment workflows are configurable, rule-based paths that determine how each transaction is processed. They control routing decisions (which PSP handles the transaction), retry logic (how failures are recovered), failover behavior (what happens when a provider is degraded), fraud screening (what risk treatment applies), dynamic checkout (which payment methods appear to which customers), and authentication flows (when 3D Secure is invoked). Modern payment workflows live in a rules engine outside application code, so they can be adjusted without engineering involvement.

How are payment workflows different from business workflows?

Business workflows automate processes like invoice approvals, employee onboarding, and accounts receivable. Payment workflows specifically govern transaction processing inside a payment stack. They operate at much higher speed (sub-second decisions rather than hours), span multiple providers (PSPs, acquirers, fraud tools), are constrained by external rules (card networks, regulators), and directly affect revenue (authorization rates, conversion, recovery). The infrastructure and platforms suited to business workflows are typically different from those that handle payment workflows.

What is a no-code payment workflow?

A no-code payment workflow is one configured through a visual interface rather than written in application code. Payments teams can build and modify rules through a dashboard, with changes deploying in minutes. The alternative is hardcoded workflows, where each rule is part of the application code and changes require an engineering release cycle. No-code workflows let merchants iterate on payment performance continuously rather than in occasional batched releases.

What types of payment workflows are most common?

Six patterns cover most enterprise use cases: intelligent routing (which PSP handles each transaction), retry logic (how failures are recovered), failover (what happens during provider outages), fraud and risk screening (which transactions need additional checks), dynamic checkout (which payment methods appear to which customers), and authentication workflows (when 3DS or SCA applies). Most merchants run combinations of all six.

How do payment workflows improve authorization rates?

Workflow-driven routing sends each transaction to the PSP and acquirer most likely to approve it, based on card BIN, geography, currency, and historical performance data. Workflow-driven retries recover failed transactions through alternate paths, refreshed network tokens, and decline-reason-specific timing. Together, these typically lift authorization rates by 2-10%, with cross-border transactions sometimes seeing gains of up to 16% when routed through local acquirers rather than foreign processors.

Can payment workflows handle multiple PSPs?

Yes, and this is one of the strongest reasons to use a workflow engine. Routing workflows can direct different transactions to different PSPs based on configurable rules. Failover workflows can switch between PSPs during outages. Retry workflows can attempt a failed transaction through an alternate PSP. None of this is practical inside a single-PSP integration, which is one of the reasons workflow capability is closely tied to payment orchestration.

Do payment workflows require an orchestration platform?

The two are closely related but distinct. A payment orchestration platform connects to multiple PSPs and providers; workflows are the rules that decide how transactions move through those connections. Workflow capabilities can exist inside a single-PSP setup, but they tend to be limited by the underlying provider’s roadmap. Workflows running on top of an orchestration platform have access to the full set of patterns described above.

How long does it take to implement payment workflows?

For merchants using a payment orchestration platform with workflow capability built in, implementing the initial set of rules typically takes days to weeks rather than months. The deeper work is the ongoing optimization, which is continuous. For merchants building workflow capability from scratch inside their payments service, the initial implementation is usually 3-6 months and the ongoing optimization is bottlenecked by engineering throughput.

What is dynamic checkout in the context of workflows?

Dynamic checkout is a workflow pattern that personalizes the payment options shown to each customer based on real-time data. Country, currency, cart value, customer history, and custom metadata can all be used as signals. A Brazilian customer might see PIX as the primary option; a French customer might see Cartes Bancaires; a high-value cart in either market might add installment plans. The same checkout displays differently to different customers, with the rules adjusted continuously rather than coded in static templates.

How do payment workflows handle fraud?

Fraud workflows apply different risk treatments to different transactions. Low-risk traffic moves through a frictionless flow; higher-risk transactions are routed to specialized fraud providers, stepped up through 3D Secure, or escalated to manual review. The workflow tunes the friction transaction by transaction rather than applying a uniform rule to all of them. This approach typically reduces both fraud losses and false declines at the same time, which is the only combination worth pursuing.

Can payment workflows be A/B tested?

Yes, and this is one of the main advantages of workflow-based payment infrastructure. Different rule variants can be applied to different customer segments, with the results measured against authorization rate, conversion, fraud, or any other configured metric. A/B testing of payment logic was historically rare because the engineering cost of running each test was high; with no-code workflows, it becomes routine.

What governance is needed for payment workflows?

At minimum, three governance elements are essential: clear ownership of which team can change which rules (routing typically sits with payments, fraud with security, dynamic checkout with growth), staged rollout for any rule change (shadow mode, A/B test, full deployment), and audit logging of who changed what when. Workflow platforms that lack these governance features tend to accumulate rule sprawl and ownership disputes within their first year of use.

Are payment workflows compliant with PCI DSS?

The workflows themselves are not in PCI scope, because they operate on transaction metadata and decisions rather than on cardholder data. The infrastructure that runs the workflows must be PCI compliant if it stores, processes, or transmits cardholder data, which is why most modern workflow engines operate inside PCI DSS Level 1 certified environments. Centralizing payment logic in a single PCI Level 1 workflow engine typically reduces overall PCI scope compared to scattered hardcoded logic across multiple PSP integrations.

What to do next

Payment workflows work as an architecture for the entire payment stack. Merchants who run their payment logic as configurable rules in a no-code engine consistently move faster, recover more revenue, and adapt better to provider and market changes than those who hardcode the same logic into their payment services. The architectural choice has compounding effects, because every optimization opportunity gets easier with the right foundation in place.

For merchants beginning to evaluate workflow capability, the practical first step is auditing where payment logic currently lives. If routing rules, retry schedules, fraud thresholds, and checkout personalization are spread across application code, PSP-specific configurations, and ad-hoc scripts, the engineering cost of any optimization is high enough that most optimizations do not happen. Centralizing this logic in a workflow engine is the foundation that makes everything else possible.

Gr4vy’s cloud-native payment orchestration platform was built around exactly this architecture. The Workflows engine handles routing, retries, failover, fraud, dynamic checkout, and authentication through a single no-code interface, with changes deploying in minutes and integration to more than 400 PSPs and payment methods through one API.

If you’re evaluating where your current payment logic sits or want to understand what workflow capability could unlock for your business, contact our team for a walkthrough of how Gr4vy handles each of the six core workflow patterns in production.

Between 70% and 90% of all failed card-not-present payments are soft declines, which means the card itself is fine but something temporary went wrong: a network timeout, insufficient funds at the moment of the charge, an issuer-side velocity limit, a fraud rule that fired conservatively. The transaction will likely succeed on a second attempt, if the second attempt is made at the right time, in the right way, through the right path. The merchants who get this right recover meaningful revenue. The merchants who get it wrong trigger fraud flags, annoy customers, accumulate card network penalties, and convince their own analytics teams that retries do not work.

This guide explains what payment retry logic actually is, the difference between static and smart retries, the six retry patterns every merchant should know, how card network rules constrain what is allowed, and how to implement retry logic as a workflow rather than a hardcoded loop. The framework applies to one-time card-not-present transactions, card-on-file billing, subscriptions, and agent-initiated payments. For a focused look at recovering recurring subscription declines specifically, see Gr4vy’s guide on subscription payment decline recovery.

What is payment retry logic?

Payment retry logic is the set of rules that determines when, how, and through which provider a merchant attempts to charge a card again after an initial transaction fails. The logic decides whether to retry at all (some declines should never be retried), when to retry (timing affects success rates by an order of magnitude), what to change between attempts (same PSP or different one, same authentication or stepped up, same card or updated credentials), and when to stop (network rules cap the number of attempts).

A well-designed retry strategy recovers a meaningful share of failed transactions silently, without the customer ever knowing a retry happened. A poorly designed strategy retries the wrong declines on the wrong schedule and produces worse outcomes than not retrying at all.

The cost of getting this wrong is significant. Subscription businesses lose approximately 9% of their revenue to failed payments. Up to 70% of involuntary churn stems from failed transactions, with subscription companies projected to lose $129 billion to failures in 2025 alone. Even non-subscription merchants leak meaningful revenue from cart abandonments and dropped one-time transactions that better retry logic could have recovered.

Soft declines vs hard declines: the distinction that matters most

Before any retry logic can work, the system has to know which failures are worth retrying. Card declines fall into two categories, and treating them the same is the single most common mistake in retry implementations.

Soft declines are temporary failures where the card is still valid but something specific to that moment caused the transaction to fail. Common soft decline reasons include insufficient funds, processor timeouts, issuer-side velocity limits, “do not honor” responses, generic risk flags, and bank-side authentication issues. Soft declines account for 70-90% of all CNP payment failures and represent the bulk of recoverable revenue.

Hard declines are permanent failures where the card cannot be used and retrying will not change the outcome. Common hard decline reasons include stolen card, lost card, closed account, expired card, restricted card, fraud-block, and pickup-card responses. Retrying a hard decline wastes processing fees, triggers card network penalties, and damages the merchant’s standing with the issuing bank.

The challenge is that decline codes are imperfect signals. There are roughly 160 distinct decline reasons across the major card networks, and the mapping between codes and the soft/hard distinction is not always clean. American Express, for example, returns a single decline code for approximately 85% of its declines, hiding the underlying reason. Visa’s “do not honor” (code 05) is technically a soft decline but sometimes masks permanent issues.

The practical implication is that retry logic should be configured around decline-reason categories rather than a strict soft-versus-hard binary. Ambiguous codes (such as do not honor) are typically treated as soft with a longer retry window, then escalated to customer outreach if retries fail. For a comprehensive reference, see Gr4vy’s updated list of credit card decline codes and how to fix them.

Static retries vs smart retries

Most merchants start with static retry logic. Some never move beyond it. The performance difference between static and smart retries is significant enough that the upgrade is usually one of the highest-impact payments improvements a business can make.

Static retries

A static retry schedule attempts the failed payment at fixed intervals regardless of the decline reason or context. A common pattern is to retry after 1 day, then 3 days, then 7 days, then 14 days. The schedule is the same for every failure, every customer, and every card.

Static retries are simple to implement. They are also leaving meaningful revenue on the table, because the timing of a retry is one of the largest determinants of whether it succeeds. A retry attempted at 2 AM on a Tuesday performs differently than one attempted at 9 AM on the day after payday. Insufficient-funds declines need different timing than network timeouts. The same schedule cannot be optimal for all of them.

Smart retries

A smart retry strategy adapts to the specific decline reason, the customer context, and the historical performance of similar transactions. Implementations vary, but the common building blocks are:

• Decline-reason-specific timing: insufficient-funds declines are retried in line with typical payroll cycles; network timeouts are retried within seconds; issuer velocity limits are retried after the velocity window resets
• Customer-context awareness: a customer whose card recently succeeded has a different retry profile than one whose card has failed three months running
• Cross-PSP routing: retries can be sent to a different acquirer than the original attempt, which often resolves declines that were caused by an issuer-acquirer combination rather than the card itself
• Network token refresh: if a card was reissued, retrying with a network token can succeed where the original attempt failed
• Statistical optimization: machine learning models trained on historical retry outcomes can predict the highest-probability time and path for each retry

The performance gap between static and smart retries is significant. Paddle data shows that adding three extra retries within the standard dunning window lifted failed payment recoveries by 20.2%. Retrying 24 hours after the initial failure rather than 2 hours improved recovery by 6.5%. Some retail merchants have lifted monthly authorization rates from 88% to 95% through smart retry implementation, with no increase in fraud.

The six retry patterns every merchant should know

A complete retry strategy uses several different patterns, each suited to a specific failure mode. The merchants who recover the most failed transactions combine all six, with the workflow engine deciding which pattern applies to each specific decline.

1. Immediate same-PSP retry

A retry attempted within seconds of the initial failure, through the same PSP and acquirer. This pattern is appropriate for network timeouts, transient connection errors, and processor-side hiccups. Most modern PSPs handle this internally without merchant configuration, but the boundary between “internal retry” and “merchant-initiated retry” varies by provider and is worth understanding for any audit of recovery performance.

2. Scheduled time-based retry

A retry attempted hours or days after the initial failure, following a fixed or smart schedule. This is the standard pattern for insufficient-funds declines, where waiting until after a typical pay cycle materially improves success rates. Schedule design matters: aligning retries with customer paydays produces higher recovery than arbitrary day-counts.

3. Alternate-PSP retry

A retry routed to a different PSP or acquirer than the original attempt. This pattern is especially powerful for cross-border transactions and for issuer-specific decline patterns. A transaction that declined through a foreign acquirer may succeed when routed through a local one. A card that one issuer-acquirer pairing rejects may be accepted by a different one. This is one of the strongest cases for intelligent payment routing and is only possible inside a multi-PSP setup.

4. Network token retry

A retry attempted with a network token rather than the original PAN, or with an updated network token if the underlying card has changed. Because network tokens automatically reflect card reissue and update events at the network level, a retry against the network token will succeed in cases where the original credential has gone stale. This pattern is especially effective for card-on-file and subscription billing, and for merchants who experience high involuntary churn from expired or reissued cards.

5. Account updater retry

A retry attempted after an account updater service has refreshed the underlying card data. Visa Account Updater and Mastercard’s Automatic Billing Updater both provide programmatic ways to refresh stored card details when the underlying account has changed. The merchant queries the updater service, receives any updated credentials, then retries the transaction with the new data. This is most useful for periodic batch retries on dormant credentials.

6. Dunning-driven retry with customer contact

A retry combined with proactive customer outreach. For ambiguous decline reasons or repeated failures, this pattern emails or messages the customer to update their payment method or take other action, then retries the transaction with the updated credentials. Dunning is the last line of defense before treating the customer as lost.

The strongest retry strategies use all six patterns together. A workflow engine decides which pattern applies to each decline, often combining several (for example, an immediate same-PSP retry followed by a scheduled alternate-PSP retry with a network token, with dunning kicking in if all of the above fail).

What card network rules actually allow

Retry logic operates inside constraints set by the card networks. Violating those constraints can produce penalties, increased processing fees, or merchant program reviews. The rules are worth understanding before designing any retry strategy.

Visa rules cap merchant-initiated retries at 15 attempts within a 120-day period for the same transaction. Visa also requires merchants to honor decline reason codes: certain codes (such as 04 “pick up card” or 41 “lost card”) prohibit retries entirely. Excessive retry attempts can trigger Visa’s Acquirer Monitoring Program.

Mastercard rules are similar, with slightly different specific thresholds. Mastercard’s Excessive Decline Rate program monitors merchants whose decline rates exceed defined thresholds, and excessive retries on hard declines are a primary trigger.

American Express and Discover operate their own retry rules through their closed-loop systems. Both are stricter on certain decline categories than Visa or Mastercard, particularly for fraud-flagged transactions.

For most merchants, the practical implications are:

• Do not retry hard declines under any circumstances
• Limit retries to 3-5 attempts in most cases (the network maximum is rarely the optimal number)
• Space retries appropriately (immediate retries on the same path often produce worse outcomes than waiting)
• Stop retrying when the decline reason explicitly forbids it (this requires decline-code-aware logic, not blanket schedules)

The merchants who consistently exceed network retry thresholds end up paying for it, sometimes through higher fees, sometimes through merchant program intervention, and sometimes through the gradual erosion of their reputation with issuers.

How to design your retry rules: a framework

A practical retry strategy can be designed using six decisions. Document each one before implementation, and revisit them quarterly as performance data accumulates.

Decision 1: Which decline reasons are retry-eligible? Build a mapping of decline codes to retry policies. Most modern retry implementations group codes into categories (retry-now, retry-scheduled, retry-with-updater, dunning-required, do-not-retry) rather than handling each code individually.

Decision 2: What is the timing schedule for each retry-eligible category? Different decline reasons benefit from different timing. Insufficient funds responds to payday-aligned timing. Velocity limits respond to short waiting periods. Network timeouts respond to immediate retries through alternate paths.

Decision 3: How many attempts are allowed before escalation? Most enterprise merchants land on 3-5 retries within a 10-14 day window. Beyond this, marginal recovery drops sharply and network penalty risk rises.

Decision 4: Will retries go through the same PSP, an alternate one, or a configurable mix? Multi-PSP retry routing requires an orchestration layer but typically produces 2-5 percentage points of additional recovery. Single-PSP retries are simpler but capped in performance.

Decision 5: Are network tokens enabled, and is the account updater running? Both are prerequisites for the highest-performance retry patterns. The decline reduction from network tokens specifically can be 15-25% on card-on-file portfolios.

Decision 6: When does dunning kick in? Customer-facing communication should typically wait until silent retries have exhausted (or are about to exhaust) their attempts. Premature dunning frustrates customers; late dunning loses recovery opportunity.

These six decisions can be encoded in a workflow engine and adjusted without code changes, which is the operational pattern most modern payment teams now use.

Implementing retry logic as a workflow rather than hardcoded logic

Traditional retry implementations hardcode the schedule, decline mapping, and routing logic into the merchant’s payments service. Changing any of it requires engineering effort, redeployment, and the usual release cycle overhead. For a function as performance-sensitive as retry logic, this is the wrong architecture.

A workflow-based approach treats retry logic as configuration. The rules engine handles decline code classification, routing decisions, retry timing, and escalation policies through a visual interface. Changes are deployed in minutes rather than weeks. A/B tests on retry strategies become routine. Payment teams can iterate without filing engineering tickets.

This is the model Gr4vy’s Workflows product was built around. Retry rules sit alongside routing rules, fraud rules, and dynamic checkout rules in a single no-code engine. A typical merchant configuration might encode:

• Soft declines route to immediate same-PSP retry
• Insufficient funds route to a 3-day scheduled retry, then a 7-day retry through an alternate acquirer
• Velocity limits route to a 24-hour delayed retry through the same PSP
• Network timeouts retry immediately through an alternate acquirer
• Hard declines bypass retry entirely and trigger dunning
• After three failed retries, the workflow triggers an email to the customer and a final retry 48 hours later
• After five total failures, the customer is moved to an inactive state and the subscription is paused

The same configuration that took six weeks to implement in a hardcoded retry service typically takes a few hours in a workflow engine, and updates that previously required engineering sprints become same-day adjustments.

Common retry mistakes that cost merchants revenue

A handful of patterns consistently separate merchants who recover failed transactions from those who do not:

Treating all declines as binary. Configuring a single retry schedule for “any failure” wastes both opportunities (different declines respond to different timing) and risk capacity (hard declines get retried and trigger network penalties).

Retrying too frequently in the early window. Multiple retries in the first hour after a failure rarely succeed and often look fraud-suspicious to issuers. The standard guidance is to wait at least 24 hours between attempts on the same path, with shorter windows reserved for retries through alternate paths.

Skipping the alternate-PSP path. Single-PSP retry setups cap the achievable recovery at whatever the original acquirer can produce. Adding alternate-PSP routing for retries typically lifts recovery by 2-5 percentage points and is one of the strongest cases for orchestration.

Not using network tokens for card-on-file retries. Merchants who run subscription billing without network tokens are leaving the largest single retry-improvement on the table. The 15-25% reduction in card-reissue declines from network tokens shows up directly in retry success rates.

Ignoring decline-reason-specific timing. A 1-day, 3-day, 7-day schedule applied to every decline category produces strictly worse outcomes than reason-specific timing. The engineering effort to implement reason-aware timing is modest; the recovery improvement is meaningful.

Hardcoding retry logic. Retry strategies are exactly the kind of logic that benefits most from rapid iteration. Hardcoding it produces strategies that lag the data by months because every adjustment requires an engineering sprint. Configuration-based retry logic in a workflow engine lets payment teams iterate weekly.

Missing the dunning handoff. A retry strategy that never escalates to customer outreach loses the opportunity to recover hard-decline customers who would gladly update their payment method. Silent recovery has limits; dunning closes the gap.

A worked ROI example

For a subscription business processing $50M in annual recurring card volume, with a baseline failed-payment rate of 8% and current static retry recovery of 30%:

Current state. Failed payments total $4M annually (8% of $50M). Static retries recover 30%, or $1.2M. Net loss from failures: $2.8M annually.

With smart retry logic (decline-reason-aware timing, alternate-PSP routing, network tokens, multi-pattern strategy). Industry data suggests this typically lifts recovery from 30% to 50-65%. Taking the conservative midpoint of 55%, recovery rises to $2.2M annually. Net loss falls from $2.8M to $1.8M.

Annual revenue impact: approximately $1M of additional recovered subscription revenue, with no change to acquisition spend or product. For a subscription business, the recovery also avoids the lifetime value loss from involuntary churn, which typically adds another 30-50% to the headline number when measured across customer lifecycles.

The math is even stronger for larger merchants, because retry infrastructure costs are largely fixed while the recovery scales linearly with volume.

Frequently asked questions

What is payment retry logic?

Payment retry logic is the set of rules a merchant uses to attempt a failed transaction again, including when to retry, how often, through which payment provider, and when to stop. Effective retry logic distinguishes between soft declines that benefit from retries and hard declines that should not be retried, applies decline-reason-specific timing, and operates within card network rules that cap the number and frequency of attempts.

What is the difference between soft declines and hard declines?

Soft declines are temporary failures where the card is still valid and a retry has a meaningful chance of success. Common reasons include insufficient funds, network timeouts, and issuer velocity limits. Hard declines are permanent failures where retrying will not succeed and may trigger penalties. Common reasons include stolen card, closed account, and fraud blocks. Soft declines account for 70-90% of all card-not-present payment failures, which is why retry strategy focuses on them.

How many times should I retry a failed payment?

Three to five attempts spread over 10-14 days is the optimal range for most merchants. Card networks allow up to 15 attempts within 120 days, but recovery diminishes sharply after the first few attempts and excessive retries can trigger network penalties. The specific schedule should vary by decline reason rather than apply uniformly.

What is the difference between static retries and smart retries?

Static retries apply the same fixed schedule to every failure regardless of decline reason or context. Smart retries adapt the timing, routing, and approach based on the specific decline code, the customer’s history, and the predicted success probability of each retry path. Smart retries typically recover 20-50% more revenue than static retries on the same failure volume.

Can I retry payments through a different PSP than the original?

Yes, if your payment infrastructure supports it. Multi-PSP retry routing means a failed transaction can be retried through an alternate acquirer or processor that may have a stronger relationship with the issuing bank, a stronger local presence in the customer’s geography, or a better historical performance for that specific card type. Cross-PSP retries typically add 2-5 percentage points of recovery beyond same-PSP retries alone.

What is network token retry?

A network token retry uses a network-issued token (from Visa Token Service, Mastercard MDES, American Express Token Service, or Discover’s tokenization service) in place of the original card number. Because network tokens automatically reflect card reissue and expiration updates at the network level, a retry against the network token succeeds in cases where the original credential has gone stale. This pattern is especially effective for card-on-file and subscription retries.

Should I retry payments immediately or wait?

It depends on the decline reason. Network timeouts and transient processor errors often resolve within seconds and benefit from immediate retries through alternate paths. Insufficient funds declines benefit from waiting hours or days, ideally aligned with the customer’s payday cycle. Issuer velocity limits require waiting until the velocity window resets. The single worst pattern is retrying the same path repeatedly within minutes, which both fails to recover and looks suspicious to fraud systems.

Do retries count against my chargeback rate or fraud metrics?

Retries themselves do not count as chargebacks, but excessive retries on hard declines or fraud-flagged transactions can trigger card network monitoring programs. Visa’s Acquirer Monitoring Program and Mastercard’s Excessive Decline Rate program both track merchants whose retry patterns suggest noncompliance with network rules. The practical guidance is to never retry hard declines and to limit retry frequency on ambiguous decline codes.

How does dunning relate to retry logic?

Dunning is the customer-facing component of retry strategy. After silent retries have exhausted or are about to exhaust, dunning emails or messages the customer to update their payment method or take other action. The most effective retry strategies use silent retries first (no customer involvement, no friction) and escalate to dunning only when silent recovery has failed. Premature dunning frustrates customers; late dunning misses recovery opportunity.

What is involuntary churn and how do retries reduce it?

Involuntary churn is when a customer’s subscription ends because of a failed payment they did not intend. It typically accounts for 20-40% of all subscription churn. Smart retry logic, especially when combined with network tokens and account updater services, recovers 50-70% of the payments that would otherwise cause involuntary churn. For most subscription businesses, retry logic is the single most effective churn-reduction tool available.

Can retry logic be configured without engineering work?

Yes, when retry logic is implemented as a workflow rather than hardcoded into the payments service. A workflow engine lets payment teams configure decline-code mapping, timing schedules, routing decisions, and escalation rules through a visual interface, with changes deploying in minutes rather than weeks. This is the architectural pattern most modern payment teams now use, and it is the core function of platforms like Gr4vy’s Workflows product.

How long does it take to implement smart retry logic?

For merchants with an existing orchestration platform or workflow engine, smart retry configuration typically takes days to weeks. For merchants building retry logic from scratch inside their payments service, the timeline is usually 8-16 weeks including testing and rollout. The biggest variable is the data engineering work required to map decline codes accurately to retry policies, which most modern platforms handle out of the box.

What metrics should I track for retry performance?

Five metrics matter most: overall recovery rate (percentage of failed transactions eventually collected), recovery rate by decline reason (to identify which categories perform well or poorly), time-to-recovery (how long it takes from initial failure to successful charge), retry-attempt distribution (how many retries each successful recovery required), and customer experience metrics (complaints, support tickets, churn following failed transactions). Tracking only the overall recovery rate hides significant optimization opportunities.

Payment retry logic is one of the most impactful optimizations available to any merchant with meaningful card-not-present volume. The merchants who treat retries as a workflow problem (configurable, decline-reason-aware, multi-pattern, multi-PSP) consistently recover meaningfully more revenue than those who treat it as a fixed cron job that runs the same schedule for every failure.

The infrastructure pattern that makes this work is the same one that makes payment orchestration valuable generally: rules separated from code, routing separated from a single PSP, tokens separated from a single vault. Retry logic running on top of that infrastructure becomes a continuous optimization rather than a one-time engineering project.

If you’re evaluating where your current retry strategy sits or want to understand what the recovery improvement could look like with smart, multi-pattern retry logic running on top of your existing PSPs, contact our team for a walkthrough of how Gr4vy’s Workflows engine handles retries across acquirers, networks, and decline categories through a single configuration layer.

Most enterprise merchants start their tokenization journey with PSP tokens, because that is the default option every payment service provider offers out of the box. The integration is fast, the vault is managed by the provider, and the immediate security and PCI scope benefits are real. The trade-off is vendor lock-in. Once millions of stored credentials sit inside one PSP’s vault, switching providers, adding a second one, or capturing the 2-7% authorization rate lift from network tokens becomes operationally complex and easy to defer.

This guide is for merchants who have decided to migrate. It covers what to audit before starting, the five stages of a typical PSP-to-network-token migration, how to handle the operationally sensitive credential migration step, common pitfalls, expected timelines and resource requirements, and how to measure ROI as the migration proceeds.

For a foundational understanding of how PSP tokens and network tokens differ before reading this guide, our overview of PSP tokens vs network tokens covers the basics.

Why merchants migrate: the six business triggers

Token migration is significant engineering work. Merchants typically commit to it when one or more of the following business pressures becomes acute:

1. Adding a second PSP. The single most common trigger. The moment a merchant decides to operate with more than one PSP (for redundancy, regional coverage, cost optimization, or specific payment method support), PSP-locked tokens become a structural problem. Cards stored with the existing PSP cannot be charged through the new one without either re-collecting from customers or migrating the underlying credentials.

2. Subscription decline rates climbing. PSP tokens do not auto-update when underlying cards are reissued. Subscription businesses typically see 5-8% involuntary churn from expired or reissued cards, with most of that loss preventable through network tokenization. Network tokens automatically refresh at the network level, removing this source of churn entirely.

3. Cross-border expansion. Merchants expanding into new geographies often discover their current PSP’s coverage is weakest in exactly the markets they need most. Local acquirers typically deliver 10-16% higher authorization rates than foreign processors for in-market cards, but unlocking those acquirers requires moving stored credentials out of the PSP-locked vault.

4. Acquisition or merger integration. Post-acquisition integration almost always surfaces incompatible PSP token stores. The acquiring company runs Stripe, the acquired company runs Adyen, and unifying the customer book requires either dual-running both stacks indefinitely or migrating one set of tokens to a common provider-agnostic layer.

5. Pricing renegotiation power. Merchants with PSP-locked tokens negotiate from a position of weakness. The PSP knows the cost of switching is high, and pricing conversations reflect this. Merchants with portable tokens negotiate from parity, which typically translates to meaningfully better pricing terms within the first negotiation cycle.

6. PCI DSS 4.0.1 audit pressure. The current PCI DSS standard tightens requirements around stored cardholder data. Some merchants find that consolidating onto network tokens through a single PCI Level 1 vault simplifies their audit posture substantially compared to maintaining cardholder data across multiple PSP integrations.

If any two of these apply to your business, the migration math typically works in the first year. If three or more apply, deferring the migration becomes the more expensive option.

The pre-migration audit: ten questions to answer first

Before any technical work begins, the migration project needs answers to ten questions. The answers determine timeline, complexity, and which providers need to be involved.

1. How many stored credentials does the migration cover? Total count, plus the split between active customers (last transaction within 12 months) and dormant ones.
2. Which PSPs hold those credentials today? Single-PSP migrations are simpler than multi-PSP consolidations.
3. What proportion is card-on-file or subscription versus one-time? Card-on-file volume is where the migration ROI concentrates.
4. What is the current authorization rate, segmented by card type and geography? This becomes the baseline against which the post-migration lift is measured.
5. What is the current involuntary churn rate on subscription customers? Card-reissue declines are the largest single category, and network tokens address them directly.
6. What is the contractual relationship with the current PSP? Specifically, the data export provisions and any contractual limits on credential portability.
7. Where will the migrated tokens live? Merchant-controlled vault, third-party PCI Level 1 vault, or orchestration platform.
8. Which network tokens will be provisioned? Visa Token Service (VTS), Mastercard Digital Enablement Service (MDES), American Express Token Service, Discover’s tokenization service, or a combination.
9. What is the rollback plan if something goes wrong? Dual-write architectures during transition are the standard answer.
10. Who owns the migration internally? Payments engineering, infrastructure, security, and finance all need to be aligned before stage 1 begins.

The audit typically takes 1-2 weeks for a mid-market merchant and 3-4 weeks for an enterprise with multiple PSPs. It is time well spent, because every downstream stage assumes these answers.

The five-stage migration framework

A typical PSP-to-network-token migration runs through five stages. The stages are sequential, but several can be partially overlapped to compress the timeline.

Stage 1: Stand up the vault layer

The first technical step is implementing the destination vault. This is the PCI DSS Level 1 certified environment that will hold the underlying PAN data after migration. There are three common approaches:

Approach A: Use a third-party vault provider. Provider-agnostic vaults from Basis Theory, VGS, or Gr4vy’s Cloud Vault handle the certification, infrastructure, and ongoing PCI scope. Most enterprise merchants choose this path because the build-versus-buy math rarely favors building.

Approach B: Use an orchestration platform with vaulting built in. This is the option that simplifies the entire architecture, because the vault and the routing layer share a single integration. The orchestration platform handles vault storage, network token provisioning, and PSP routing through one API.

Approach C: Build an in-house vault. Some very large merchants with specialized requirements run their own PCI Level 1 vault. This is significant engineering work (typically 9-18 months and multi-million-dollar investment) and ongoing compliance burden, but provides maximum control.

Whichever path is chosen, the vault must be operational, certified, and integrated with the merchant’s checkout before stage 2 begins.

Stage 2: Dual-write architecture for new transactions

Once the vault is live, the merchant’s checkout starts writing every new card to both the existing PSP vault (for backward compatibility) and the new vault (for forward compatibility). The PSP token continues to be used for transactions during this stage; the new vault is populated in parallel but not yet active.

This dual-write phase is the single most important risk-mitigation step in the entire migration. It allows the merchant to validate that the new vault is capturing data correctly, that the integration is stable, and that the operations team is comfortable with the new system before any production transactions depend on it.

Dual-write typically runs for 2-4 weeks. During this period, the merchant’s payments analytics should be checking that every new card written to the PSP also gets a corresponding entry in the new vault, with no data loss or mismatch.

Stage 3: Migrate stored credentials

This is the operationally sensitive step. The stored cards that live inside the current PSP’s vault need to be moved into the new vault. There are three primary methods, each with different trade-offs:

Method 1: PSP-supported export. Most major PSPs support credential export procedures for departing merchants. Stripe’s Data Migration program, Adyen’s tokenization export, and similar processes at Braintree and Worldpay all exist, though the specific terms vary by contract. The export typically takes 4-12 weeks of coordinated work between the merchant, the current PSP, and the destination vault.

Method 2: Network token re-provisioning. Visa, Mastercard, and American Express can provision network tokens directly against the underlying PAN without requiring the PAN to leave the PSP’s vault, in some implementation patterns. This approach works particularly well when both the current PSP and the destination vault are integrated with the same network tokenization services. The migration becomes a metadata operation rather than a full credential transfer.

Method 3: Card-on-file re-authorization. For active customers, a hybrid approach involves issuing a $0 or $1 authorization request to refresh the credential, capturing the response, and storing it in the new vault. This works for active customers but does nothing for dormant accounts.

The right method depends on the PSP, the merchant’s contract, and the network tokenization partners involved. Most enterprise migrations use a combination: PSP-supported export for the bulk of the credentials, network re-provisioning where it is faster, and re-authorization for any remaining edge cases.

This stage is also where data loss or corruption risk is highest. The most defensible approach is to migrate in batches (typically 10% of the credential book per week), with reconciliation checks after each batch confirming that every credential migrated successfully and the resulting tokens authorize correctly.

Stage 4: Provision network tokens

Once cards live in the merchant-controlled vault, network tokens can be provisioned against them. The provisioning typically happens through the vault provider or orchestration platform, not directly by the merchant. The technical work involves:

• Connecting the vault to Visa Token Service, Mastercard MDES, American Express Token Service, and Discover’s tokenization service (or whichever subset is in scope)
• Submitting the underlying PANs for token provisioning
• Storing the returned network tokens alongside the existing PAN reference
• Configuring cryptogram generation for each authorization request

For most enterprise vaults, this provisioning runs as a back-end batch process and takes 1-3 weeks depending on the volume of credentials. The credentials being provisioned can already be in active use through merchant tokens during this stage; network tokens are provisioned underneath without disrupting transactions.

A useful detail: not every card is eligible for network tokenization. Issuer participation varies, and certain card types (some commercial cards, certain co-branded cards) may not be tokenized at the network level. Plan for roughly 80-90% of the credential book to be eligible for network tokenization, with the remainder continuing as merchant tokens.

Stage 5: Route through orchestration

The final stage activates the new infrastructure. The orchestration layer (or routing logic, if no orchestration platform is being used) is configured to:

• Use network tokens for eligible card-on-file and CNP transactions
• Fall back to merchant tokens for cards not yet network-tokenized
• Route each transaction to the PSP and acquirer most likely to approve it for that specific token, card, and geography
• Handle cryptogram management and lifecycle updates automatically

Once routing is active, the merchant can begin running A/B comparisons between transactions routed through network tokens and the legacy PSP-token-only flow. The authorization rate lift typically becomes visible within the first month, and the full revenue impact compounds across subsequent billing cycles for subscription businesses.

The credential migration step in detail

The migration of stored credentials (stage 3) is where most migration projects encounter unexpected issues. A closer look at what actually happens at this stage helps anticipate them.

What “migrating credentials” really means

The merchant’s current PSP holds the underlying PAN for every stored customer. The merchant typically does not have direct access to those PANs (they live inside the PSP’s PCI environment). To migrate, the PAN data needs to move from the source PSP’s vault to the destination vault, in a way that is PCI compliant at every step.

In practice, this means the source PSP exports the PANs into an encrypted file that is transmitted directly to the destination vault provider through a secure channel. Both parties verify the file integrity, the destination vault ingests the data and generates new tokens, and the merchant updates their customer records to reference the new tokens.

The merchant never sees the raw PAN data during this process. Both PSPs are responsible for maintaining PCI compliance at their respective ends.

What can go wrong

Three failure modes account for most migration incidents:

Data integrity issues. Encrypted file transfers can drop, corrupt, or duplicate records. Reconciliation procedures need to verify that every credential in the source set appears exactly once in the destination set, with the correct customer mapping. Batching the migration helps catch issues early.

Customer record mismatches. If the merchant’s database uses different customer IDs than the PSP’s vault, or if there are duplicate customer accounts in the source system, the migration can produce orphan tokens (no customer to associate them with) or duplicate associations (one customer linked to two tokens). Pre-migration data cleanup prevents this.

Authentication failures during the transition. During the dual-write phase and the credential migration window, some customers may transact, update their card, or churn. The migration plan needs to handle these mid-flight changes without losing data or double-charging.

Reconciliation: the step nobody talks about

After every batch of credentials moves, reconciliation has to confirm three things:

1. Every credential in the source batch produced a corresponding token in the destination vault
2. The new tokens, when used in a $0 authorization, return success responses from the issuer
3. The customer records in the merchant’s database point correctly to the new tokens

Reconciliation typically runs the day after each batch. Any discrepancies are investigated and corrected before the next batch begins. Skipping reconciliation is how migrations produce silent data loss that only becomes visible months later when subscription renewals start failing.

Common pitfalls and how to avoid them

A handful of patterns separate successful migrations from troubled ones:

Migrating active and dormant credentials with the same plan. Active customers (last transaction within 12 months) have valid cards that can be reauthorized as part of the migration. Dormant customers may have expired or replaced cards that will only become visible as failures. Plan separately for the two populations. For dormant customers, accept that some credentials will not migrate cleanly and that the next transaction (whenever it happens) may decline.

Underestimating the PSP cooperation requirement. The current PSP has to participate in the migration. They are not always eager to help a departing customer. Build the migration contract terms before any technical work begins, and make sure the PSP’s data export commitments are written into the agreement.

Skipping the dual-write phase. Some teams want to move fast and migrate directly from PSP tokens to network tokens without a dual-write period. The savings in calendar time are real, but the risk of an undetected failure mode taking down live transactions is also real. The conservative approach (dual-write for 2-4 weeks) catches issues before they reach production.

Failing to plan for cards that cannot be network-tokenized. Roughly 10-20% of cards in a typical book will not be eligible for network tokenization on day one. The migration plan needs to handle these gracefully, either by keeping them as merchant tokens in the new vault or by gradually re-attempting network tokenization as issuer participation expands.

Not measuring the right metrics. The migration’s success is measured in authorization rate lift, decline reduction on card-on-file transactions, and reduction in involuntary churn. Some teams measure migration success in operational metrics (credentials migrated, percent complete) and miss whether the migration is actually delivering the business outcomes. Both sets of metrics matter.

Treating it as a one-time event rather than a capability. Once the vault and orchestration layer are in place, adding new PSPs, switching primary processors, or running A/B tests across providers becomes routine. The migration is the hard part. The flexibility it unlocks is the lasting benefit.

Migration ROI: a worked example

For an enterprise merchant processing $100M in annual card volume, with 70% card-not-present and 30% card-on-file or subscription billing, the typical migration delivers:

Authorization rate lift on CNP volume. A 4.6% lift on $70M in CNP volume translates to roughly $3.22M in additional approved transactions per year that would have declined without network tokens.

Subscription churn reduction. On $30M in card-on-file volume with a baseline 5-8% involuntary churn rate, a 20% reduction in card-reissue declines recovers $300K-$480K per year.

Fraud reduction. A 30% reduction in fraud on a baseline 0.5% chargeback rate saves approximately $150K in chargebacks and associated fees.

Visa interchange incentive. The 0.10% incentive on eligible tokenized CNP transactions delivers an additional $50K-$70K per year.

Total annual recovery: $3.5M to $4M of recovered revenue.

Against this, the migration costs typically include vault provider fees, orchestration platform fees if applicable, internal engineering time (typically 2-4 engineering quarters), and any PSP transition fees. For most enterprise merchants, the migration recovers its costs within the first 6-9 months and compounds in every subsequent year.

The ROI math becomes more favorable as merchant volume increases, because the per-transaction costs are largely fixed while the per-transaction lift scales linearly with volume.

Timeline expectations and resource requirements

A typical PSP-to-network-token migration for an enterprise merchant runs 12-20 weeks from kickoff to live network token routing:

Phase	Duration	Key deliverable
Pre-migration audit	2-4 weeks	Inventory, contracts reviewed, plan approved
Stage 1 (vault setup)	3-6 weeks	Vault live, certified, integrated with checkout
Stage 2 (dual-write)	2-4 weeks	New cards writing to both vaults reliably
Stage 3 (credential migration)	4-12 weeks	Existing credentials transferred and reconciled
Stage 4 (network token provisioning)	1-3 weeks	Eligible cards have active network tokens
Stage 5 (routing activation)	1-2 weeks	Live transactions routing through new infrastructure

The phases can be partially parallelized. Stage 2 and the early parts of Stage 3 typically overlap, as do Stage 4 and Stage 5. The bottleneck for most projects is Stage 3, where PSP cooperation and reconciliation requirements set the pace.

Resource requirements for a mid-market enterprise:

• Payments engineering: 2-3 engineers for the duration, plus architectural review at key checkpoints
• Security and compliance: review and approval at each stage gate
• Finance and procurement: contract review with the current PSP, vault provider, and orchestration platform
• Operations: monitoring, alerting, and on-call coverage during cutover windows
• Customer support: trained for any customer-facing edge cases during migration

For larger enterprises with multiple PSP relationships and tens of millions of credentials, double the timeline and resource estimates as a starting point.

How orchestration simplifies the migration

A payment orchestration platform with built-in vaulting and network token support compresses several of the stages significantly. Instead of integrating separately with a vault provider, a network tokenization service, and a routing layer, the merchant integrates once with the orchestration platform and the underlying components are configured rather than built.

The practical impact:

• Stage 1 (vault setup) collapses from 3-6 weeks to days of configuration, because the orchestration platform’s vault is already PCI Level 1 certified and integrated
• Stage 4 (network token provisioning) becomes a configuration toggle rather than an integration project, because the orchestration platform already maintains relationships with Visa Token Service, Mastercard MDES, and other network tokenization services
• Stage 5 (routing activation) is built-in, because routing is the orchestration platform’s core capability

Stages 2 and 3 (dual-write and credential migration) still require operational coordination with the current PSP, but the technical work happens through the orchestration platform’s existing connectors.

For a deeper view of how this works end-to-end, our overview of what a payment orchestration platform is covers the architecture, and Gr4vy’s collaboration with Mastercard details how Mastercard Merchant Cloud (network tokenization, Click to Pay, gateway services) is available directly through the orchestration platform.

Frequently asked questions

How long does a PSP-to-network-token migration take?

For an enterprise merchant with a single existing PSP and a moderate credential book, a typical migration runs 12-20 weeks end-to-end. Merchants with multiple PSPs, tens of millions of stored credentials, or complex compliance requirements should plan for 6-9 months. Merchants using an orchestration platform that has the vault and network tokenization built in can typically compress the timeline by 30-40%.

Will my customers notice the migration?

If the migration is executed properly, customers should notice nothing at all. Their stored cards continue to work, their subscriptions continue to renew, and their checkout experience is unchanged. The only customer-visible impact should be the gradual improvement in transaction success rates as network tokens reduce expired-card declines and improve authorization rates.

Can I migrate without my current PSP’s cooperation?

Partially, but not completely. For the underlying PAN data to leave the PSP’s vault, the PSP has to participate in the export process. Most major PSPs have established procedures for this, though the specific terms vary by contract. Where PSP cooperation is limited, alternative approaches (network token re-provisioning where the network can identify the underlying card, or $0 reauthorization of active customers) can recover a meaningful portion of the credential book without full PSP support.

What happens to credentials that cannot be migrated?

For dormant customers with expired or invalid cards, those credentials will fail to migrate cleanly. The standard practice is to remove them from active billing flows and treat the next customer engagement as a fresh card collection. For active customers whose cards cannot be migrated for any reason, the merchant typically prompts a card update during the next customer interaction.

Do I need to switch PSPs to migrate?

No. The migration is from PSP-locked tokens to provider-agnostic tokens, not from one PSP to another. After migration, the merchant can continue using the same PSP, add additional PSPs without re-collecting card data, or switch primary processors based on performance. The point of the migration is to gain the option, not to force a specific PSP change.

How much does a migration typically cost?

Migration costs vary significantly by merchant size and complexity. For a typical enterprise migration, the major cost components are vault and orchestration platform fees (typically priced as a percentage of transaction volume or a tiered subscription), internal engineering time (2-4 quarters of engineering capacity), and any PSP transition fees. For most enterprise merchants processing $50M+ in annual card volume, the migration recovers its costs within 6-9 months from authorization rate lift alone.

What is the rollback plan if something goes wrong?

The dual-write architecture is the rollback plan. During and immediately after the migration, the current PSP’s vault and the new vault both hold copies of the customer credentials. If a critical issue is detected, transactions can be routed back to the PSP tokens while the issue is resolved. Once the migration has been live and stable for 30-60 days, the dual-write can be wound down and the PSP-side vault becomes a true backup.

Do I need to migrate all credentials at once?

No, and most merchants do not. Batch migration (typically 10% of the credential book per week, with reconciliation between batches) is the standard pattern. This allows issues to be caught and corrected early without affecting the entire credential book. The full migration typically completes in 6-12 weeks of active credential movement.

What happens to my PCI DSS scope during migration?

PCI scope is typically reduced once the migration completes, sometimes significantly. The merchant’s environment no longer needs to be configured to handle cardholder data flowing to multiple PSP integrations; instead, cardholder data is centralized in a single PCI Level 1 vault, and the merchant interacts with tokens. During the migration itself, both the source and destination environments need to maintain PCI compliance, which is why working with a Level 1 certified destination vault is essential.

Will the migration affect my existing card-on-file authorization rates during the transition?

The migration itself should not change authorization rates during the transition, because transactions continue to flow through the existing PSP tokens until routing is activated in Stage 5. Once network tokens are live, authorization rates on tokenized CNP transactions typically lift by 2-7%, with the full benefit visible within the first 30-60 days.

Can I migrate from one PSP’s tokens to another PSP’s tokens without using network tokens?

Yes, but the migration unlocks less value. Moving from one PSP’s vault to another’s is technically possible if both PSPs cooperate, but the result is still a PSP-locked credential book, just in a different PSP. The strategic value of migration comes from moving to a provider-agnostic vault with network tokens layered on top, which is what unlocks the flexibility, authorization rate lift, and lifecycle resilience.

What if my business is too small for this migration to be worth it?

The migration ROI scales with volume. For merchants processing under $10M annually with no card-on-file or subscription billing, the return may not justify the engineering investment. The break-even point typically sits around $20-30M in annual card volume for merchants with meaningful CoF or subscription mix, and the math gets steadily more favorable above that threshold.

What to do next

The merchants who have completed PSP-to-network-token migrations consistently report that the engineering work, while substantial, was the easy part. The harder part is committing to the project in the first place, because the costs are visible upfront and the benefits compound over time.

For merchants beginning to plan this work, the practical first step is the pre-migration audit. Answer the ten questions in the section above. The answers will tell you whether the migration is worth pursuing now, what your specific timeline looks like, and where your risks concentrate.

Gr4vy’s cloud-native payment orchestration platform was designed to compress the technical phases of this migration. Through a single integration, merchants get a PCI Level 1 vault, automatic network token provisioning across Visa, Mastercard, American Express, and Discover, and routing across more than 400 PSPs and payment methods. The migration becomes a configuration project rather than a multi-vendor integration project.

If you’re evaluating whether and when to migrate, or want a walkthrough of what your specific migration would look like, contact our team for a stack audit and migration plan tailored to your current setup.