Visa's 2026 agent-initiated transactions: the 3RI authentication checklist

This guide maps Visa's agent-initiated shift to the existing 3RI rule set for merchant authentication.

It focuses on the required linkage between a prior customer-initiated 3DS and each agent-initiated transaction.

How 3RI authentication actually works

3RI stands for 3DS Requestor Initiated. According to the PayPal Braintree developer docs, 3RI allows merchants to generate authentication data for authorization by referencing details from the initial customer-initiated authentication. For the purposes of this flow, 3RI references the initial customer-initiated 3DS authentication to generate authentication data without the customer being directly involved. This is the direct linkage that makes a merchant-initiated step possible after the first customer action.

That linkage is not automatic for any order. The PayPal Braintree developer docs state that the initial customer-initiated 3DS must be authenticated for the entire amount of the order. This means the first authentication event must cover the full order value, not a partial amount. If that full-amount authentication was never completed, there is no valid record for 3RI to pull from, so the flow cannot be formed as intended.

Because the full order amount is locked to that initial authentication, fulfillment cannot be treated as one continuous authentication. The PayPal Braintree developer docs state that the merchant must then initiate separate 3RI requests for each subsequent shipment. Each of those shipments requires its own 3RI request, even though all of them are tied back to the same initial customer-initiated 3DS.

These requirements create a strict dependency between checkout and fulfillment. The merchant must know the full order amount at the time of the initial customer-initiated 3DS, and must track how many shipments remain after the first. Without both pieces in place, a 3RI request cannot be properly formed for a later shipment. This is the mechanical structure of 3RI itself, separate from any outcome it may produce.

Evidence: liability shift and auth rates

According to the PayPal Braintree developer docs, 3RI can provide a liability shift for merchant-initiated transactions. This means that, when properly executed, the responsibility for certain chargebacks can shift away from the merchant, offering a form of protection that would not exist if the transaction were left unauthenticated.

In addition, the same PayPal Braintree documentation states that 3RI may increase authorization rates for merchant-initiated transactions. While the available grounding does not provide a specific approval percentage, this documented possibility is a factor that can help offset the effort of authenticating these payments.

As noted in the PayPal developer docs, the same CAVV is currently used for the initial customer-initiated 3DS and subsequent 3RI requests. This reuse of the CAVV is what allows the subsequent requests to remain tied to the original authentication, without requiring the customer to be directly involved again.

With that said, this section alone states that 3RI provides a liability shift and may increase authorization rates, as documented by PayPal Braintree. These two documented effects are the key forms of protection for merchants looking to adapt to Visa's 2026 agent-initiated transaction shift.

Options compared: 3RI vs no authentication

When comparing options for agent-initiated transactions, Option A is 3RI authentication. According to the PayPal Braintree developer docs, 3RI provides a liability shift and may increase authorization rates. Option B is no authentication. With no authentication, there is no liability shift, higher fraud risk, and no documented authorization rate benefit.

For that reason, 3RI authentication is the winner between the two options, because it is the only option with a documented liability shift for merchant-initiated transactions.

Costs and numbers that matter

For merchants preparing for Visa's 2026 agent-initiated transaction shift, this scope rule becomes an operational check. As detailed in the "How 3RI authentication actually works" section above, the PayPal Braintree developer docs require the initial customer-initiated 3DS to be authenticated for the entire amount of the order. If an order will be fulfilled in parts, the first authentication cannot cover only the first shipment's value, or the later 3RI requests will not be supported.

That full-order coverage becomes more demanding once fulfillment is split. The same PayPal Braintree developer docs state that separate 3RI requests are required for each subsequent shipment. A split delivery cannot be handled by one 3RI call for the remaining balance. Each later shipment must trigger its own 3RI request, so the count of 3RI requests will scale directly with the number of shipments after the initial one. This is a request-count requirement, not a choice of batching.

Authentication data itself is reused rather than regenerated: as noted above, the PayPal Braintree developer docs state that the same CAVV is currently used for the initial authentication and subsequent 3RI requests. That reuse applies only to the CAVV — it does not remove the full-amount requirement at the initial customer-initiated 3DS, nor does it let a merchant consolidate separate shipments into a single 3RI request.

These are strictly scope and count requirements for the flow. Before relying on 3RI for any agent-initiated transaction, merchants must confirm their checkout can perform a customer-initiated 3DS for the entire order amount, and that their fulfillment logic can issue a separate 3RI request for each subsequent shipment. Both checks must be met, because missing either one falls outside of the conditions laid out in the PayPal Braintree developer docs for using 3RI in split-fulfillment orders.

What the evidence does NOT establish

For merchants preparing for Visa's 2026 agent-initiated transaction shift, the first necessary check is the limits of the available evidence. Based strictly on the PayPal Braintree developer documentation reviewed, the available sources does not provide specific percentages for authorization rate increases or liability shift coverage. Because of this, any projection of a fixed offset must be treated as unverified, and merchants should not rely on assumed figures when weighing the cost of authentication.

