Optimize your payment flow for recurring and subscription payments

In the early days of online payments, card schemes and issuers did little to distinguish between one-off transactions and recurring / subscription payments. Later, as online subscriptions became more popular, Visa and Mastercard introduced requirements to ensure merchants are transparent about subscription terms to customers.

These requirements are still evolving - last month we published a Mastercard scheme mandate requiring merchants to show the basic subscription terms and capture the cardholder’s acceptance of those terms before they pay.

Alongside new disclosure requirements, you can use properties in your Checkout.com payment requests to help issuers identify recurring and subscription transactions.

Flagging recurring and subscription transactions to issuers

If you process subscriptions, recurring payments, or any other type of Merchant Initiated Transaction, it’s important that you’re sending the right properties in your Checkout.com payment requests.

This is crucial if you operate in an SCA region, where issuers might want the cardholder to authenticate recurring payments (an impossible ask for subsequent transactions) if they can’t correctly identify the transaction type.

Here are our top tips to optimize how you send these transactions to Checkout.com:

When submitting the first transaction to set up a subscription or series of recurring payments:

• Set the parameter payment_type to recurring, instead of regular. This will help the issuer identify subsequent payments using the same payment ID (more on this below)

For subsequent subscription and recurring transactions:

• Set the parameter payment_type to recurring
• Set merchant_initiated  to true
• Use the store_for_future_use field to true
• Submit the previous_payment_id of the initial transaction used to set up the recurring series; this can be either a Checkout.com payment_id (format pay_XXX) returned with the first transaction. Alternatively, if you made the first payment through another provider, you can use the scheme_id (format: 12345… or ABCDE…)

The last of these points has become more important, as previously Visa allowed Checkout.com to use a dummy ID in place of the previous_payment_id. From November 1, Visa may apply non-compliance assessments (fines) if you don’t supply this as part of your subscription and recurring transaction requests within the EEA and UK.

To increase authorization success, we strongly recommend using the payment_id associated with the original transaction used to set up the recurring payment series. We’ve included an example flow below:

For more information, please visit our docs, or speak to your Checkout.com support team who will be happy to help you.