PSD 2 Implementation Guideline

📘

Document in progress

This document will be updated as more information becomes available. Please ensure to revisit this page regularly.

Introduction

This page will describe PXP Financial's API framework for Payment Service Directive 2 (PSD2) compliance. Currently the instructions below apply to Visa, MasterCard (including Maestro), Amex and Diners only.

The information in this document is supplemented by the following resources:

PXP Financial PSD2 API Overview

With the PXP Financial PSD2 API extensions you can:

  • Override the default or configured Policy behaviour
  • Submit exemptions for application in either Authorisation or Authentication
  • Submit information to be used for specific payment use-cases such as follow-up recurring payments

Note, a typical initiatePayment or getRedirectData request should also include the standard fields for 3DS1 and/or 3DS2 authentication if SCA is going to be performed.

This section provides more details on how to make use of these API extensions.

📘

Backend2Backend vs. Redirect (Checkout) API

The PXP Financial PSD2 API extensions are available for both integration options:

  • Backend2Backend - using initiatePayment request
  • Redirect (Checkout/Hosted Payment Pages) - using getRedirectData request

❗️

Define your PSD2 approach

PXP Financial recommends to use the API fields only if you have an extensive knowledge of PSD2 SCA regulations and the 3-D Secure protocol and are familiar with our Policy Framework.

Refer to the Merchant Decisions and Actions of our PSD2 Support Page for guidance.

👍

PSD2 Implementation Checklist: Overview

  • Contact PXP Financial Support if you require specific Policy behaviour to be configured using a Policy other than the default Policy
  • Support 3DS1 at a minimum for SCA requirements: Card Deposits with 3DS
  • Support 3DS2 to take advantage of the enhanced capabilities and benefits which are tailored for 3DS2: 3DS 2.0 Information Hub
  • Ensure you have extended your system to take advantage of exemptions and out-of-scope PSD2 cases using the information in this Guide
  • Ensure that your are prepared to handle a soft-decline response to a card payment and perform the relevant follow-up steps
  • Optionally submit the PSD2 fields in the Payments.SpecificPaymentData section of the initiatePayment request or in the additionalData section of the getRedirectData request in order to control your SCA requirements on a per-transaction level

Default SCA behaviour with new API fields

The initiatePayment and getRedirectData request have been extended with new fields applicable to PSD2.

Merchants will need to send these fields in addition to those that they usually send in order to meet SCA requirements.

Exemption Flagging

The table below lists the additional fields that should be sent in initiatePayment or getRedirectData request to support exemption and out-of-scope handling by using the default Policy provided by PXP Financial. All fields should be provided in initiatePaymentRequest.specificPaymentData or getRedirectDataRequest.additionalData.

Field

Description

Values

ScaPolicyID

Indicates the Policy type that the merchant wants to apply for the particular transaction.
If a value is supplied, this will override the default or merchant-configured Policy.

Do not set this value. The Default policy will be used - Check here for Policy descriptions.

ScaChallengeIndicator

Indicates the merchant's preference for a challenge for the particular transaction.

Do not set this value

ScaExemptionID

Indicates the exemption type that the merchant wants to request for the particular transaction.

Specify No Exemption if you wish to have all your transactions undergo SCA.

The Secure Corporate Card, White-listed merchant/Trusted Beneficiary, and Transaction Risk Analysis exemptions must be flagged even for the default Policy. The Low Value Transaction exemption is the only exemption that is applied automatically by default.

3 - No Exemption
4 - Secure Corporate Card
5 - White-listed merchant/Trusted Beneficiary
6 - Transaction Risk Analysis (TRA)

Note: 5 is not allowed for Amex and Diners.
6 is not allowed for Amex.

ScaExemptionFlowId

Indicates at which stage the merchant wishes the exemption to be applied.

Possible values:
1 - authentication - The exemption will be applied during SCA

2 - authorisation - The exemption will be applied directly in authorisation, bypassing SCA

