How to do Merchant Initiated Transactions

Purpose of this document

This document provides a brief overview of how to perform Merchant Initiated Transactions (also referred to as recurring payments or MIT).

In this document we will focus on a high-level overview of what you as a Merchant need to consider when performing recurring payments on stored cards using the features available in the OnPay service.

Please note that technical integration with OnPay for recurring payments is not within the scope of this document, but where relevant, we have included links to the technical documentation.

What is a Merchant Initiated Transaction?

Simply put, it is a payment on a stored card without the cardholder being present.

For example, you are a Merchant that is selling a subscription to a magazine/newspaper; a cardholder signs up for and pays for your subscription creating a stored card on file.

Each month you process a payment on the stored card to continue the service, this recurring payment is a Merchant Initiated Transaction.

Initial sign-up process and storing the card

The first step of performing Merchant Initiated Transactions is to obtain the stored card on file.

In all cases the cardholder will be required to perform SCA on this initial signup, it is important to note that the initial signup can be done with no charge to the card (0 amount). However, if you intend on making an initial charge on the card the amount must be provided in the request to cover the amount you will charge.

Relevant technical documentation:

API: https://onpay.io/docs/technical/api_v1.html#create-a-new-payment-request

SDK: https://github.com/onpayio/php-sdk (see the Payments header in the readme)

It is the Merchants responsibility to ensure that the cardholder is clearly informed at the time of payment, that

1. This is creating a stored card on file.
2. Recurring payments will be automatically charged to their card.

How should a Merchant Initiated Transaction be used?

Because of the nature of Merchant Initiated Transactions, there is an element of trust between the Cardholder and the Merchant. Therefore, it is important for the Merchant to use this type of payment in a predictable way. I.E. In regular intervals and for an agreed amount.

Also, be aware that local laws apply to this type of transaction. As the Merchant, you need to ensure that you comply with them. A breach of these laws can result in the termination of Acquirer agreements.

Stored Card Lifecycle Overview

Every stored card has a lifecycle, this lifecycle provides you as the Merchant a period where the credentials are viewed as valid, and you can process payments using them.

A Merchant should not use card expiry data to assume that a card is no longer valid.

The process that should be followed is that, first the Merchant attempts a payment on a stored card. If the response from OnPay is that this is indeed an expired card, this can then be communicated to the Cardholder as they will be required to sign up again with a new card to continue their service with you.

The reason this process should be followed is because of the introduction of tokenized cards (in the case of some brands) and card automatic updates (in the case of some brands) where the expiration date could be different to the original card used.

In the case where a stored card is exchanged for a token with the card provider, the original card details are replaced with the token card details. The tokenized card will contain a different card number and different expiry data to the original card that was tokenized.

In the case of tokenized cards (or cards brands that support automatic updates), it is also possible that the card/token will automatically be renewed, and the expiration date updated without any involvement with the Cardholder. This update to the expiration date can potentially happen as late as during the final month of the previous expiration date.

For more information on Tokenized cards please see: Tokenized cards

Prior to the ability for card issuers to automatically update tokens/cards it was customary for Merchants to perhaps store or retrieve the original cards expiry data to notify Cardholders that their card was due to expire prior to attempting to process a payment. Due to the introduction of tokenized/updated cards this is not recommended anymore. Following the process above will result in a smoother experience for both you as the Merchant and the Cardholder.

It is also possible that in certain cases, a stored card will be cancelled.

This can happen either as part of a failed transaction by the issuer or by direct communication from card brands to OnPay. In this case this should be communicated to the Cardholder as they will be required to sign up again with a new card to continue their service with you.

COF setup flow diagram