Demystifying card payments pt.2

An overview of repeat payments


The typical card transaction outlined in our"Demystifying card payments pt.1assumes 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)

This is when a customer makes a payment using card details already stored with you. There’s no particular pattern or schedule and it’s most common after you have asked permission from a customer to store their details for future ‘one-click’ purchases.

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).

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.


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.

Got any feedback or bugs to report?