3DS Authorisation Policies

The information provided on this page is relevant for

merchants with backend2backend integration using PXP Financials MPI for 3D Secure
merchants using the PXP Financial Checkout (Hosted Payment Pages)

After the authentication step for a card payment (3DS check) was done successfully the next step to complete the payment is to do the authorisation.
This can be done

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

Even in some situations where the 3DS check was not successfully done, it is possible to continue with authorisation, but with the impact that the liability shifts from the issuer to the merchant.
To continue with authorisation in such a case, this can be done again either by the merchant system per request or automatically by PXP Financial system (if configured for the merchant).

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

Policy ID	Scenario	Related states for 3DS 2.0	Related states for 3DS 1.0
1	Continue with authorisation in case of a successful 3DS Authentication and in all failure/error scenarios where it is possible and recommended.	UserAuthenticationSuccessful (and no challenge required) UserVerificationPassed UserAuthenticationErrorOccurred UserAuthenticationFailed UserVerificationErrorOccurred UserVerificationFailed	AuthenticatedByThreeDSecure AuthenticateByThreeDSecureAttemptsPerformed NotEnrolledInThreeDSecure NotEnrolledInThreeDSecureADSAvailable VerifyThreeDSecureEnrollmentErrorReported VerifyThreeDSecureEnrollmentErrorOccurred AuthenticateByThreeDSecureFailed
2	Continue with authorisation in case of a successful 3DS Authentication and if an error or failure during user authentication occurred.	UserAuthenticationSuccessful (and no challenge required) UserVerificationPassed UserAuthenticationErrorOccurred UserAuthenticationFailed	AuthenticatedByThreeDSecure AuthenticateByThreeDSecureAttemptsPerformed NotEnrolledInThreeDSecure NotEnrolledInThreeDSecureADSAvailable AuthenticateByThreeDSecureFailed
3	Continue with authorisation in case of a successful 3DS Authentication and if an error or failure during user verification occurred.	UserAuthenticationSuccessful (and no challenge required) UserVerificationPassed UserVerificationErrorOccurred UserVerificationFailed	AuthenticatedByThreeDSecure AuthenticateByThreeDSecureAttemptsPerformed NotEnrolledInThreeDSecure NotEnrolledInThreeDSecureADSAvailable VerifyThreeDSecureEnrollmentErrorReported VerifyThreeDSecureEnrollmentErrorOccurred
4	Continue with authorisation in case of a successful 3DS Authentication and in case an error occurred during user authentication or user verification - due to a technical or other issue at the scheme's directory server.	UserAuthenticationSuccessful (and no challenge required) UserVerificationPassed UserAuthenticationErrorOccurred UserVerificationErrorOccurred	AuthenticatedByThreeDSecure AuthenticateByThreeDSecureAttemptsPerformed NotEnrolledInThreeDSecure NotEnrolledInThreeDSecureADSAvailable VerifyThreeDSecureEnrollmentErrorReported VerifyThreeDSecureEnrollmentErrorOccurred
5	Continue with authorisation in case of a successful 3DS Authentication and in case a failure occurred during user authentication or user verification.	UserAuthenticationSuccessful (and no challenge required) UserVerificationPassed UserAuthenticationFailed UserVerificationFailed	AuthenticatedByThreeDSecure AuthenticateByThreeDSecureAttemptsPerformed NotEnrolledInThreeDSecure NotEnrolledInThreeDSecureADSAvailable
6	Continue with authorisation only in case of a successful 3DS Authentication.	UserAuthenticationSuccessful (and no challenge required) UserVerificationPassed	AuthenticatedByThreeDSecure AuthenticateByThreeDSecureAttemptsPerformed
7	Never automatically continue with authorisation - only on merchant request (usually only applicable for backend2backend merchants).	n/a	n/a
8	Continue with authorisation only in case of a successful 3DS Authentication or if the Card is not enrolled in 3DS.	UserAuthenticationSuccessful (and no challenge required) UserVerificationPassed	AuthenticatedByThreeDSecure AuthenticateByThreeDSecureAttemptsPerformed NotEnrolledInThreeDSecure NotEnrolledInThreeDSecureADSAvailable

Default Configuration for Backend2Backend merchants

By default policy 7 "Never automatically continue with authorisation" is configured for a backend2backend merchant.
The merchant system needs to trigger the authorisation after the 3DS check was done 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 system will continue with authorisation after the 3DS check was done automatically.

📘
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.
Only in case of 3DS 1.0 state "NotEnrolledInThreeDSecure" the liability remains with the Issuer.
Of course, if the authentication was successful, the liability is always with the Issuer. This is the case in those success-states of the 3DS process:

UserAuthenticationSuccessful (3DS 2.0)

UserVerificationPassed (3DS 2.0)

AuthenticatedByThreeDSecure (3DS 1.0)

AuthenticateByThreeDSecureAttemptsPerformed (3DS 1.0)

Override default 3DS Authorisation Policy on request

As already mentioned, for every merchant there will be a default 3DS Authorisation Policy configured in PXP Financials backend. 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