Changes for transactions without customer presence
10.02.2023
What happened?
A directive, introduced by the major card schemes, requires merchants to submit a so called transaction identifier. This transaction identifier is used to track cards and transactions done with these cards, in order to battle fraud and other malicious transactions.
For most merchants, Saferpay does keep track of this Identifier for you, However for initial transactions and card aliases created before November 2019, this transaction identifier could either be invalid, or non-existent, which could lead to rejections, should Merchant Initiated Transactions (MITs), like Recurring Payments, be attempted.
This chapter aims to help merchants with this issue and guide them towards a compliant solution.
This change does not impact normal customer initiated E-Commerce transactions, done with 3D Secure.
It only applies to certain Merchant Initiated Transactions, initial Customer Initiated Transactions and card aliases, created before November 2019.
If you do not do MITs/Recurring transactions, this change does not apply to you.
What to do?
The following steps may be required, in order to stay compliant, depending on your integration.
1. For fully PCI certified merchants using JSON API AuthorizeDirect with plain card data to perform “merchant initiated transactions” (MITs):
Use
Authentication.IssuerReferencecontaining the transaction identifier from the Saferpay transaction response (SeePayment.IssuerReference)message to make sub-sequent recurring or unscheduled transactions.
Important: Upgrade to the latest JSON API Spec. version (or at least to 1.16 [1.21+ recommended]) is required.
Please consider this chapter for critical changes within the Saferpay Payment API, if you need to do an upgrade.
2. For merchants using AliasId to perform sub-sequent MITs via Authorize Direct:
Existing Aliases: continue until the 1st soft-decline (PAYER_AUTHENTICATION_REQUIRED) is received or card renewal is required. Then continue with the next step, "New Aliases".
New Aliases: Always register new Aliases forcing Strong Consumer Authentication.
Important: Upgrade to the latest JSON API Spec. version (or at least to 1.16 [1.21+ recommended]) is required.
Please consider this chapter for critical changes within the Saferpay Payment API, if you need to do an upgrade.
Strong Consumer Authentication (SCA) is mandatory for merchants inside the PSD2 zone / European Economic Area (EEA), when performing MITs.
For merchants outside of PSD2/the EEA, SCA is strongly recommended, as these transactions are more secure and also cheaper for the merchant!
“No authentication”-fee and non-compliant MIT-penalties are also applicable for payments outside PSD2.
3. For merchants using AuthorizeReferenced without initial SCA or if initial 3DS transaction was done before Nov. 2019
Continue until the 1st soft-decline (PAYER_AUTHENTICATION_REQUIRED) is received or card renewal is required. Then submit a new initial transaction according to recommendation below:
Submit a new initial transaction with Strong Consumer Authentication and re-start the recurring sequence. See Recurring Payments with the Referenced Transactions Method.
Important: Upgrade to the latest JSON API Spec. version (or at least to 1.16 [1.21+ recommended]) is required.
Please consider this chapter for critical changes within the Saferpay Payment API, if you need to do an upgrade.
Strong Consumer Authentication (SCA) is mandatory for merchants inside the PSD2 zone / European Economic Area (EEA), when performing MITs.
For merchants outside of PSD2/the EEA, SCA is strongly recommended, as these transactions are more secure and also cheaper for the merchant!
“No authentication”-fee and non-compliant MIT-penalties are also applicable for payments outside PSD2.
4. Inside the Saferpay Backoffice
Only use authorizations or Aliases created with Strong Consumer Authentication from which to initiate unscheduled MITs.
Strong Consumer Authentication (SCA) is mandatory for merchants inside the PSD2 zone / European Economic Area (EEA), when performing MITs.
For merchants outside of PSD2/the EEA, SCA is strongly recommended, as these transactions are more secure and also cheaper for the merchant!
“No authentication”-fee and non-compliant MIT-penalties are also applicable for payments outside PSD2.
Moto transactions must always be performed via dedicated Moto terminals. Do not use e-com terminals!
Last updated