Menu

Exemption Engine (EE)

The Exemption Engine (EE) maximizes a frictionless checkout by using transactional data to predict issuer behavior. Request real-time risk analysis of transactions to exempt as many as possible fromSCA.

Prerequisite: You must be set up to use the EE with Worldpay. For more information, please contact your Relationship Manager. Additionally, please note the EE can currently only be used with aDirect Integration.

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: Exemption Engine (EE) performs the Transaction Risk Assessment (TRA) and decides if exemption can be honoured by Worldpay.

Step three: The exemption is placed in accordance with the merchant intent, or EE recommendation.

Step four: Payment is sent to authorisation with or without an exemption - depending on the EE decision.

Step five: 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 Flow

Exemption Request

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

  • CARD-SSL
  • VISA-SSL
  • ECMC-SSL

Exemption types

You must submit an additional element of <exemption> with attributes type and placement (both required). You must include placement="AUTHORISATION" or placement="AUTHENTICATION". Failure to include the type and placement results in an XML validation error.

AttributeValue
typePossible Values:
  • LV - Low value exemption (less than 30 EUR)
  • LR - Low risk exemption
  • OP - Optimised exemption (highest probability of issuer acceptance determined by the EE)
placementPossible Values:
  • AUTHORISATION- Applies exemption in authorisation flow.
  • AUTHENTICATION - Applies exemption in authentication flow.
  • OPTIMISED - Applies the exemption placement that has the highest probability of issuer acceptance as determined by the EE.

An OP exemption type results in an LV or an LR exemption, after the EE performs the Transaction Risk Analysis (TRA).

An OPTIMISED placement allows the Exemption Engine to decide the optimal placement of the exemption, either in the AUTHORISATION or AUTHENTICATION flow, based on the highest probability of issuer acceptance.

Use placement="AUTHORISATION" to place the exemption in authorisation. When the issuer accepts the exemption, the payment proceeds without any form of authentication, this exempts the shopper from a step-up challenge. If Exemption Engine rejects your exemption or finds it out of scope, your payment may automatically go to authentication. This is expected when your merchant code is subscribed to3DS FlexorWorldpay MPI.

Use placement="AUTHENTICATION" to place your exemption in authentication. We refer to an authentication with exemption as a frictionless authentication because the shopper is exempt from a step-up challenge. For the authentication flow with exemption, you must be subscribed to our 3DS Flex Product – please refer to3DS Flex Brochure.

Exemption examples with placement in AUTHORISATION

Exemption example with placement in AUTHENTICATION

Exemption request and Worldpay authentication products

The following combinations of exemption types and placements are available when subscribed to Exemption Engine.

Exemption Engine with 3DS Flex

Exemption type: LV, LR, OP
Exemption placement: AUTHORISATION, AUTHENTICATION, OPTIMISED

Note: Optimised placement will result in either Authorisation or Authentication. Should EE reject the exemption the payment will proceed to authentication or authorisation without an exemption - based on the EE instruction

Exemption Engine with Worldpay MPI

Exemption type: LV, LR, OP
Exemption placement: AUTHORISATION, OPTIMISED

Note: Optimised placement will default to Authorisation unless EE rejects the exemption. If EE rejects the exemption the payment will proceed to authentication or authorisation without an exemption - based on the EE instruction

Exemption Engine with no Worldpay authentication product

Exemption type: LV,LR, OP
Exemption placement: AUTHORISATION, OPTIMISED

Note: Optimised placement will default to Authorisation unless EE rejects the exemption. If EE rejects the exemption the payment will proceed to authorisation.

Exemption request examples

Exemption request exampleswithandwithout3DS Flex.

Examples of Exemption Engine with 3DS Flex

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

Examples of Exemption Engine with Worldpay MPI and no Worldpay authentication product

Exemption Responses

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.

FieldAttributeDescription
lastEventN/AThis field reflects either the status of the payment as AUTHORISED or REFUSED
exemptionResponseresultOne of the following values:
  • HONOURED
  • REJECTED
  • OUT_OF_SCOPE
exemptionResponsereasonOne of the following values based upon result attribute (bold)

HONOURED
  • ISSUER_HONOURED

OUT_OF_SCOPE
  • MIT
  • MOTO
  • CONTACTLESS
  • OLO

REJECTED
  • ISSUER_REJECTED
  • HIGH_RISK
  • INVALID
  • UNSUPPORTED_SCHEME
  • NOT_SUBSCRIBED
  • UNSUPPORTED_ACQUIRER
  • UNAVAILABLE
  • FRAUDSIGHT_OVERRIDE

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
  • CONTACTLESS
  • 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:

  • UNSUPPORTED_ACQUIRER
  • UNSUPPORTED_SCHEME
  • NOT_SUBSCRIBED
  • INVALID

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> where <challengePreference> is challengeRequested or challengeMandated.
  • An LV exemption request is for a transaction of a value greater than EUR 30.00

