Merchant initiated transactions are out of scope for strong customer authentication. However, there are some important considerations to be aware of…

 

In summary

New requirements for strong customer authentication are coming into force from 31 December 2020 in Europe. And from 14 September 2021 in the UK.

Strong customer authentication, also known as SCA for short, will apply to every electronic transaction, such as logging on to online banking or buying something on the web, however there are some exceptions.

One of these is merchant-initiated transactions or MITs — one or a series of transactions governed by an agreement between the cardholder and the merchant. Once an agreement is in place, the merchant can initiate payments without direct involvement from the customer.

This could be for fixed or variable amounts, and at fixed or variable intervals. In this way, MITs are similar to direct debit mandates.

Importantly, out-of-scope MITs are not identified automatically. Merchants and payment service providers must flag them accordingly, so issuers can recognise them.

In some circumstances, SCA may be required for the first transaction when the customer agrees to the terms for subsequent MITs. Thereafter, providing subsequent transactions are correctly coded and flagged as out of scope MITs, issuers must not decline them.

 

Use cases

MITs are much more than recurring transactions. They include delayed and split shipments. And certain transaction types common in the hospitality sector, such as reauthorisations, delayed charges and no shows.

We advise our merchants to assess the impact of SCA on their customer journeys and processes to maximise the use of exemptions for a smooth checkout flow. It would be the worst of all worlds to get to 1 January 2021 and find that legitimate transactions are being declined, because they have not been correctly identified and flagged.

If you’re uncertain as to whether any of your use cases falls within the scope of a MIT, please contact our payment experts today for advice.

Here are some examples of MITs (non-exhaustive list):

  • Recurring payments: where merchants bill at fixed, regular intervals for goods or services supplied over time, following agreement with the cardholder.
  • Instalment payments: where merchants bill for goods or services across multiple transactions agreed with the cardholder.
  • Prepayments: where merchants bill in advance for goods or services across multiple transactions agreed with the cardholder.
  • Credential on file (MIT): where the cardholder has consented to the merchant initiating one or more future transactions using a stored credential. This could be for fixed or variable amounts and intervals.
  • Reauthorisation: a payment made after the original purchase, for example in the case of delayed or split shipments, or extended stays or rentals in the hotel and car rental sectors.
  • Delayed charges: typically used in the hotel, cruise and car rental sectors to bill cardholders after the original service has been rendered. For example, mini-bar use, breakfast on the morning of check-out or damage.
  • No show: typically used in the hotel, cruise and car rental sectors to bill cardholders, who fail to take up services they have agreed to purchase.

 

Flagging and coding

Merchants and payment service providers must flag out-of-scope MITs accordingly, so issuers can recognise them. This will help prevent declines or ‘soft declines’, namely when the 3D-Secure (3DS) protocol is used to ask for a step-up authentication from the customer.

Two values are required to indicate an MIT transaction. Firstly, a code that identifies the type of MIT. Secondly, the transaction ID of the transaction used to set up the MIT. This means that you have to be able to store the previous transaction ID, retrieve it and populate appropriate field when you process an MIT transaction.

 

Zero-value transactions

Zero-value transactions are used in various different scenarios. Whether or not SCA is required depends on the scenario. 

Sometimes you will not take payment when setting up an MIT. This comes later at the end of the first month, on usage or download. You may wish to check the validity of the card by performing a zero-value transaction. SCA is not required because this is not a payment transaction.

However if you are using a zero-value transaction to set up an MIT, then SCA is required, unless an exception applies. For example, the MIT is set up via mail order/telephone order.

 

What support is available?

PXP Financial has devised strong customer authentication policies for processing online payments to suit all merchants, sectors and geographies. For more information on the policies, please visit https://developer.pxp-solutions.com/reference#sca-policy.

Our ANYpay online developer hub also contains various integration guides, API references, examples and test scripts and is publicly available at https://developer.pxp-solutions.com.

If you cannot find a solution for your particular sector or use case, contact us. We may be able to help, plus work with business partners to deliver solutions.