FAQ – 3DS 2.2

Estimated reading: 3 minutes

Selecting a flow

Should I use the BRW feed or the 3RI feed?

The criterion is who initiates the transaction and if the cardholder is present, not the order of the transaction:

BRW → customer-initiated transaction (CIT), where the cardholder is present and authorizes the payment personally. Use this for the initial authentication of a card as well as for any payment where the customer is present during the transaction.
3RI → merchant-initiated transaction (MIT), with the cardholder absent, based on a previously authenticated CIT (referenced via threeDSReqPriorRef).

See the section overview and the MIT page.

Can I use the BRW feed for my recurring or Merchant-initiated transactions?

No. The BRW assumes that both a browser and a cardholder are present. Using it for MITs results in unnecessary friction, soft declines, and PSD2 non-compliance. For these transactions, use the 3RI, which relies on the acsTransID from the initial CIT. However, an MIT may, in exceptional cases, be reclassified as a CIT by the issuer; in this case, reprocess a CIT (BRW) with the cardholder.

Test environment

Are there any test cards for 3DS2 transactions in a Sandbox environment?

👉 View the list of test maps for the RCT environment.

3DS authentication errors and statuses

My versioning is returning a 404 error: “Card account number not found in card ranges from Directory Server.” What should I do?

The card being used is not enrolled in 3DS 2.2: the transaction cannot be processed using 3DS 2.2. We recommend switching to a 3DS1 payment for this type of card.

The Result query returns ” transStatus = U.” How should this be interpreted?

The value U means that authentication/verification could not be completed (due to a technical issue or other problem).

Regarding SmartForm: during the challenge, only the values Y and A pass the challenge and allow the payment to proceed. Any other values cause the challenge and the payment to fail.
Regarding CustomForm : the behavior may vary. You can use the value U to retry a challenge; if it fails again, switch to 3DS1, or treat the payment as declined. These different handling options are possible.

SmartForm vs. CustomForm : SmartForm is the payment page hosted by

After submitting the form toacsURL, the customer returns without a CRES but with a ” ERROR ” (base64) parameter and an empty ” THREEDSSESSIONDATA.” What should be done?

Verify that your entire 3DS2 process takes place on a single page using the iframe solution. If the process is compliant, contact technical support with the necessary information.

ℹ️ As a reminder, all steps of the form are completed on a single page, without being redirected to a bank page or any other page, thanks to the iframe solution.

Error 303: “acquirerBIN, acquirerMerchantID not recognized” during authentication. What should I do?

This is either a contract that is not 3DS2 or another issue. In the second case, contact technical support and provide the electronic payment contract number (if known) and any other relevant information.

Error 203: “Validation of 3DS Requestor Authentication data failed […]” for the “ merchant.merchantName ” field. What does this mean?

Error 203 indicates an invalid character in parameter merchant.merchantName.

“There is no unique source of card” error in the key ` card data`. What does this mean?

This error, which is common across the entire platform, happens when you send card information twice: for example a cardToken and a cardId, or a PAN and a cardToken. Send only one set of card information.

Bank Authorization

The transaction API returns “Soft Decline,” even though ” threeDSServerTransID ” is indeed the status returned by CRES. What should I do?

The bank returns a “soft decline” (code A1) when 3DS is not included in the transaction. Verify that no 3ds[...] fields are missing — see the data to be transmitted on the BRW page, under the “Transaction” step.

Bank return codes 5 and 12 (excluding 3DS)

These codes come from the bank authorization and are not specific to 3DS.

Code 5: The bank declines the transaction without providing a specific reason (incorrect CVV or another reason we are unaware of). This status does not indicate that the bank will decline authorization after further attempts.
Code 12: The bank declines the transaction without providing a specific status. Possible causes: invalid transaction; incorrect or invalid CAVV (the CAVV is the authentication code provided by the ACS during 3DS; not to be confused with the CVV); or another reason unknown to us.