Rejection after Transaction Risk Analysis (TRA)

Exemption Engine will reject an exemption request after the TRA when the exemption request is:

ReasonDescription
HIGH_RISKExemption Engine TRA identifies the payment as high risk
INVALIDTheexemption request is invalid
UNAVAILABLEThe Exemption Engine service is unavailable
FRAUDSIGHT_OVERRIDEFraudSight risk check overrides the decision of Exemption Engine

Exemption is HONOURED

When the Exemption Engine and the card issuer honour the exemption, the response is HONOURED with the reason ISSUER_HONOURED.

When Exemption Engine honours the exemption but the issuer rejects it, 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. Please refer to our3DS Flex guidefor additional information.

If the issuer rejects an exemption applied in the authorisation, the rejection results in a soft decline. In this case, you must re-submit the payment with an authentication request in order to be authorised by the issuer. In this scenario, we advise you to authenticate without an exemption request.

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.

Example response messages

Soft decline loop

Soft decline loop is a feature of the Exemption Engine 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 Engine and 3DS Flex products
  • You have submitted 3DS Flex mandatory element of <additional3DSdata> and <session ID> in the original payment request
  • You have requested LR or LV exemption in authorisation in the original payment request
  • Payment status of the original payment is SOFT_DECLINED
  • 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.

Testing Exemption Engine

The following two sections provide information about testing the Exemption Engine in various scenarios.

When you use OP in our secure test environment, we decide the exemption type or placement based on the amount as defined in the below table:

AmountExemption TypePlacement
<=15LVAUTHORISATION
>15 <= 30LVAUTHENTICATION
>30 <= 100LRAUTHORISATION
>100LRAUTHENTICATION

Authorisation Flow

Submit the values from the magic value column in the <cardHolderName> field to test the EE in the authorization flow and receive known responses. The system returns the response data shown in the last column.

Subscribed to EE

Low Risk
Magic ValueOverviewResponse Data
EE.HON_ISSUER_HONOURED.AUTHRD
The gateway honored the exemption and the issuer authorised the payment.
Exemption: Any
Risk: Low
Path: Happy
lastEvent = AUTHORISED
result = HONOURED
reason = ISSUER_HONOURED
EE.REJ_ISSUER_REJECTED.SD
The gateway honored the exemption, but the issuer refused (soft declined) the payment.
Exemption: Any
Risk: Low
Path: Unhappy
lastEvent = REFUSED
result = REJECTED
reason = ISSUER_REJECTED
High Risk
Magic ValueOverviewResponse Data
EE.REJ_HIGH_RISK.AUTHRD
The gateway rejected the exemption for high risk, but the issuer authorized the payment.
Exemption: Any
Risk: High
Path: Happy
lastEvent = AUTHORISED
result = REJECTED
reason = HIGH_RISK
EE.REJ_HIGH_RISK.SD
The gateway rejected the exemption for high risk and the issuer refused (soft declined) the payment.
Exemption: Any
Risk: High
Path: Unhappy
lastEvent = REFUSED
result = REJECTED
reason = HIGH_RISK

Out-of-Scope Payment Types

Magic ValueOverviewResponse Data
EE.OOS_MIT.AUTHRD
The gateway excludes the exemption, because it was identified as MIT (Merchant Initiated Transaction), but the issuer authorized the payment.
Exemption: Any
Payment Type: MIT
Path: Happy
lastEvent = AUTHORISED
result = OUT_OF_SCOPE
reason = MIT
EE.OOS_OLO.SD
The gateway excludes the exemption, because it was identified as One-Leg-Out and the issuer refused (soft declined) the payment.
Exemption: Any
Payment Type: Any
Path: Unhappy
lastEvent = REFUSED
result = OUT_OF_SCOPE
reason = OLO

Incorrect Exemption Request

Magic ValueOverviewResponse Data
EE.REJ_INVALID.AUTHRD
The gateway rejected the exemption, because it was an invalid exemption, but the issuer authorized the payment.
Exemption: LV
Path: Happy
lastEvent = AUTHORISED
result = REJECTED
reason = INVALID
EE.REJ_INVALID.SD
The gateway rejected the exemption, because it was an invalid exemption and the issuer refused (soft declined) the payment.
Exemption: Any
Path: Unhappy
lastEvent = REFUSED
result = REJECTED
reason = INVALID

Not Subscribed to the Exemption Engine

Magic ValueOverviewResponse Data
EE.REJ_NOT_SUBSCRIBED.AUTHRD
The gateway rejected the exemption, because you are not subscribed to the EE, but the issuer authorized the payment.
Exemption: Any
Path: Happy
lastEvent = AUTHORISED
result = REJECTED
reason = NOT_SUBSCRIBED
EE.REJ_NOT_SUBSCRIBED.SD
The gateway rejected the exemption, because you are not subscribed to the EE, and the issuer refused (soft declined) the payment.
Exemption: Any
Path: Unhappy
lastEvent = REFUSED
result = REJECTED
reason = NOT_SUBSCRIBED

