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 from
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 a
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 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.
| Attribute | Value |
|---|---|
type | Possible Values:
|
placement | Possible Values:
|
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 to
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 to
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 examples
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.
| Field | Attribute | Description |
|---|---|---|
| lastEvent | N/A | This field reflects either the status of the payment as AUTHORISED or REFUSED |
| exemptionResponse | result | One of the following values:
|
| exemptionResponse | reason | One of the following values based upon result attribute (bold) HONOURED
OUT_OF_SCOPE
REJECTED
|
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>ischallengeRequestedorchallengeMandated. - 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:
| Reason | Description |
|---|---|
| HIGH_RISK | Exemption Engine TRA identifies the payment as high risk |
| INVALID | The |
| UNAVAILABLE | The Exemption Engine service is unavailable |
| FRAUDSIGHT_OVERRIDE | FraudSight 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 our
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:
| Amount | Exemption Type | Placement |
|---|---|---|
| <=15 | LV | AUTHORISATION |
| >15 <= 30 | LV | AUTHENTICATION |
| >30 <= 100 | LR | AUTHORISATION |
| >100 | LR | AUTHENTICATION |
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 Value | Overview | Response 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 Value | Overview | Response 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 Value | Overview | Response 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 Value | Overview | Response 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 Value | Overview | Response 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 Value | Overview | Response 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 Value | Overview | Response Data |
|---|---|---|
| EE_3DS.HON_ISSUER_HON.AUTHRD The gateway honored the exemption and the issuer authorized the payment | Cardholder authenticated | lastEvent = AUTHORISED result = HONOURED reason = ISSUER_HONOURED |
3SD2 Frictionless Authentication Unavailable
| Magic Value | Overview | Response 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 required | lastEvent = 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 required | lastEvent = 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 required | lastEvent = 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 the
Full Payment Request example
<?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><?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.
