Stored credentials and Merchant Initiated Transactions

A refresher

Storing customer payment information reduces checkout friction and opens a world of use cases. But this comes with both card scheme and regulatory compliance responsibilities. This article tells you what you need to know in order to benefit from stored credentials.

Written by Joe Connolly
13 October 2025

What is a stored credential?

Within the context of card payments, stored credentials are card details that are retained by you (the merchant or aggregator) or your Payment Service Provider (Worldpay or a third party) in order to perform further payments in the future.

In contrast, a guest checkout (or one-off) payment occurs when a customer provides you with their card details for a single payment, but does not give you permission to store them for future use.

By storing your customer's card details, you can offer a seamless express checkout experience, allowing returning customers to rapidly check out without re-entering their payment information, thereby reducing basket abandonment.

Stored credentials are the basis of repeat payments such as Customer Initiated Transactions (CITs) and Merchant Initiated Transactions (MITs). Neither type of transaction is possible without the customer's prior consent to store their payment information securely.

But what exactly are CITs and MITs?

Customer Initiated Transactions (CITs)

You must store your customer's card details using a compliant Customer Initiated Transaction (CIT). This may be fulfilled using either:

• a card payment authorization - for cases where you take an initial payment
• a card verification - common where your customer adds a card to their account without any payment, or for a subscription free trial.

You may also store payment credentials to take Merchant Initiated Transactions - also known as MITs - in line with an agreement with your customer.

Merchant Initiated Transactions (MITs)

A Merchant Initiated Transaction (MIT) is a transaction initiated by you according to an agreement previously made with your customer. Importantly, the customer is not actively involved in the payment flow.

You can only take MITs after you have successfully processed a compliant CIT as your first payment in the series.

Standing orders

Standing order agreements are a common type of MIT, including the below use cases:

• Subscriptions: 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).

• Installments: 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 entertainment system). Often used by merchants offering "Buy Now, Pay Later" (BNPL) services.

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

Standing order MITs must always use stored card details following the written consent of your customer.

Industry reasons

Alongside standing orders, another category of MITs are those performed for industry practice reasons. Example use cases are:

• No Show: where the customer fails to honor a reservation and you take a fee according to an agreement made at the point of booking.

• Pre-orders: your customer pre-orders goods that will be dispatched outside of the ordinary maximum authorization validity period (between 3-7 days in most cases).

Unlike standing orders, MITs for industry reasons may or may not fall under the stored credentials framework. An example of an MIT being made that does not qualify as the subsequent use of a stored credential would be to fulfil a pre-order that was made using a guest checkout flow.

How can I store payment details?

• Within your own systems: You are fully responsible for PCI-DSS compliance, data security, and maintenance.

• Worldpay Tokens: We store your customer payment information on your behalf, taking on the responsibility for secure storage and reducing your PCI-DSS compliance burden.

• Network Payment Tokens: Use us to store customer payment information direct with card schemes like Visa and Mastercard.

You can use our Checkout SDK to further reduce your PCI burden to the lowest level (SAQ-A), and take advantage of tokenization for repeat payments.

How do I process these payments?

However you decide to store your customers' payment details, you must indicate which of your transactions use stored credentials.

The summary below describes what to use in our Access APIs when processing stored credential payments:

• use the customerAgreement object

• set the usage to first or subsequent

• set the type of agreement made with your customer:

  • subscription
  • installment
  • unscheduled
  • reauthorization
  • resubmission
  • noShow
  • delayedCharge

• for CITs: authenticate the customer using 3DS where required - read our condensed guide on SCA compliance

• for MITs: include the schemeReference from the original CIT where required by the card scheme

What rules do I have to abide by?

For most card schemes, each Merchant Initiated Transaction MIT must be tied back to an original Customer Initiated Transaction. This is done using the scheme's reference returned in the original CIT.

For co-branded cards, you may need the flexibility to process payments using either card scheme. This is common for local card schemes like Cartes Bancaires (France), or eftpos (Australia) – both of which are commonly co-branded with Visa or Mastercard. In this case, best practice is to take the original CIT using the international scheme, before taking subsequent payments with either the international or the local card scheme. Cartes Bancaires will honor the Visa or Mastercard scheme reference to link to an original transaction, while eftpos does not currently employ scheme references to link MITs to an original CIT.