Unsupported Scheme

Magic ValueOverviewResponse Data
EE.REJ_UNSUPPTD_SCHEME.AUTHRD
The gateway rejected the exemption, because of unsupported scheme, but the issuer authorized the payment.
Exemption: Any
Path: Happy
lastEvent = AUTHORISED
result = REJECTED
reason = UNSUPPORTED_SCHEME
EE.REJ_UNSUPPTD_SCHEME.SD
The gateway rejected the exemption, because of unsupported scheme and the issuer refused (soft declined) the payment.
Exemption: Any
Path: Unhappy
lastEvent = REFUSED
result = REJECTED
reason = UNSUPPORTED_SCHEME

Authentication Flow

Submit the values from the magic value column in the <cardHolderName> field to test the EE in the authentication flow and receive known responses. The system returns the response data shown in the last column.

Subscribed to EE and Risk Management

Prerequisite: You must submit 3DS data to solicit these responses.

Successful Frictionless Authentication

Magic ValueOverviewResponse Data
EE_3DS.HON_ISSUER_HON.AUTHRD

The gateway honored the exemption and the issuer authorized the payment
Cardholder authenticatedlastEvent = AUTHORISED
result = HONOURED
reason = ISSUER_HONOURED

3SD2 Frictionless Authentication Unavailable

Magic ValueOverviewResponse Data
EE_SCA.REJ_HIGH_RISK.AUTHRD

The gateway rejected the exemption, a step-up challenge was requested and the issuer authorized the payment
Challenge requiredlastEvent = AUTHORISED
result = REJECTED
reason = HIGH_RISK
EE_SCA.REJ_ISSUER_REJ.AUTHRD

The gateway honored the exemption but the issuer rejected the exemption. A step up challenge was requested and the issuer authorized the payment
Challenge requiredlastEvent = AUTHORISED
result = REJECTED
reason = ISSUER_REJECTED
EE_SCA.REJ_INVALID.AUTHRD

The gateway rejected the exemption because it was invalid. A step up challenge was requested and the issuer authorized the payment
Challenge requiredlastEvent = AUTHORISED
result = REJECTED
reason = INVALID

Worldpay Device JavaScript Collector

To fully comply with the PSD2 mandate when performing Transaction Risk Analysis (TRA), the Exemption Engine needs to use device data within its risk decision, before applying for an exemption. While this data needs to be collected on a ‘best efforts’ basis, we strongly recommend using ThreatMetrix to collect device data as it will enable us to optimize your exemption decision, resulting in more accurate decisioning and fewer issuer soft declines.

ThreatMetrix collects and sends device fingerprint and geo-location data that relates to a shopper’s payment. You use JavaScript to send all this data to ThreatMetrix. Obtain theJavaScript toolkitfrom Worldpay.

Full Payment Request example

Copied!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd.worldpay.com/paymentService_v1.dtd" >
<paymentService version="1.4" merchantCode="YOUR_MERCHANT_CODE">
  <submit>
    <order orderCode='YOUR_ORDER_CODE'>
      <description>test order</description>
      <amount value="100" currencyCode="EUR" exponent="2"/>
      <orderContent>
        <![CDATA[]]>
      </orderContent>
      <paymentDetails>
        <CARD-SSL>
          <cardNumber>4444********1111</cardNumber>
          <expiryDate>
            <date month="06" year="2020"/>
          </expiryDate>
          <cardHolderName>Mr Bert Shopper</cardHolderName>
          <cvc>666</cvc>
          <cardAddress>
            <address>
              <firstName>Bert</firstName>
              <address1>Worldpay</address1>
              <address2>270-289 The Science Park</address2>
              <address3>Milton Road</address3>
              <postalCode>CB4 0WE</postalCode>
              <city>Cambridge</city>
              <countryCode>GB</countryCode>
            </address>
          </cardAddress>
        </CARD-SSL>
        <session shopperIPAddress="127.0.0.1" id="ssn194781884"/>
      </paymentDetails>
      <shopper>
        <shopperEmailAddress>mrbertshopper@worldpay.com</shopperEmailAddress>
        <browser>
          <acceptHeader>text/html</acceptHeader>
          <userAgentHeader>Mozilla/5.0 ...</userAgentHeader>
        </browser>
      </shopper>
      <!-- Exemption -->
      <exemption type="LV" placement="AUTHORISATION"/>
      <deviceSession>
        <sessionId>55f9c219-4e98-4130-972e-8c8b2f3c2125</sessionId>
      </deviceSession>
    </order>
  </submit>
</paymentService>

Reports

Reports are generated in the Merchant Admin Interface (MAI). Use the SCA Exemption Acceptance report to review the performance of Exemption Engine and refine your experience with us.