Merchant-initiated 3RI is a card-not-present transaction where the merchant starts a 3DS request without the cardholder present. It is used for stored credentials, recurring payments, or delayed charges, and the issuer may rely on prior customer authentication or other risk signals instead of a live challenge.
How Merchant-Initiated 3RI Works
Merchant-initiated 3RI is a 3-D Secure flow where the merchant, not the cardholder, starts the request for an authentication decision. That makes it a useful pattern for recurring billing, stored credentials, and delayed capture, because the issuer can assess context from prior authentication, transaction history, and other risk signals instead of forcing an interactive step every time.
In practice, the key difference is that the customer is absent at the moment the request is initiated. The merchant therefore has to present the transaction as a valid merchant-triggered event, rather than a fresh cardholder-authenticated purchase. That distinction matters because the issuer and payment ecosystem may treat it differently for fraud scoring, challenge logic, and liability outcomes.
Where 3RI Fits in Card-Not-Present Payments
3RI sits inside the broader 3-D Secure payment ecosystem as a protocol path for non-present transactions that still need an issuer authentication decision. It is commonly associated with subscriptions, top-ups, instalments, and other payment models where the merchant has a legitimate reason to complete a charge after the first customer interaction.
This model helps payment flows stay usable without weakening the authentication framework. It is not a shortcut around authentication so much as a different way of expressing a transaction that was already authorised by the customer relationship, the stored payment arrangement, or a prior authenticated event. The merchant still has to preserve the required transaction context and request metadata so the issuer can make an informed decision.
Security and Trust Implications
Because 3RI relies on contextual trust rather than an interactive challenge, its security depends on strong merchant controls around stored credentials, request integrity, and transaction classification. If those inputs are inaccurate or tampered with, the issuer may receive a misleading picture of the payment and either over-trust a risky charge or disrupt a legitimate one.
The main security value is that 3RI can reduce friction while preserving an authentication trail across repeat payments. The main security trade-off is that the merchant becomes more responsible for correctly representing why the transaction is being initiated and for ensuring that stored payment arrangements were originally established under proper customer consent.
NIST SP 800-53 Rev 5 Security and Privacy Controls
Operational Checks for Merchants and Payment Teams
Teams implementing 3RI should validate that their payment platform can distinguish initial cardholder-initiated authentication from later merchant-initiated requests, and that the correct fields are populated consistently. The practical challenge is often not the protocol itself, but the business process around when a charge is allowed to proceed without a live customer step.
That means aligning billing, fraud, customer support, and engineering on what qualifies as a stored-credential event, a recurring charge, or a delayed submission. When that classification is loose, 3RI can become a source of failed transactions, issuer confusion, or inconsistent fraud treatment rather than a reliability improvement.
Risk and Threat Considerations
Merchant-initiated 3RI creates risk where the merchant is trusted to start a payment on behalf of the cardholder. If an attacker compromises the merchant environment, payment workflow, or stored-credential process, they may be able to submit charges that look structurally legitimate even when the customer did not initiate them.
Failure mechanism: Weak transaction classification, compromised merchant systems, or abused stored-payment arrangements can cause the issuer to receive a request that appears valid enough to bypass a live challenge or reduce scrutiny.
Impact: The result can be unauthorised billing, dispute exposure, customer trust loss, and broader abuse of the merchant’s payment relationship, especially where recurring or delayed-charge logic is widely used.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | 3RI depends on controlling the credentials and tokens behind stored payment credentials. |
| AC-6 — Least Privilege | 3RI merchant systems should only initiate approved payment actions and related access. | |
| AU-2 — Event Logging | 3RI requires transaction records that support fraud review and dispute investigation. | |
| Recommendation — Apply IA-5 to govern how payment credentials and related authenticators are issued, stored, rotated, and revoked. Enforce AC-6 so only tightly scoped systems and roles can initiate or approve merchant-initiated charges. Log 3RI initiation, decision, and exception events so payment activity can be reconstructed during review. | ||
| CIS Controls v8 | 5 — Account Management | Stored-credential payments rely on controlled account and entitlement lifecycle handling. |
| Recommendation — Manage payment-related accounts and service access so stored-credential workflows remain authorised and reviewable. | ||
| OWASP ASVS | V10 — OAuth and OIDC | 3RI is part of a payment authentication flow that depends on correct trust and token handling. |
| Recommendation — Validate authentication-flow handling so payment requests and return messages are bound to the correct transaction context. | ||
Practitioner Guidance
Governance implication: Treat 3RI as a controlled payment capability, not just a technical flag in the checkout stack. Ownership should span payments, fraud, and engineering so the organisation can decide which transaction types are permitted, what evidence supports them, and how exceptions are reviewed.
What to watch for: Pay close attention to failed issuer responses, unusual retry patterns, and disputes on transactions that should have been routine. Those signals often indicate classification problems, consent problems, or abuse of stored-credential flows rather than a simple payment decline.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org