How and when to retry SCA-related soft-declined transactions

Strong Customer Authentication (SCA) has been rolled out across the European Economic Area (EEA) and the UK. And, as such, merchants will likely encounter more soft declines for transactions presented without SCA.

This article explains how SCA compliant and non-compliant transactions are defined and how merchants using Checkout.com retry SCA-related soft declines.

Find out more about Checkout.com's authentication solution.

Which transactions require strong customer authentication?

All electronic transactions require SCA unless the transaction is out of scope or there’s an exemption applied.

As a reminder, the main out-of-scope scenarios for remote transactions include:

• Merchant initiated transactions (MITs): These are a large group of transactions, comprising installment payments, recurring transactions, delayed charges, no-show transactions, reauthorizations, among others. SCA may be required to set up such arrangements, mainly if initiated through a remote channel. However, once in place, merchants may initiate subsequent payments without applying SCA requirements.
• Mail order/telephone order: Payments made by mail order or over the phone fall outside the scope of SCA.
• One leg out: When either the card issuer, acquirer or both are outside the EEA. For example, when a card issued in Japan is used at the website of a German merchant.
• Anonymous transactions: For example, prepaid gift cards issued without an identifiable cardholder name.

The main exemptions for remote transactions include:

• Transaction risk analysis (TRA): TRA exemptions may be applied to transactions deemed as low risk by merchants or on behalf of merchants by their PSPs that have low fraud rates due to their measures that ensure the safety of the payment service user's funds and personal data.
• Low-value transactions: These are transactions up to €30, or equivalent in the processing currency, with a cumulative limit of €100 or five consecutive transactions.
• Trusted beneficiary: This is also sometimes known as whitelisting. This is where the cardholder adds the payee to a list of trusted beneficiaries held by their issuer.

To reiterate: SCA is not required for transactions that are out of scope or exempt. But these transactions must be correctly flagged in the authorization message to reduce the chance of issuers soft declining them.

Also, keep in mind that issuers have the final say about whether to apply SCA. There are things that only they can know or do. For example, understanding the customer’s typical spending patterns or which merchants are listed as trusted beneficiaries.

If issuers are suspicious about a transaction, they can always request a step-up or challenge authentication via 3DS, even if it’s been flagged as out of scope or exempt from SCA.

Initiating SCA retries using Checkout.com

While merchants should do what they can to prevent customers from encountering soft declines, they will happen, especially during the ramp-up period. At Checkout.com, we've made it easy for merchants to retry soft-declined transactions by following these steps:

1. If a transaction requires SCA because the authorization wasn’t preceded by authentication, the issuer should respond with a soft decline response code 20154.
2. Merchants should then retry with EMV 3DS (3DS2) and ideally use a challenge indicator SCA mandated (04) or 3DS1 if EMV 3DS isn’t supported by either the merchant or the issuer.
3. If the authentication is successful, merchants may proceed with another authorization with 3DS data and the issuer should accept a fully authenticated authorization.

Note: Issuers should not apply soft decline for other reasons than when SCA is required.

See our docs page for more information.

Understanding system integrity rules

When planning their resubmission strategies, merchants must consider the system integrity rules applied by the schemes that came into force in April 2021. These rules group pre-existing decline response codes into categories and require issuers to use descriptive values when they cannot approve a transaction.

Merchants can break the system integrity rules by incorrectly submitting retries or making an excessive number of retries and these can lead to fines issued to merchants by the schemes.  

Here's an overview of the rules set by the schemes.

Issuer will never approve – retry not allowed

'Issuer will never approve' category decline codes indicate that there are no circumstances in which the issuer will approve the transaction. Examples include the card being compromised or never in fact issued.

This category also includes decline codes that indicate the account is valid but that the transaction is not permitted due to permanent regulatory restrictions that prevent approval.

Merchants should never resubmit a transaction when they receive a response code from this category.

Issuer cannot approve at this time – retry allowed

'Issuer cannot approve' at this time category decline codes indicate that the issuer may approve but cannot do so at this time. Examples include a temporary system outage, lack of funds or that SCA is required. These occur when the issuer is prepared to approve a transaction but cannot do so at the time or based on the transaction details. In some cases, cardholder action is required to remove the restriction before approval can be obtained.

The issuer would welcome a further authorization attempt in the future but limited to 15 resubmissions in 30 days.

Data quality, issuer cannot approve with these transaction details – retry allowed with valid data

Merchants can submit a retry when they receive decline codes from issuers that indicate there are data quality issues and that either invalid payment or authentication data has been provided. The issuer may approve the transaction if the merchant then provides valid data.

Merchants can be charged twice the system integrity fees in the case of data quality category decline response code resubmissions if the following applies:

• Merchants make over 15 retries using the same CAID, PAN and purchase amount over a 30-day period.
• Over 25,000 declines with the same CAID and Acquirer BIN are made.

Best practices for automatic retries

As merchants consider these rules and work with their PSPs to build their SCA resubmission strategies, some best practices to follow are:

• Ensure that any automated authorization retries exclude 'Issuer will never approve' category response codes.
• Not retry 'Issuer cannot approve at this time and/or with this data category' more than 15 times over a 30-day period.
• Apply SCA and use account verification transactions when adding credentials on file.
• Evaluate the use of automated customer messaging, alerts or emails when receiving successive declines or the retries threshold is reached for transactions with credentials on file.
• Utilize velocity of spend controls to reduce the risk of account testing and apply captcha-like solutions to mitigate bots that retry transactions continuously.

What are the early lessons from the SCA rollout across the EEA?

Overall, the early signs are that the SCA rules are helping to reduce fraud. Card schemes have reported a reduction in fraudulent activity during early 2021. And it’s encouraging to see this happening with minimum impact on merchant payment performance.

Soft declines are increasing as expected, as are soft decline resubmissions. The sooner merchants adopt 3DS2, the sooner they can learn where soft declines are occurring. And the sooner they can hone robust SCA exception strategies to optimize payment performance and deliver a seamless but secure customer experience.

Contact our team today to see how we can support your business.