Do not set this value

Recurring Payments

Recurring Payments have specific requirements for how they should be handled as part of the PSD2 mandate for both the initial payment and subsequent payments. This is covered in detail here.

Out-of-Scope Flagging

Out-of-scope Flagging only applies for Backend2Backend integration (initiatePayment).

Field

Description

Values

creationTypeID

MOTO Transactions and Merchant-Initiated Transactions are out of scope.

5 - MOTO
10 - MIT

ScaExemptionID

An out-of-scope transaction using an Anonymous Card must be flagged in this field.

1 - Anonymous Card
Note: It is not allowed for Amex and Diners.


Custom SCA behaviour with new API fields

The initiatePayment and getRedirectData request have been extended with new fields applicable to PSD2.

Merchants will need to send these fields in order to control their SCA preferences if the default behaviour is not sufficient.

The table below lists the additional fields that can be sent in initiatePayment or getRedirectData request. All fields should be provided in initiatePaymentRequest.specificPaymentData or getRedirectDataRequest.additionalData:

Field

Description

Values

ScaPolicyID

Indicates the Policy type that the merchant wants to apply for the particular transaction.
If a value is supplied, this will override the default or merchant-configured Policy.

1 - Default policy
2 - Apply SCA When 3DS 2.0 is available
3 - Apply SCA when 3DS 2.0 with fallback to 3DS 1.0
4 - Never Apply SCA

Check here for Policy descriptions

ScaChallengeIndicator

Indicates the merchant's preference for a challenge for the particular transaction.

ScaChallengeIndicator is only applied if 3DS 2.0 is supported and available within the specified policy

1 - No preference
2 - Request no challenge
3 - Request challenge
4 - Request Challenge As Mandate - A Challenge flow will take place to fulfill a mandate
5 - Challenge Requested Whitelist Prompt - Required when setting up a trusted beneficiary to force a Challenge

ScaExemptionID

Indicates the exemption type that the merchant wants to request for the particular transaction.

The Secure Corporate Card, White-listed merchant/Trusted Beneficiary, and Transaction Risk Analysis exemptions must be flagged even for the default Policy.

An out-of-scope transaction using an Anonymous Card must also be flagged in the same way

1 - Anonymous Card
2 - Low Value Transaction
3 - No Exemption
4 - Secure Corporate Card
5 - White-listed merchant/Trusted Beneficiary
6 - Transaction Risk Analysis (TRA)

Note: 1 and 5 are not allowed for Amex and Diners.
6 is not allowed for Amex.

ScaExemptionFlowID

Indicates at which stage the merchant wishes the exemption to be applied.

Possible values:
1 - authentication - The exemption will be applied during SCA

2 - authorisation - The exemption will be applied directly in authorisation, bypassing SCA

Note: If the exemption type is not supported for the selected exemption flow, then an error is returned

The supported values based on exemption type are:
anonymousCard - 2
lowValue - 2
secureCorporate - 1, 2
trustedBeneficiary - 1, 2
transactionRiskAnalysis - 1, 2

(default value is bold)

The following table describes various scenarios showing how the parameters can be applied:

Desired Behaviour

Values

Action

Apply a specific Policy to a transaction

ScaPolicyID = {any valid ScaPolicyID}
ScaChallengeIndicator = Do not provide
ScaExemptionID = Do not provide
ScaExemptionFlowID = Do not provide

If the provided Policy ID is valid and different than configured or default policy, apply it to the transaction

Exemption can be applied if available as described in Default Policy section

Stipulate whether a challenge is requested during authentication

ScaPolicyID = {not provided or 1, 2 or 3}
ScaChallengeIndicator = {any valid ScaChallengeIndicator}
ScaExemptionID = Do not provide
ScaExemptionFlowID = Do not provide

A challenge preference will be specified during authentication.

Valid for cases where 3DS 2.0 is supported and available

Request exemption in authorisation