When looking at the liability shift specifically, the sources confirm the mechanism exists for merchant-initiated transactions, but they do not quantify what percentage of fraud is covered or how consistently that protection applies. The same applies to authorization rates, as the possibility of an increase is noted, but no exact percentage increase is specified. For planning purposes, this means "liability shift" and "authorization rate gains" must be treated as potential benefits to verify with an acquirer, rather than measurable amounts.

Another critical check is scope. The PayPal Braintree 3RI guidance, along with the other cited sources, covers merchant-initiated transactions generally. However, the available sources does not provide data on agent-initiated transactions specifically. While emerging activity, such as the BBVA-Visa agent-initiated transaction, shows the category is developing, there is no verified evidence isolating its performance from general merchant-initiated transactions. Merchants cannot directly transfer general results to the agent-initiated category without separate validation.

With no verified percentages or agent-specific data present, the only supported approach is a method-based one. Merchants should focus on confirming the required linkage for 3RI and documenting it for review, while treating any offset as conditional until their own acquirer can validate it against agent-initiated volume. This restraint is not a gap in strategy, but a direct reflection of what the available sources does and does not establish.

Subscription with 3RI

One concrete case is a $15 per month subscription where the first payment is charged up-front with customer-initiated 3DS and CIT, and subsequent payments use 3RI. As described in the PayPal Braintree developer docs, the customer enrolls for the $15 per month plan, and that initial charge is run with a customer-initiated 3DS for $15 followed by a customer-initiated transaction (CIT) for $15. This initial authentication is the only anchor that can be referenced for the rest of the billing cycle.

Once that anchor is in place, for subsequent monthly payments, the merchant initiates 3RI requests referencing the initial authentication. Each renewal charge is its own request tied back to that original approval, rather than treating the entire subscription as one continuous authorization. This keeps each billing cycle traceable to the customer's original action at enrollment.

To enforce that traceability, there are three checks to apply. First, ensure the initial 3DS covers the full order amount at enrollment, as the PayPal Braintree developer docs state the initial customer-initiated 3DS should be authenticated for the entire amount of the order. Second, for each subsequent billing cycle, initiate a separate 3RI request for that cycle's charge, not a single reused authorization. Third, verify the CAVV is reused correctly for each of those 3RI requests, since the PayPal Braintree developer docs note the same CAVV is used in this flow.

By holding to these checks, each renewal stays linked to the full-amount initial authentication. That link is what allows the subscription to move into the agent-initiated billing path while still keeping every cycle tied back to the original customer approval.

Decision rules for agent-initiated payments

For agent-initiated transactions, the selection between 3RI and step-up authentication begins with a single reference check. If a prior customer-initiated 3DS authentication exists for the full order amount, then use 3RI for agent-initiated transactions. This condition is not a matter of preference, but a gate, as the reference must match the full order amount to satisfy that path. Without that match, the transaction cannot be placed into the 3RI path under these rules.

If no prior customer-initiated authentication exists, then treat the transaction as high-risk and require step-up authentication. This is a required escalation, not an optional one. The absence of that reference removes the basis for 3RI, so the authentication path must shift to step-up authentication to address the higher risk profile of that agent-initiated transaction.

If the transaction is a recurring payment, then use 3RI referencing the initial authentication. As noted in the PayPal Braintree developer docs on 3RI use cases, subsequent payments in a recurring flow are intended to reference the initial customer-initiated 3DS rather than requiring a new customer-initiated authentication each time. This rule applies to recurring payments specifically, while still relying on that initial authentication as the required reference.

These are the only decision rules stated here for choosing between 3RI and step-up authentication. Merchants should enforce them at the point of selecting the authentication path for agent-initiated transactions, applying the full-order-amount check first, escalating to step-up when no prior authentication exists, and applying the initial-authentication reference for recurring payments. Each of these checks is a condition to satisfy, not a general guideline, and together they define when 3RI is used versus when step-up authentication is required.

What to do next

Frequently Asked Questions

What does the acronym 3RI stand for?

3RI stands for 3DS Requestor Initiated.

What amount must the initial customer-initiated 3DS authentication cover to enable 3RI?

The initial customer-initiated 3DS must be authenticated for the entire amount of the order.

What happens if the full-amount authentication was never completed?

If that full-amount authentication was never completed, there is no valid record for 3RI to pull from, so the flow cannot be formed as intended.

Can fulfillment be treated as one continuous authentication under this rule set?

Because the full order amount is locked to that initial authentication, fulfillment cannot be treated as one continuous authentication.

How does 3RI generate authentication data without the customer being directly involved?

3RI references the initial customer-initiated 3DS authentication to generate authentication data without the customer being directly involved.

Is the required linkage between a prior customer-initiated 3DS and agent-initiated transactions automatic for Visa's 2026 agent-initiated shift?

That linkage is not automatic for any order.

Quick answers

Also worth reading: EU Instant Payments Regulation’s October 9, 2025 payee-verification mandate: why banks and payment apps need liability-based fraud controls: EU Instant Payments Regulation’s October · instant payment fees for merchants: FedNow $0.045 vs card networks in 2026: instant payment fees for merchants: · Tap to pay fraud: Phone vs Plastic vs Chip Cut 60% Loss 2026: Tap to pay fraud: Phone