The information provided on this page is relevant for both:

• Merchants with a backend-to-backend integration using PXP Financial's 3DS Server
• Merchants using the PXP Financial Checkout (Hosted Payment Pages)

Process Overview

After performing SCA for a card payment (3DS check) the next step to complete the payment is to complete the authorisation.

This can be done :

• By the merchant system, sending an authorise request (executePaymentActionRequest with actionID=120).
• Automatically by PXP Financial (if configured for the merchant).

Even in some situations where the 3DS check was not successful, it is possible to continue with authorisation, but with the impact that the liability shifts from the issuer to the merchant.

🚧

Note: PSD2 rules must be followed

PSD2 stipulates either using an exemption or performing SCA successfully for in-scope transactions. If an authorisation policy is selected which results in payments being submitted into authorisation without an exemption, this will most likely lead to a soft-decline.

For MasterCard in particular this can cause a compliance issue. Please ensure your integration makes use of exemptions correctly, especially if Policy IDs 1 to 3 from the below table are used.

To support the different configuration options, PXP Financial offers certain 3DS Authorisation Policies:

Default Configuration for Backend2Backend merchants

By default, policy 7: "Never automatically continue with authorisation", is configured for a backend-to-backend merchant.

This means that the merchant system needs to trigger the authorisation after completing SCA by sending an authorise request (executePaymentActionRequest with actionID=120).

Default Configuration for a Checkout merchant

By default, policy 1: "Continue with authorisation in all scenarios where possible and recommended", is configured for a merchant using the PXP Financial Hosted Payment Pages.

The merchant system need not do anything. PXP Financial will automatically continue with authorisation after the 3DS check was done.

📘

Change the default configuration

To set up a different default policy for a merchant/shop, please contact [email protected].

❗️

Liability Shift

Merchants should be aware that in all cases where the authentication was not done successfully, the liability shifts to the merchant in case the following authorisation will be successful.

Of course, if the authentication was successful or there was a technical error on the issuer-side (ACS), the liability remains with the Issuer. This is the case in the following payment states:

• UserAuthenticationSuccessful
• UserVerificationPassed

Override default 3DS Authorisation Policy on request

As already mentioned, for every merchant there will be a configured default 3DS Authorisation Policy. This policy will be applied for all card transactions.

To override this default configuration for a particular payment, a 3DS Authorisation Policy ID can be sent in the initiatePayment or getRedirectData request.

• initiatePayment.specificPaymentData (backend2backend integration): parameter ThreeDSecureAuthorisationPolicyID
• getRedirectData.additionalData (Checkout integration): parameter ThreeDSecureAuthorisationPolicyID

Version History