Optimize the Frictionless Rate

What is “frictionless”?

Authentication is considered “frictionless” when the cardholder’s bank approves the transaction without any interaction on the cardholder’s part (no challenge: no one-time code and no confirmation in the banking app). The bank authenticates “silently,” based on the data received and its own risk analysis (Risk-Based Authentication).

It serves two purposes:

• Better conversion: no extra steps for the carrier, so fewer dropouts.
• Liability Shift: As with successful challenge-based authentication, a successful frictionless transaction (transStatus = Y) shifts liability for fraud to the card issuer. This is what distinguishes it from a payment without 3DS.

ℹ️ The final decision always rests with the issuer bank. No approach guarantees a frictionless experience: the issuer may require verification regardless of your integration. The strategies below maximize the chances of a frictionless experience; they do not guarantee it. 

Lever 1 — Enhance authentication data

This is the most important lever. The more reliable contextual data about the user that the authentication request (3ds2/authentication) contains, the better the bank can evaluate the risk and the more likely it is to provide frictionless access. Reverse, a minimal request (amount + browser data only) deprives the bank of the information it would need to bypass the challenge.

All of the fields below are accepted by the API in both BRW and 3RI formats and are marked as “Recommended” or “Conditional” (to be submitted as soon as the information is available):

Contact information for the cardholder

Field	Role
email	cardholder’s email address (conditional: to be sent unless restricted by local regulations)
homePhone / mobilePhone / workPhone	cardholder’s phone numbers (area code [cc] + number [subscriber])
deliveryEmailAddress	delivery email (for electronic delivery)

Billing and shipping address

Field	Role
billAddrLine1/2/3, billAddrCity, billAddrPostCode, billAddrState, billAddrCountry	billing address
shipAddrLine1/2/3, shipAddrCity, shipAddrPostCode, shipAddrState, shipAddrCountry	shipping address
shipAddressUsageInd	length of time the shipping address has been in use

Customer account history

Field	Role
chAccAgeInd, chAccDate, chAccChange	the account holder’s account age and the date of the last change made to the account with the merchant
paymentAccAge, paymentAccInd	length of time the payment method has been registered
nbPurchaseAccount	number of purchases over the past six months
provisionAttemptsDay	Number of attempts to add a card in a 24-hour period
preOrderDate, preOrderPurchaseInd	pre-order information, if applicable

💡 Practical tip: Share all the reliable information you have. Inconsistent data (such as an incorrect address) is counterproductive; missing reliable data is a missed opportunity for a frictionless experience. 

Lever 2 — Run the 3DS Method

Whenever versioning allows it, always run the 3DS Method: it enables the bank to collect the technical fingerprint of the cardholder’s browser in the background, which directly feeds into its risk analysis. Skipping this step deprives the bank of information that promotes a frictionless experience. See the procedure on the BRW page.

Lever 3 — Expressing a preference and reporting exemptions

The threeDSRequestorChallengeInd field (optional, BRW flow) allows you to indicate your challenge preference to the bank and to specify that an exemption applies:

Value	Meaning
01	No preference
02	No challenge desired
03	Desired challenge (merchant’s preference)
04	Desired challenge (required)
05	No challenge — transactional risk analysis (TRA) already completed
06	No challenge — data sharing only
07	No challenge — strong customer authentication (SCA) already completed
08	No challenge — “trusted beneficiary” exemption (whitelist)
09	No challenge — invitation to whitelist if a challenge is required

⚠️ The values 05, 07 and 08 indicate that an exemption applies. Use them only if the corresponding exemption actually applies to your configuration: incorrectly declaring an exemption makes you liable and may result in a soft decline (see FAQ). If in doubt, use 01 or 02. 

The field whiteListStatus also allows you to indicate the merchant’s “trusted beneficiary” status (Y = merchant whitelisted by the cardholder, N, E, P, R, U). When a cardholder adds your merchant to their trusted list with their bank, their subsequent payments go through more smoothly and frictionless.

Lever 4 — Properly implement merchant-initiated transactions (MIT)

Once an initial CIT transaction has been authenticated, subsequent transactions initiated by the merchant (MIT) are processed via the 3RI flow and are no longer subject to strong authentication. This is one of the most direct ways to reduce friction in recurring, installment, or future payments: authenticate once (CIT), then reuse (MIT).

What’s beyond your control

Even with complete data and a requested exemption, the issuer may decide to issue a challenge (step-up). If you attempt an authorization without authentication (via exemption) and the issuer denies it, you will receive a soft decline: you must then retry the transaction with authentication. See the corresponding entry in the FAQ.