Exemption Management

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
It is important to know that in case an exemption is requested:
  • 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.

Liability shift

  • If the transaction goes to 3D Secure with the exemption request in place: Liability is with the issuer.
  • If the 3D Secure is skipped, and the transaction goes straight to the acquirer with the exemption flag: Liability is with the merchant.

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:

  1. 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.
  2. The gateway can automatically retry the transaction.
If the transaction is retried after a soft decline, the 3D Secure authentication will always end up with a challenge flow for the customer.

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