PSD 2 Support at PXP Financial
Introduction
PSD2 is a new paradigm for payment processing and authentication in the EEA and for card payments, is intrinsically linked to the 3D Secure 2.0 (3DS2) for Strong Customer Authentication (SCA) requirements. These requirements make SCA mandatory for all card payments, unless either an exemption can be applied to a payment, or if it is out-of-scope of the PSD2 mandate.
PXP Financial has taken steps to ensure that the new PSD2 requirements can be handled automatically on behalf of all our merchants, but it is important for merchants to be aware of how the new PSD2 framework impacts transaction processing. Decisions will need to be taken to determine how best to leverage this framework and the degree of implementation necessary.
This page provides more detail on how PXP Financial supports PSD2 requirements and how this can be managed based on merchant preference or needs.
Tools to manage PSD2
PXP Financial has introduced a number of new features to facilitate PSD2 handling.
Policy Framework
A new PSD2 Policy Framework will dictate how PSD2 SCA requirements will be handled by PXP Financial, with a default policy that will be applicable to all merchants where PSD2 is in-scope, and a set of configurable policies which are applicable where PSD2 is out-of-scope.
SCA Exemption Engine
PXP Financial will introduce an SCA Exemption Engine to:
- Evaluate and select qualifying exemptions on a per-transaction basis
- Determine if the exemption will be applied directly during authorisation
API Extensions to manage exemptions
Exemption behaviour can be managed according to merchant preference on a per-transaction basis. Details can be found in our PSD2 Implementation Guide.
Exemption behaviour can be configured
Our default approach may not suit all needs, so we have provided additional configurable behaviour which can be requested per transaction.
SCA through 3DS2
PSD2 requirements for SCA are fulfilled by 3DS2
3DS2 supports PSD2 directly by allowing exemptions to be applied during payment authentication.
For comprehensive information on the benefits of 3DS2 and the API integration requirements for PXP Financial's 3DS 2.0 Server, please refer to the 3DS 2.0 Information Hub.
Not being compliant with PSD 2 will lead to much lower approval rates
Merchants must ensure support for 3DS2 at the earliest possible opportunity.
Configuring the level of SCA
The following behaviour is configurable at merchant level:
- Default Policy
- Supported exemptions that will be processed
Support in the PXP Financial Checkout
The PXP Financial Checkout will support PSD2 by default.
Smart 3D Secure
In scenarios where PSD2 is not mandated, our existing Smart 3D Secure logic will still take over to determine if 3DS Authentication should take place. See our Smart 3DS page for more information on Smart 3D Secure.
PXP Financial PSD2 Policy Overview
This section will provide more detail on how PXP Financial leverages the new SCA exemption engine and Policy framework to enable merchants to meet PSD2 requirements.
Each Policy:
- Defines a default behaviour for in-scope PSD2 transactions
- Dictates when and how authentication takes place for transactions which are not covered by the PSD2 mandate
The policies are described below.
| Policy Type | Description |
|---|---|
| Default | SCA will take place for all in-scope PSD2 transactions with 3DS2. Transactions which are out-of-scope will skip all forms of SCA. Smart 3DS rules will not apply. |
| SCA only with 3DS2 | Same as Default Policy for in-scope PSD2 transactions. For out-of-scope PSD2 transactions, SCA will be performed always with 3DS2. Smart 3DS rules will apply if configured. |
| SCA with 3DS1 or 3DS2 (Obsolete) | Same as Default Policy for in-scope PSD2 transactions. For out-of-scope PSD2 transactions, SCA will be performed always with 3DS2 or 3DS1. Note: 3DS1 has now been sunset, so this policy will function identically to the Policy above. Smart 3DS rules will apply if configured. |
| No SCA | Always skip all forms of SCA. If a transaction is in-scope PSD2, then apply any available exemptions in the authorisation, as described in the Default Policy. |
There are 3 options for managing the Policy Framework:
- Let PXP Financial manage the PSD2 SCA requirements on your behalf for both in-scope and out-of-scope PSD2 transactions as per the Default Policy
- Set a Policy preference to manage out-of-scope PSD2 transactions (Note: PSD2 in-scope transactions will still be governed by default behaviour for all but one of our Policies). Please contact the PXP Financial Support team if you wish to configure a specific Policy
- Alternatively, parameters can be sent in the payment request (
initiatePaymentorgetRedirectData) which will override the configured or default Policy, in order to have specific behaviour per transaction. These are covered in the Implementation Guide
Default Policy Behaviour: PXP Financial manages SCA on your behalf
Using the Default Policy
The Default Policy will be the preference of merchants who do not want to perform extensive integration, configuration and testing.
This is a standardised processing framework for all your transactions that are in-scope for PSD2. Transactions which are out-of-scope of PSD2 will not have any SCA applied by default.
Note: The default policy for Visa and MasterCard payments have some differences compared to Amex. The specifics related to Amex payments are described further below.
The diagram below illustrates the decision flow that will be used for all payments with the Default Policy:
PXP Financial will:
- Automatically screen incoming payments for the PSD2 mandate
- Exclude out-of-scope payments from SCA and proceed to authorisation. If Smart 3DS is configured, it will only be applied for One-leg-out payments
- For in-scope PSD2 payment transactions, evaluate if any exemption is available and apply it directly in authorisation or authentication
- Where SCA is necessary, apply 3DS2
Out-of-scope (OOS) checks are applied as follows:
| Type of OOS transaction | Trigger |
|---|---|
| Inter-regional (One leg out) | Based on card BIN range information determined by PXP Financial The check is not available for Amex |
| MOTO | Based on Payment Creation Type. Must be flagged in initiatePayment request |
| Anonymous | Based on flag provided in initiatePayment requestThe check is not available for Amex and Diners |
| Merchant-Initiated Transactions (MITs) | Based on Payment Creation Type flagged in initiatePayment request |
| Card Verifications | Card Verifications which are pure Account Status Inquires without storing credentials are considered as out-of-scope for PSD and do not require SCA. |
Exemption priority will be pre-set in a defined order - the exemption with the highest priority that is applicable to the payment will be selected before proceeding to SCA or authorisation respectively. Some exemptions must be explicitly requested in each Payment Request and be configured for use.
The table below shows how this works, including the defined order for checking for available exemptions:
| Exemption Type | Priority | How to Apply | Applied during... |
|---|---|---|---|
| Secure Corporate Payments | 1 | Must be explicitly requested in each payment transaction and configured with PXP Financial Support | Authorisation |
| White-listed Transactions/Trusted Beneficiary | 2 | Must be explicitly requested in each payment transaction and configured with PXP Financial Support. White-listing is selected by the cardholder when performing SCA and can be requested during SCA by a merchant as described here This exemption type cannot be used for Amex and Diners | Authorisation |
| Transaction Risk Analysis (TRA) | 3 | Must be explicitly requested in each payment transaction and configured with PXP Financial Support This exemption type cannot be used for Amex | Authentication |
| Low Value Transactions | 4 | Must be explicitly requested in each payment transaction and configured with PXP Financial Support Could be applied automatically if requested | Authorisation |
| Recurring Payments | 5 | See PSD 2 Implementation Guideline: Recurring Payments | Authentication (first payment) Authorisation (subsequent payments) |
The exemption type determines if we will either proceed to SCA with the applied exemption requested, or directly authorise the transaction with the applied exemption.
Where an exemption cannot be applied to a payment, we will proceed to SCA. This will require a fully working 3DS2 integration.
Amex specifics
This section describes the differences of the default policy for American Express from Visa and MasterCard. In brief, the differences are:
- Every transaction must go through SCA except Moto and MIT. In case the payment is out-of-scope or an exemption is available, it is expected to proceed with authorisation following frictionless authentication
- Amex evaluates if a payment is One-leg-out during frictionless flow of authentication.
- Amex evaluates if anonymous card is used during frictionless flow of authentication. It cannot be requested by merchant.
- Low-value exemption and Secure Corporate exemption can be requested by merchant
- TRA or Trusted Beneficiary exemptions are applied by Amex during frictionless flow of authentication. They cannot be requested by merchant.
Successful and Unsuccessful Exemption Handling
Where an exemption is available and applied successfully, note that the liability will stay with the merchant.
Where an exemption is available and rejected during authorisation, the merchant must be prepared to process the corresponding soft decline code sent back to them by PXP Financial. See the Soft Decline Handling section for more information.
Where an exemption is rejected during authentication, an SCA check will be applied using 3DS2 (Challenge flow).
Policy 2: SCA always with 3DS2
When should a Merchant use Policy 2?
Select this Policy when you want to apply SCA to all your transactions with 3DS2.
This policy will always apply an SCA check wherever 3DS2 is supported by the issuer for out-of-scope PSD2 payment transactions.
For in-scope PSD2 transactions, the Default Policy behaviour will be followed. If 3DS2 is not available then there will be a fallback to 3DS1.
For out-of-scope PSD2 transactions where 3DS2 is not supported or if the merchant is only configured for 3DS1, PXP will automatically proceed to authorisation without a 3DS1 fallback.
Policy 3: SCA always with 3DS1 and 3DS2
Policy 3 is deprecated
Since 3DS1 has been sunset, this Policy is functionally identical to Policy 2. The below text has been retained for illustrative purposes only.
This policy will always apply SCA wherever 3DS1 or 3DS2 are supported by the issuer for out-of-scope PSD2 payment transactions.
For in-scope PSD2 transactions, the Default Policy behaviour will be followed. If 3DS2 is not available then there will be a fallback to 3DS1.
Policy 4: Never apply SCA
This policy will not apply SCA for any payment. Authentication will be skipped and PXP Financial will directly proceed with authorisation.
For in-scope PSD2 transactions, exemptions will still be applied during Authorisation as described in the default policy, unless specifically requested by contacting the PXP Financial Support team, or if over-ridden in the API request as described below
This policy will greatly increase the possibility of an issuer rejecting a payment with a soft decline. See the Soft Decline Handling section for more information. Where a merchant is configured by default for Policy 4, this means a follow-up payment will need to be submitted with a policy preference which performs SCA, or forcing an SCA to take place using the appropriate flag in the initiatePayment or getRedirectData request. Please note that for MasterCard specifically, this Policy, when not applied with an exemption during authorisation, will lead to possible non-compliance fines.
Notes for all policies
General
- Policies can be specified per payment transaction or configured by default
Exemption Handling
- The SCA Exemption Engine can be over-ridden if the default order of exemption prioritisation is not desired. The exemption preference - including type of exemption and where it should be applied (in authorisation or authentication) - can be provided in each transaction request. See the PSD 2 Implementation Guideline for more information
- If an exemption is approved by the issuer during authentication, PXP will proceed with authorisation as per the merchant's preference for automatic fallback to authorisation. For more information please refer to our 3DS Authorisation Policies
- Secure Corporate, Trusted Beneficiary and Transaction Risk Analysis (TRA) Exemptions must be requested explicitly in the
initiatePaymentrequest or they will not be applied
Merchant Decisions and Actions
Please use the following table as a checklist for decision-making on how PSD2 should be applied to your payment processing through PXP Financial.
| Decision | Required Actions |
|---|---|
| Will you use the PXP Financial Default Policy for managing PSD2? | - Integrate 3DS2 as soon as possible - Contact the PXP Financial Support team to ensure your 3-D Secure configuration reflects your capabilities - Ensure you have a process in place to handle Soft Declines as described further below - Ensure you have integrated the MIT Framework correctly to flag appropriate OOS transactions (recurring and merchant-initiated) as described further below |
| Will you use a different Policy for managing PSD2 than the PXP Financial Default Policy? | - Consider all points in the row above - Decide if you will configure a Policy or send it directly per payment transaction - The PXP Financial Support team will assist with configuring your Policy if necessary |
| Dynamically switch selected Policy per payment transaction? | - Ensure your integration teams are familiar with the Implementation Guide to determine when to over-ride the configured Policy |
| Which exemptions will you support? | Certain exemptions must be flagged in the payment request (initiatePayment or getRedirectData) request if they are to be applied. These must also be configured by request to the PXP Financial Support team.If there are exemptions that you do not wish to apply to your transactions, please inform PXP Financial Support |
| Do you have a preference for when to apply exemptions? | Exemptions can be applied during Authentication or Authorisation. If the default exemption behaviour outlined in this section is contrary to what you wish then combine the scaExemptionID and scaExemptionFlowID fields in the in the payment request (initiatePayment or getRedirectData) request to customise where the exemption will be applied.Applying exemptions during authentication will result in a better customer experience and less declines, but will also increase overall transaction fees. Refer to the Implementation Guide for more information |
| Do you require all your payments to undergo SCA? | If absolutely no exemptions are desired, in order to ensure that all transactions undergo SCA and liability shift, this can be done by either: - setting the relevant scaExemptionID to require no exemption- setting the scaChallengeIndicator to require a challengeSee the Implementation Guide for more information |
| Will you use Secure Corporate Card, Low Value or TRA exemptions? | Send the appropriate exemption in the in the payment request (initiatePayment or getRedirectData) and ensure you are configured for this exemption with PXP Financial Support |
| Will you flag Trusted Beneficiary exemptions? | Follow the instructions in the SCA Whitelisting section to both apply for and handle confirmation of merchant whitelisting |
| Will you force SCA even when an exemption is available? | Some merchants may have a preference to apply SCA to all their transactions, regardless if an exemption is available. This can be done by flagging in the payment request (initiatePayment or getRedirectData) with the appropriate field.This enables a merchant to have a liability shift for all their transactions, even if an exemption was available for use |
| Will you use the MIT framework to flag transactions as out-of-scope? | - Ensure you store and use the Scheme Transaction Identifier for both MasterCard and Visa - Refer to the Implementation Guide for more information |
| Do you have Recurring payments? | - Ensure you can store the unique Scheme Transaction Identifier for both MasterCard and Visa when setting up a Recurring Payment - This unique identifier will need to be submitted in follow-up Recurring payments - Refer to the Implementation Guide for more information |
| Do you have MOTO payments? | PXP Financial will automatically skip SCA for transactions with the creation type MOTOEcom |
| Can you handle the Soft-Decline response code in case an exemption is refused during Authorisation? | Ensure you have a process in place to handle Soft Declines |
| Are you integrated to the PXP Financial Checkout? | - The PXP Financial Checkout will apply the Default Policy as standard, but this can also be over-ridden to manage exemption and/or Policy behaviour as specified in the Implementation Guide - Please note that certain exemptions and out-of-scope behaviour are not available on the Checkout, such as MITs and MOTO payments |
Updated 11 months ago
Read on for our detailed PSD2 Implementation Guide. Detailed instructions are provided for how to use the PXP Financial API to meet the minimum requirements for PSD2, and to take advantage of custom exemptions if desired.