LogoLogo
BlogLogin
English
English
  • An Introduction to Saferpay
    • Licensing
      • Legacy licensing
    • Reconciliation
    • Acquirers & Payment Methods
    • Web Shop Plugins and certified partners
      • ePages Beyond
      • ePages NOW
      • Magento 2
      • Odoo
      • PrestaShop
        • PrestaShop User Guide
      • Salesforce Commerce Cloud
      • SAP Commerce Cloud
      • Shopware 6
        • Shopware 6 User Guide - German
        • Shopware 6 User Guide - English
      • WordPress WooCommerce
      • Shopify
    • Supported Languages
    • Common Saferpay terms - Glossary
  • News
    • Changes for transactions without customer presence
    • Changes for the Saferpay Hosted Forms, Fields and Payment Page
  • Quick Links
    • Web Shop Plugins and certified partners
    • Secure PayGate
    • User Administration
    • Payment Page Configuration
    • Risk Management
    • API Authentication
  • Interfaces
    • Payment API (aka JSON API)
    • Management API
    • Backoffice
      • The Home screen
      • Batch Processing
      • Transactions
        • Transaction Details
        • Batch Close
        • Declined transactions
        • Pending authorizations
        • Analytics
        • SEPA Refunds Export
        • Authorization & Payment
        • Credit
      • Risk Management
      • Secure PayGate / Payment Links
      • Secure Card Data
        • Secure Card Data Details
      • Settings
        • JSON API basic/Client Certificate authentication
        • User Administration
        • Payment Page Configuration
      • Online Support
      • User Profile
    • Saferpay OnSite
    • Feedback
  • Integration Guide
    • Integrating Saferpay
    • Ways of integration
      • General Information
        • Data Security and PCI DSS
        • Versioning
        • 3-D Secure
        • PSD2
        • Dynamic Currency Conversion
        • Iframe Integration and CSS
        • Fraud Intelligence
          • Silver
          • Fraud Intelligence Integration
      • Payment Page
        • Payment Page checklist
      • Transaction Interface
        • Recurring Payments
        • Refunds
          • SEPA Refunds
      • Capture and Daily Closing
        • Partial Captures
          • Marketplace
      • Secure Card Data - Tokenization
      • Saferpay Fields
      • Inquire Interfaces
      • Mobile Integration
      • Omni-Channel
      • Mail Phone Order
      • Error Handling
      • API Health Check
      • Saferpay API Specification
    • Payment Methods & Wallets
      • General and special cases
      • Account-to-Account Payments
      • Alipay+
      • Apple Pay
      • American Express
      • Bancontact
      • Billie
      • blik
      • Click to Pay
      • Diners Club International & Discover Card
      • eps
      • giropay
      • Google Pay
      • iDEAL 2.0
      • JCB
      • Klarna Payments
      • Maestro International
      • Mastercard
      • paydirekt
      • PayPal
      • PostFinance Pay
      • Przelewy24
      • Reka
      • SEPA Direct Debit
      • Sofort by Klarna
      • TWINT
      • UnionPay
      • Visa & V PAY
      • WeChat Pay
      • WL Crypto Payments
    • Testing
    • Go-Live
    • Frequently Asked Questions
    • Saferpay Demo
      • Saferpay Demo Environment
      • Saferpay Demo Shop
    • Support
    • Changelog
Powered by GitBook
On this page
  • What happened?
  • What to do?
  • 1. For fully PCI certified merchants using JSON API AuthorizeDirect with plain card data to perform “merchant initiated transactions” (MITs):
  • 2. For merchants using AliasId to perform sub-sequent MITs via Authorize Direct:
  • 3. For merchants using AuthorizeReferenced without initial SCA or if initial 3DS transaction was done before Nov. 2019
  • 4. Inside the Saferpay Backoffice

Was this helpful?

  1. News

Changes for transactions without customer presence

10.02.2023

PreviousNewsNextChanges for the Saferpay Hosted Forms, Fields and Payment Page

Last updated 1 year ago

Was this helpful?

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 and 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 , 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 .

It only applies to certain Merchant Initiated Transactions, and , 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 using with plain card data to perform “merchant initiated transactions” (MITs):

  • Use Authentication.IssuerReference containing the transaction identifier from the Saferpay transaction response (See Payment.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 for critical changes within the Saferpay Payment API, if you need to do an upgrade.

2. For merchants using to perform :

Important: Upgrade to the latest JSON API Spec. version (or at least to 1.16 [1.21+ recommended]) is required.

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.

Important: Upgrade to the latest JSON API Spec. version (or at least to 1.16 [1.21+ recommended]) is required.

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.

Only use authorizations or Aliases created with Strong Consumer Authentication from which to initiate unscheduled 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.

Existing Aliases: continue until the is received or card renewal is required. Then continue with the next step, "New Aliases".

New Aliases: Always register new Aliases forcing .

Please for critical changes within the Saferpay Payment API, if you need to do an upgrade.

Strong Consumer Authentication (SCA) is mandatory for merchants inside / European Economic Area (EEA), when performing MITs.

3. For merchants using without initial SCA or if initial 3DS transaction was done before Nov. 2019

Continue until the is received or card renewal is required. Then submit a new initial transaction according to recommendation below:

Submit a new initial transaction with and re-start the recurring sequence. See .

Please for critical changes within the Saferpay Payment API, if you need to do an upgrade.

Strong Consumer Authentication (SCA) is mandatory for merchants inside / European Economic Area (EEA), when performing MITs.

4. Inside the

Strong Consumer Authentication (SCA) is mandatory for merchants inside / European Economic Area (EEA), when performing MITs.

Moto transactions must always be performed via dedicated . Do not use !

consider this chapter
the PSD2 zone
AuthorizeReferenced
consider this chapter
the PSD2 zone
the PSD2 zone
Recurring Payments
3D Secure
fully PCI certified merchants
JSON API AuthorizeDirect
consider this chapter
Saferpay Backoffice
Moto terminals
e-com terminals
card aliases
card aliases
AliasId
1st soft-decline (PAYER_AUTHENTICATION_REQUIRED)
Strong Consumer Authentication
1st soft-decline (PAYER_AUTHENTICATION_REQUIRED)
Strong Consumer Authentication
initial transactions
initial Customer Initiated Transactions
sub-sequent MITs via Authorize Direct
Recurring Payments with the Referenced Transactions Method