ScaPolicyID = Optional/Do not provide
ScaChallengeIndicator = Do not provide
ScaExemptionID = {any valid ScaExemptionID}
ScaExemptionFlowID = 2

If a merchant wants to override the default or configured behaviour for exemptions in Policies 3 and 4, they can skip authentication and request exemption through authorisation

If the exemption is not approved by the issuer, a payment decline response is returned and a new payment has to be initiated by merchant and authenticated through 3DS

Note: Only valid when a payment has an applicable exemption. If the exemption cannot be applied to the transaction then an error is returned

Request exemption in authentication i.e. force SCA on an exempt transaction

ScaPolicyID = Optional/Do not provide
ScaChallengeIndicator = Do not provide
ScaExemptionID = {any valid ScaExemptionID}
ScaExemptionFlowID = 1

The preferred exemption will override the predefined order as described in Default Policy section

If the exemption is not approved by issuer, a response requesting a challenge to be performed is returned

Note: Only valid when a payment has an applicable exemption. If the exemption cannot be applied to the transaction then an error is returned

Perform SCA for both in-scope out-of-scope transactions

ScaPolicyID = 2 or 3
ScaChallengeIndicator = Do not provide
ScaExemptionID = 3
ScaExemptionFlowID = Do not provide

This will ensure that for both in-scope and out-of-scope PSD2 transactions, SCA will take place. Depending on the submitted Policy, this will be with a 3DS1 fallback or 3DS2 only.

Perform SCA for in-scope transactions and use Smart3DS for out-of-scope transactions

ScaPolicyID = 2 or 3
ScaChallengeIndicator = Do not provide
ScaExemptionID = 3
ScaExemptionFlowID = Do not provide

Optional:
IsThreeDSecureConditionalRequired=True

This will ensure that in-scope PSD2 transactions will undergo SCA, but out-of-scope PSD2 transactions will only undergo authentication when there is a Smart 3DS configuration set up for you. For more information on Smart 3DS see Card Deposits with 3DS

Managing specific payment scenarios

Summary of supported payment scenarios per Scheme

Scenarios

Supported for Schemes

Merchant Initiated Transactions (MITs)

Visa, MasterCard, Amex, Diners

White-listed transactions/Trusted Beneficiary

Visa, MasterCard

Managing soft declines

Visa, MasterCard, Amex, Diners

Pass-through Payments

Visa, MasterCard, Amex, Diners

Using different acquirers in authentication and authorization

Visa, MasterCard, Amex, Diners

Merchant Initiated Transactions (MITs)

📘

MITs - relating payments with the Scheme Transaction reference

MITs are transactions made without the presence of a cardholder using stored card information. Card-On-File (COF) payments and Recurring payments are two of the most common examples, and while MITs are treated as out-of-scope for PSD2, there are specific requirements about their correct usage which must be met.

PXP Financial has made available a new API detail to store the unique transaction references - the Visa Transaction ID and Banknet Reference Number respectively - in order to meet the PSD2 requirement for dynamic linking.

This allows for recurring payments and stored credential payments agreements to be related to the initial payment in the agreement sequence.

The name of the detail is SchemeTransactionIdentifier. This detail will need to be enabled by PXP Financial Support once you have indicated that you are ready to use it.

📘

Merchants using the PXP Financial Checkout who want to use MITs

Merchants using the PXP Financial Redirect integration (Checkout/Hosted Payment Pages) can also take advantage of MITs by integrating a combination of Checkout and Backend2Backend:

  • Merchant should redirect customers that want to pay with a new card to the Checkout
  • Merchant should store the created payment credentials (token/payment account) and if a customer wants to pay with stored credentials use the Backend2Backend integration to transmit a COF/MIT transaction

MITs: Handling Recurring Payments

PXP Financial offers both an internal Recurring Payment Service and the ability to pass through recurring payments. See Set up Recurring Payment for more details.

This section provides more details on specific PSD2 mandate requirements for recurring payments and how they can be met.

