Demystifying card payments pt.2

An overview of repeat payments .

Product Knowlegde

Written by Tom Hannah and Janka Bergner
16 November 2020


Note

This article refers to [Version 6 of our Card Payments API]/products/access/card-payments/@v6/index.md).

Introduction

The typical card transaction outlined in our "Demystifying card payments pt.1 assumes that your customer is making a one-off purchase from your website. However anyone shopping online today knows it is commonplace to store your payment details on a website for ease of making subsequent purchases. These are called repeat payments and this section outlines: what they are, why you should offer them, the different types of repeat payments along with some commonly used terms.

Why offer repeat payment?

Having the customer's payment credentials stored with you is convenient for them, leading to higher customer retention. You are making future purchases easy, so your customers are more likely to come back. Besides this, repeat payments tend to strengthen your business because your predictability in order fulfilment and cashflow is greater.

Why use stored credentials?

A stored credential is payment information - usually a card number and expiry date - that is saved by you to carry out transactions in the future. This makes transactions smoother, simpler and faster for the customer. Just as importantly, using stored credentials gives other players (e.g. issuing banks, payments processors and card networks) more information about the transactions involving these cards.

This results in:

  • A direct link to a first authorization where the customer was present and authenticated (usually through 3DS) at the point of authorization, which leads to:
  • higher authorization rates (it's easier to confirm that a transaction is genuine), and therefore;
  • a better customer experience and fewer complaints.

Types of transaction

Customer-initiated transaction (CIT)

These are transactions that are initiated by your customer and can be a one-time payment or part of a repeat payment agreement. You must get consent from your customer, if you're storing their details for future use.

Merchant-initiated transaction (MIT)

These are transactions that are triggered by you on behalf of your customer. These transactions can only happen as a follow-up from an original CIT when a customer has pre-agreed certain parameters. In broad terms, these parameters fall into one of three categories, which must be declared by you for every MIT:

  1. Subscription: an agreement to bill a customer for ongoing consumption of goods/services at regular intervals that are no longer than one year apart, and with no end date (e.g. magazines, streaming services).

  2. Instalment: an agreement to bill a customer for a single purchase on a fixed schedule and with an agreed end date (e.g. part payments for a washing machine or TV).

  3. Unscheduled: ongoing billing with no fixed schedule, amount or end date (e.g. pay as you go top ups once a certain threshold is reached).

Useful terms

Usage flag

  • This identifies a stored credential transaction either as the first of a new CIT/MIT agreement or a subsequent transaction within an existing agreement.
  • We populate this on your behalf.

Scheme reference

  • A card scheme generates a unique reference that provides a link to the first transaction where the customer was present and which was authenticated.
  • Every subsequent transactions must include a scheme reference which we return in the most recent response.

The Worldpay approach

Worldpay deals with stored credential transactions by offering you a number of resources to use to initiate an action (e.g. an authorization or payment). To summarize:

  • Our Card on file resources flag all payments as Customer-Initiated Transactions (CIT)

  • Our Recurring resources flag all payments as Merchant-Initiated Transactions (MIT).

Specifically, there are four relevant Worldpay resources available to merchants.

  • Card on file Authorize - this is the resource to use when a customer is initiating a payment using card details already held by the merchant.

  • Card on file Sale - this is used when customers are beginning a payment using stored credentials and the merchant wants to trigger the settlement process straightaway.

  • *Recurring Authorize - merchants use this to initiate a payment using a customer's stored details.

  • Recurring Sale - this action initiates a payment using stored card details and want to begin the settlement process straightaway.

Within our recurring resources, we use the intent field to specify whether the MIT is a subscription, instalment or unscheduled payment (see above). In addition:

  • If a transaction does not include a scheme reference, it is identified to be a first payment.
  • If a scheme reference is included, we identify the transaction as a subsequent payment.
  • Best practice is to use either the original scheme reference or the most recent one - we use the most recent scheme reference in our response to a successful CIT/MIT authorization.

Card numbers vs tokens

What are tokens?

The growth of eCommerce and the need for increasingly robust security measures have been driving forces behind tokenization. For credit card payments, the customer's primary account number is replaced with a randomly-generated reference - a URI. This is the 'token', and it can be passed through the payments system to enable the transaction to be processed without exposing the customer's bank details.

Using tokens

Many merchants use Worldpay to create verified tokens, in which every new token created contains valid customer payment details and is stored credential compliant. Using Worldpay allows us to manage scheme references on your behalf. If you have verified tokens with another provider, you must update your Worldpay token with the scheme reference.

Using plain card numbers

Once you have completed an account verification with Worldpay, you can store the 'next actions' links for a card on file authorization or a recurring authorization. These links contain the necessary scheme reference data to allow Worldpay to manage the scheme reference on your behalf.

You can override Worldpay's stored scheme reference by supplying your own in the body of your request. If you want to manage the scheme reference yourself, you need not store the 'next actions' links from the first CIT. This may appeal to merchants who use more than one payment service provider.

Conclusion

We hope that this article has provided a useful introduction to credit card payments and processes. Further articles will cover specific products, such as verification, and explain their place and function within Access Worldpay.