Exemption Management
Exemptions are particular transactions that can be exempted from SCA, and they don't necessarily need explicit cardholder authentication. In a simpler way: they can be either authorized without previous authentication, or they will go through a frictionless flow during authentication which means the cardholder doesn't have to authenticate themselves with the issuer.
These exemptions are transactions which are:
- Low value
- Low risk
- Between cardholder and merchant, where the cardholder white-listed the merchant as a 'trusted beneficiary'
- Made with a corporate card
- The issuer has the power to override the exemption request.
- Some acquirers may not allow certain exemptions for their merchants. Merchants should consult with their acquirers to which extent can they use the exemption flags.
How it works
Exemptions can be easily requested by sending the appropriate value in the threeDSecure.exemptionFlag field.
| Value | Exemption |
|---|---|
| 01 | Low value exemption |
| 02 | TRA exemption |
| 03 | Trusted beneficiary exemption |
| 04 | Corporate card payment exemption |
Exemption mangement can be automated using the built-in Exemption Engine. It can determine whether the transaction is applicable for an exemption, based on the customer configured rules. The engine will then automatically apply the exemption flag, so the merchant doesn't have to send any additional value in the request. The Exemption Engine can be utilized in two ways:
- During payment: The eligibility of an exemption will be checked and the necessary flags will be automatically added to the payment request sent to the acquirer.
- As a standalone service: You can send a standalone request without a payment. The response will indicate which exemption is applicable.The request is sent to the Exemption Engine which determines whether the transaction is applicable for an exemption, based on the configured rules in the engine. If the transaction is valid for an exemption, the exemption flag is returned in the response under resultDetails in "RiskRuleCategory" with a prefix "SCAEX_".
This flag then can be used in the payment request in the field threeDSecure.exemptionFlag
Soft declines
If the exemption is requested via authorization, meaning that the 3D Secure call is skipped, the acquirer has the option to reject the exemption request. In this case the acquirer will 'soft decline' the transaction, which is indicated with the return code 300.100.100. The correct action to take is to re-send the transaction to 3D Secure authentication and after that to authorization with the authentication result.
A soft decline can happen even if there was 3D Secure performed. For example if a 3D Secure request ends up in a frictionless authentication, but a challenge was mandated. In this case the correct action is to re-send the transaction to 3D Secure authentication.
The merchant has 2 options handling the soft decline:
- The gateway can return the soft decline code, and let the merchant handle the workflow as they wish. The merchant can either handle it as a decline, or manually re-send the transaction. In the latter case it is important to include the challengeIndicator=04 field in the request.
- The gateway can automatically retry the transaction.
Out of scope transactions
A certain group of transactions is out of scope from Strong Customer Authentication (SCA). This means, that these transactions can be sent to authorization directly and they will not be declined by the acquirer or the issuer with a soft decline. In order for a transaction to qualify as out of scope it is crucial to mark the transaction with the proper flags.
| Transaction type | How to flag |
|---|---|
| Mail order or telephone order | Set the field transactionCategory to 'MO' or 'TO' |
| Recurring transactions | Set the field recurringType to REPEATED. This only applies for merchant initiated transactions (MIT), eg. subscription agreement between consumer and merchant. |
| Merchant Initiated Transactions | Set the field standingInstruction.source=MIT |