When a recurring payment is set up, then SCA must take place. Following successful authorisation, the Scheme Transaction reference of the initial payment is returned/can be retrieved:

  • In case of a backend2backend integration, the SchemeTransactionIdentifier field will be returned in the initiatePayment response
  • In case of a Checkout integration, the SchemeTransactionIdentifier field will be sent in the handlePaymentStateChangedNotification and/or can be retrieved via the getPayments request.

For subsequent payments which are not initiated with the cardholder present, SCA will not apply. For such payments use SchemeReferenceTransactionIdentifier to refer to the initial payment used to set up card on file payment.

The table below describes the parameters which need to be submitted in initiatePaymentRequest or getRedirectDataRequest to set up a recurring payment:

Use Case

Is SCA Required

Values

Set up a recurring payment

Yes

Standard fields to send in request for a pass-through Recurring payment:
creationTypeID = {4} Reference
paymentMethodID = {Visa/MasterCard/Maestro/Diners Deposit methods} Reference
IsInitialPayment = true
RecurringFrequencyInDays = {as described}
RecurringExpirationDate = {as described}

Standard fields to send in a request for PXP Financial internal Recurring Payment Service:
None

SCA fields to send in request:
None - we take care of this for you automatically

Standard fields to store in response:
SchemeTransactionIdentifier
SchemeSettlementDate (MasterCard/Maestro payments only)
DinersRetrievalReferenceNumber (Diners payments only)

The table below describes the parameters which need to be submitted in initiatePaymentRequest for a subsequent recurring payment:

Use Case

Is SCA Required

Values

Subsequent recurring payment

No

Standard fields to send in request for a pass-through Recurring payment:
creationTypeID = {4} Reference
paymentMethodID = {Visa/MasterCard/Maestro/Diners Deposit methods} Reference
SchemeReferenceTransactionIdentifier = {SchemeTransactionIdentifier of initial payment}
SchemeSettlementDate = {from initial payment, for MasterCard/Maestro payments only}
DinersRetrievalReferenceNumberOriginalTransaction = {DinersRetrievalReferenceNumber of initial payment, Diners payments only}

Standard fields to send in a request for PXP Financial internal Recurring Payment Service:
None

SCA fields to send in request:
None - we take care of this for you automatically

🚧

Recurring Agreements set up before the PSD2 effective date

If you have a Recurring Agreement which was set up before 14 September 2020, then simply do not submit the SchemeReferenceTransactionIdentifier and SchemeSettlementDate fields for MasterCard recurring payments.

For Visa payments, you must submit in the SchemeReferenceTransactionIdentifier field the SchemeTransactionIdentifier belonging to the initial payment where the COF mandate was set up. If this is not available, you may use the SchemeTransactionIdentifier of any related payment processed before the PSD2 effective date. If you have neither values, you simply do not submit SchemeReferenceTransactionIdentifier. However, please note that Visa mandates merchants to start sending valid SchemeReferenceTransactionIdentifier from November 2021.

MITs: Handling Card on File (COF) Payments

This section is only applicable for Backend2Backend integration.

When a COF payment is set up and the user's payment account information is stored, authentication is necessary. When a follow-up payment is made as a MIT, authentication is not necessary.

However if the follow-up payment is initiated by the cardholder, which will be a Cardholder-Initiated Transaction (CIT) with creationTypeID = 11, then it will need to be authenticated.

Use the creation type MerchantInitiatedWithStoredAccount (creationTypeID = 10) to indicate an MIT and provide the SchemeReferenceTransactionIdentifier of the initial payment for a subsequent COF payment. This Identifier is returned in SchemeTransactionIdentifier field in the initiatePayment response for the initial set-up payment.

See Creation Types and Card On File Deposits (with Tokenization) for more details on how PXP Financial has implemented the MIT framework.

The table below summarises the expected behaviour:

Use Case

Is SCA Required?

Values

