SCA Exemption Control

Request exemption from Strong Customer Authentication (SCA).

Prerequisite: Before using exemption control (EC), please contact your Relationship Manager. You must have a Transaction Risk Analysis (TRA) system that isRegulatory Technical Standards (RTS)compliant forPayment Services Directive 2 (PSD2).

On this page:

Exemption flow

The exemption request follows a defined flow.

Step one: The request is validated to ensure that payment is in scope of SCA and the exemption can be supported.

Step two: The exemption is placed in accordance with your intent.

Step three: Payment is sent to authorisation. Payments that are not exempt will be authenticated if you participate in 3DS.

Step four: You or Worldpay can re-submit soft declined payments for authentication without an exemption. You need to be able to identify the soft declines and re-submit the payment for authentication as a new order.

Exemption control flow

Exemption request

You can request an exemption for the following three paymentMethodMask values:


Exemption types

You must submit an additional element of <exemption> with attributes type and placement (both required). Failure to include this attribute results in an XML validation error.

typeLVLow value exemption (less than 30 EUR).
typeLRLow risk exemption.

You can request 2 different placement options:

ValueTransaction typeDescription
Exemption request in authorisation flowIf the exemption is accepted by the issuer, the payment is authorised without any authentication.
AUTHENTICATIONExemption request in authentication flow.You must be enabled for3DS Flex, since you must send the additional 3DS data. If the exemption is accepted by the issuer, the authentication is frictionless.

Exemption request examples

Examples of Exemption Control with 3DS Flex:

Note: To request an exemption in Authentication, use noPreference or noChallengeRequested in <additional3DSData> - challengePreference.

Examples of Exemption Control with Worldpay MPI and no Worldpay authentication product:

Exemption response

The response message contains information about the exemption result, type of exemption (if applied), and outcome. The table below explains the various fields and attributes associated with the exemption response message.

<lastEvent>N/AStatus of the payment is AUTHORISED or REFUSED
<exemptionResponse>resultOne of the following values:
<exemptionResponse>reasonOne of the following values based upon result attribute (bold)

  • MIT
  • OLO
  • MOTO


Exemption rejected at the initial validation

Exemption can be rejected in the initial validation step. The exemption result is OUT_OF_SCOPE if the payment is:

  • MOTO
  • MIT
  • One Leg Out (OLO)

Mail order/Telephone Order, card-present CONTACTLESS and Merchant Initiated transactions do not requires Strong Customer Authentication (SCA).

If either the issuer or acquirer are outside of the EEA the payment is out of scope of SCA. For these payment types an exemption is not required.

The exemption result is REJECTED when the following reasons apply:


Note: Not all acquirers and schemes are supported by Exemption Engine. Ask Your Worldpay Relationship Manager or Support team for the latest on supported acquirers and schemes.

If you are not subscribed to an SCA exemption product and you submit an exemption, the exemption will be rejected.

Exemption request is invalid

  • An exemption with AUTHENTICATION placement is requested for a payment without <3DSData> provided
  • An exemption is requested for a payment with <3DSData> whereis challengeRequested or challengeMandated
  • An LV exemption request is for a transaction of a value greater than EUR 30.00

Exemption rejected as high risk

When a payment is rejected by a fraud tool, the exemption will be rejected as HIGH_RISK.

Payment requests with a rejected exemption proceed to authorisation with or without authentication, depending on your subscription to Worldpay's authentication products:

  • If you're subscribed to 3DS Flex and provide additional3DSData the payment is authenticated and authorised.
  • If you're subscribed to the Worldpay MPI and provide 3DS data in the XML request, payment will be authenticated and authorised.
  • If you are not participating in 3DS your payment will proceed to authorisation without exemption.
  • Exemption is honored

    When the card issuer honours the exemption, the response is HONOURED with the reason ISSUER_HONOURED.

    When the card issuer rejects the exemption, the exemption result will be REJECTED with the reason ISSUER_REJECTED.

    When the issuer rejects an exemption applied in the authentication, the rejection results in a challenge request from the issuer. This is signalled in the response message by the element <challengeRequired>. If you are presented with this result you must follow the 3DS Flex challenge flow. See the3DS Flex guidefor additional information. Payment continues to authorisation without an exemption, after the completed challenge.

    If the issuer rejects an exemption applied in the authorisation, the rejection results in a soft decline.

    Example response messages

    Identifying soft declines

    Worldpay returns a <lastEvent> value of REFUSED. Additionally, we are sending an element of <ISO8583ReturnCode> with attributes code="65" and description="AUTHENTICATION REQUESTED".

    Note: You must have extended response codes enabled to identify soft declines.

    Soft decline loop

    Soft decline loop is a feature of the Exemption Control product. The eligible soft declined transactions are re-processed and authenticated automatically under the same Order Code. You can expect the soft decline loop to take place when:

    • You are subscribed to Exemption Control and 3DS Flex products
    • You have submitted 3DS Flex mandatory element of <additional3DSdata> and <session ID> in the original payment request
    • Payment status of the original payment is SOFT_DECLINED
    • You requested LR or LV exemption in authorisation on the original payment request
    • The original payment is not One Leg Out (OLO)

    The XML response to the original payment that contains a <lastEvent> value of REFUSED and an element of <ISO8583ReturnCode> with attributes code="65" and description="AUTHENTICATION REQUESTED" is not returned when the soft decline loop is triggered. You can expect the final XML response with a <lastEvent> value of AUTHORISED or REFUSED once the soft decline loop transaction has completed.

    Contact your Relationship Manager for further details, and to have the soft decline loop feature enabled.