Search

Are you looking for test card numbers?

Would you like to contact support?

Online-payment icon

Tokenization

Implement recurring payments and subscriptions with Adyen.

Adyen's tokenization service allows you to securely store one or more recurring payment details per shopper. We support over 25 card and local payment methods, including major card brands, ACH, and SEPA direct debit. For a list of all supported payment methods, see the Payment methods.

With our tokenization service, you can:

  • Give shoppers the option to store their card details for a faster checkout experience on their next transaction.
  • Offer shoppers their stored card details as a payment method for their next transaction.
  • Create tokens in the first transactions for a subscription or a contract.
  • Submit subsequent payments for subscriptions or for contracts with non-fixed time intervals (for example, auto account top-ups).

Tokens are stored only at the merchant level by default. If you would like to have these stored at your company level instead, reach out to Support Team.

If you wish to use network tokens issued by card networks like Mastercard and Visa for your payments, see Network tokenization.

Recurring transaction types

A recurring transaction can be:

  • A transaction that is part of a subscription or contract.
  • A transaction where the shopper agrees to store their card details.
  • Or a transaction where the shopper uses the card details they stored previously to pay.

We use the shopperInteraction and recurringProcessingModel parameters in your payments request to identify the type of recurring transaction.

Shopper interaction

The shopperInteraction specifies how the shopper provided their card details for the transaction. The possible values for online payments are:

  • Ecommerce: Transactions where shoppers enter their card details.
  • ContAuth: Transactions using previously stored card details, which include the card number and card expiry date.

For the complete list of shopperInteraction values, see our API reference.

Recurring processing model

The recurringProcessingModel defines the recurring payment type. Possible values are:

  • Subscription: A series of transactions with fixed or variable amounts, following a fixed time interval. If the recurringProcessingModel not set in the payment request for shopperInteraction ContAuth, this will be the default value.
  • CardOnFile: Transactions where a shopper stores card details, and transactions where the shopper purchases from your website or app at a later time using the previously stored card details.
  • UnscheduledCardOnFile: Contracts that occur on a non-fixed schedule using stored card details. For example, automatic top-ups when cardholder's balance drops below certain amount.

Recurring transactions based on business models

Depending on your business model, set the shopperInteraction and recurringProcessingModel to the values described below.

Business model Transaction type Payment request parameters
Shopper Interaction Recurring Processing Model
Online purchase with shopper in-session

One-off online purchase where a shopper enters card payment details on the checkout page. The shopper does not want to store their payment details for future use. Ecommerce

Online purchase where shopper agrees to store card details for future use on your website or app. This can be a zero-value transaction.

Ecommerce CardOnFile

Online purchase where shopper is actively making a purchase using their previously stored card payment details and provides their CVC/CVV.

ContAuth CardOnFile
Subscriptions First transaction where shopper signs up for a subscription and agrees with the terms and conditions. The terms and conditions should describe the policy for later subsequent charges, for example, fixed or variable amounts. The shopper agrees that the merchant will use their stored payment details for future subscription charges. This can be a zero-value transaction. Ecommerce Subscription
Subsequent subscription charges as described in the initial terms and conditions during the sign-up transaction, following equal time intervals or a fixed schedule. The shopper is not in-session and the transaction is initiated by the merchant. For example, music and TV streaming services subscription payments. ContAuth Subscription
Contracts with non-fixed time interval, such as auto account top-ups Initial transaction where shopper agrees to the terms and conditions of later subsequent charges. The shopper agrees that the merchant will use their stored payment details for future top-ups following non-fixed time intervals. This can be a zero-value transaction. Ecommerce UnscheduledCardOnFile
Subsequent charges as described in the initial terms and conditions during the sign-up transaction, following non-fixed time intervals or a changeable schedule. The shopper is not in-session and the transaction is initiated by the merchant. For example, mobile credits automatic top-ups. ContAuth UnscheduledCardOnFile

If you are implementing 3D Secure for PSD2 SCA compliance and would like to know how the regulation will impact your recurring business model, see SCA requirements based on business model.

Next steps