Set up COF payment with a card verification/account status inquiry - no purchase

Yes

Standard fields to send in request:
creationTypeID = {any value apart from 10 or 11, normally 1} Reference
paymentMethodID = {202, 203, 215, 332} Reference
UserConsentForStoredAccount = true
IsThreeDSecureRequired = true

SCA fields to send in request:
None - we take care of this for you automatically

Standard fields to store in response:
SchemeTransactionIdentifier
SchemeSettlementDate (MasterCard/Maestro payments only)
DinersRetrievalReferenceNumber (Diners payments only)

Set up COF payment with purchase

Yes

Standard fields to send in request:
creationTypeID = {any value apart from 10 or 11, normally 1} Reference
paymentMethodID = {Visa/MasterCard/Maestro/Diners Deposit methods} Reference
UserConsentForStoredAccount = true

SCA fields to send in request:
None - we take care of this for you automatically

Standard fields to store in response:
SchemeTransactionIdentifier
SchemeSettlementDate (MasterCard/Maestro payments only)
DinersRetrievalReferenceNumber (Diners payments only)

Subsequent COF payment

No

Standard fields to send in request:
creationTypeID = {10} Reference
paymentMethodID = {Visa/MasterCard/Maestro/Diners Deposit methods} Reference
SchemeReferenceTransactionIdentifier = {SchemeTransactionIdentifier of initial payment}
SchemeSettlementDate = {from initial payment, for MasterCard/Maestro payments only}
DinersRetrievalReferenceNumberOriginalTransaction = {DinersRetrievalReferenceNumber of initial payment, Diners payments only}
IndustrySpecificMITType = {Values 0 - 4} see here for more information

SCA fields:
None

🚧

COF payments set up before the PSD2 effective date

If you have a COF payment which was set up before 14 September 2020, then simply do not submit the SchemeReferenceTransactionIdentifier and SchemeSettlementDate fields for MasterCard payments. An exception is when the MIT type is Incremental - if you send IndustrySpecificIndicator = 0 then you need also to send SchemeReferenceTransactionIdentifier and SchemeSettlementDate.

For Visa payments, you must submit in the SchemeReferenceTransactionIdentifier field the SchemeTransactionIdentifier belonging to the initial payment where the COF mandate was set up. If this is not available, you may use the SchemeTransactionIdentifier of any related payment processed before the PSD2 effective date. If you have neither values, you simply do not submit SchemeReferenceTransactionIdentifier. An exception is when the MIT type is Incremental - if you send IndustrySpecificIndicator = 0 then you need also to send SchemeReferenceTransactionIdentifier.
However, please note that Visa mandates merchants to start sending valid SchemeReferenceTransactionIdentifier from November 2021.

White-listed transactions/Trusted Beneficiary

During the SCA process, a merchant can be white-listed by a cardholder so that future payments made by that cardholder for that merchant do not need to go under SCA and can make use of the Trusted Beneficiary exemption.

Not all card issuers will support white-listing so this feature will only be possible to make use of where supported.

Request White-list

In order to request a whitelist set-up during a 3DS2 Challenge, submit the following fields in the initiatePayment or getRedirectData request:

SCA Field Name

Value

ScaPolicyID

Any value except 4

ScaChallengeIndicator

5

ScaExemptionID

Not provided

ScaExemptionFlowID

Not provided

Receive White-list result

The result of the white-listing can be received after a successful challenge.

  • In case of a backend2backend integration, the fields in the below table will be sent in the executeAction response.
  • In case of a Checkout integration, the fields in the below table will be sent in the handlePaymentStateChangedNotification and/or can be retrieved via the getPayments request.

Field

Description

IsScaWhitelistingSuccessful

Indicates if white-listing of trusted beneficiary by cardholder has been successful.

Possible values: {true, false}

ScaWhitelistStatus

Indicates the white-listing status of trusted beneficiary by cardholder.

Possible values:
{
Y - Merchant is white-listed by cardholder
P - Pending confirmation by cardholder
N - Merchant is not white-listed by cardholder
}

Use White-list Exemption

Once the White-list has been set up, use it by submitting the following values in the initiatePayment request:

SCA Field Name

Value

ScaPolicyID

Not provided

ScaChallengeIndicator

Not provided

ScaExemptionID

5

ScaExemptionFlowID

1 or 2

Managing soft declines

When a merchant requests an SCA exemption and it is applied directly in the authorisation message without authentication being carried out beforehand, the transaction may be declined by the issuer with the response code 65.

This indicates a soft decline, which means that the issuer has requested that the transaction must be authenticated. In order to avoid another soft decline, the merchant will need a mechanism to retry the payment with the same card details and ensure that SCA take place. This works differently depending on if the merchant uses 3DS1 or 3DS2.

🚧

Default Policy and Soft Declines

Our Default Policy will apply an LVP in authorisation whenever possible. Since a soft decline will be sent by an Issuer when either the cumulative total amount of transactions since the last SCA took place exceeds 100 EUR or the number of transactions exceeds 5, merchants must be aware of how to force SCA on the next transaction to avoid further soft declines. Read on for more information.

Soft declines: Force SCA with 3DS2

The merchant has to initiate a new payment by sending initiatePayment with all necessary data to perform a 3DS2 authentication and either a new MerchantTransactionID, or the same MerchantTransactionID together with the ProviderID supplied in the request.

The merchant should ensure that they set a challenge indicator in the follow-up payment which will mandate SCA. The value of ScaChallengeIndicator should be set to 4 for this purpose. Please refer to the Custom SCA Behaviour section for more information on triggering a challenge.

The merchant must not request a new exemption following a soft decline.

Soft declines: Force SCA with 3DS1

For merchants who are still using and configured for 3DS1, the merchant has to initiate a new payment by sending initiatePayment with all necessary data to perform a 3DS1 authentication and either a new MerchantTransactionID, or the same MerchantTransactionID together with the ProviderID supplied in the request. The merchant should also ensure that they submit the value ScaExemptionID = 3 (No Exemption).

Automatic Soft declines handling in Checkout

📘

Automatic Soft Declines Handling in PXP Financial Checkout

The PXP Financial Checkout is able to handle Soft Declines automatically for the merchant. It works for 3DS1 as well as for 3DS2 enrolled cards.
To have this feature activated, the merchant has to contact the PXP Support or his PXP Account Manager.
Please note that this feature is not available for Maestro and Amex payments.

In case the issuer refused the card payment which a customer/player made in the checkout with response code 65 (and the payment was not authenticated with 3DS), checkout will automatically trigger an additional payment and forcing a challenge to be made.
The customer remains in Checkout and will see a spinner while he waits. The 3DS input screens will be displayed and he will be able to perform the authentication.

In case the authentication was successful and the issuer authorizes the payment, the customer is redirected back to the merchants success-URL. In addition a backend notification is sent.
In case of another refusal, the customer is redirected to the merchants error-URL (Note: Checkout only does one retry, if the second payment also fails, Checkout will not try again but redirect to Error-URL).

❗️

Handle State Change Notifications for Soft declines handling in Checkout

Usually a merchant receives state change notifications from PXP System only for successful payments.
In case a merchant is also configured to receive notifications for refused payments, merchants have to ensure that they are able to handle the following:

In the case that Checkout has applied the automatic soft-declines handling, two state change notifications will be received by the merchant.
The first notification (RefusedByProvider) is usually already received while the customer is still in the Checkout and doing the authentication for the second payment.
Merchant system needs to wait until the customer is redirected to the Success-URL and a state change notification is received for the second payment.
In case also the second payment is refused, customer is redirected to Error-URL and the merchant system will receive a notification also for the second refusal.

Details about the two state change notifications:

  • The notification for the first payment will have state “RefusedByProvider” and response code 65
  • The notification for the second payment will have the state “AuthorisedByProvider”
  • Both payments will have the same merchant-transaction-id (PaymentID)
  • But the payments will have different UniqueIDs and ProviderExternalIDs

The below diagram shows the system interaction when Checkout handles the soft decline - successful case.
Please note that the asynchronous state change notifications could also be received by the merchant system in a different order.

942942

Soft Declines Handling in Checkout - Flow

Existing 3D Secure Flags in the initiatePayment Request

Merchants with Backend2Backend integration and/ or Redirect (Checkout) need not send the IsThreeDSecureRequired = true flag in the initiatePayment/ redirectData request. The decision for triggering Strong Customer Authentication (SCA) is now controlled by the SCA Policies.

Currently in order to correctly trigger the 3DS2 or 3DS1 flows, merchants must send the IsThreeDSecureRequired = true flag in the initiatePayment request. This only applies to merchants with Backend2Backend integration who haven't integrated with PXP PSD2 Framework.

Alternatively, when a merchant wants to trigger 3DS Authentication for out-of-scope PSD2 transactions, they can determine the conditions under which this occurs using our Smart 3DS functionality. Use the IsThreeDSecureConditionalRequired flag to trigger Smart 3DS.

The IsThreeDSecureConditionalRequired flag cannot be used in conjunction with IsThreeDSecureRequired flag because they are mutually exclusive.

Furthermore, both flags will be deprecated when the PSD2 mandated is live.

❗️

Existing flags for 3DS will be deprecated when PSD2 goes live

Only the IsThreeDSecureRequired flag will be deprecated in the PXP Financial API when the full transition to PSD2 has taken place. At this point, the PXP Financial PSD2 Framework will take over fully in determining when and how SCA will take place.

Note: Originally the IsThreeDSecureConditionalRequired was going to be deprecated but this is no longer the case as it will be used to apply Smart 3DS rules.

🚧

Using Smart 3D Secure when SCA is required

When Strong Customer Authentication is required for a payment, then Smart 3D Secure is not applicable.


Pass-through Payments

Pass-through Payments only apply to Backend2Backend integrations.

3DS 2.0 Pass-through payments and 3DS1 Pass-through payments are payments which have made use of a third-party 3DS Server or 3DS MPI to complete the SCA process, but will be authorised through PXP Financial.

Such payment transactions proceed directly to authorisation but contain the relevant fields to ensure that the valid Authentication outcome is submitted to the Card Schemes, such as the CAVV.

For 3DS2 payments which have undergone SCA, if an exemption has been granted during authentication, it must be flagged in the initiatePayment request.

For more information about how to flag granted exemptions for pass through payments refer to the Integration Steps section.

❗️

Granted Exemptions Flagging

Please note that sending an exemption in a pass-through payment means that the exemption was already granted during the SCA process with the third-party 3DS provider.

Sending an exemption that hasn't been granted during authentication may lead to potential decline of the transaction by issuer.

In addition, sending either the Anonymous Card or Secure Corporate Card indicator in initiatePayment for a pass-through payment will result in a validation error.

Using different acquirers in authentication and authorization

By default, merchants should use the same acquirer for both authentication and authorization. In a multi-acquirer scenario, especially in a retry scenario, it might be necessary to use the same authentication result for multiple authorization attempts.
PXP can support such usecases with

  • stand-alone authentication for use with other acquirers.
  • Authentication is done with another partner, authorization is done with PXP, passing the authentication result (“pass-through”)
  • Authorisation can be done with multiple acquirers integrated into the PXP host. In this case you would need to pass the desired acquirer ID (‘ProviderID’ in PXP terms)

If you are interested in that option, you can contact PXP Financial Support for more information.

Testing PSD2

The functionality described in this document is already testable on our Test environment. Please contact PXP Financial Support if you need further guidance on how to do this.

In the meantime, we are working on a a comprehensive set of Test Cases which can be used as a validation and certification document.