Worldline | Recurring payments

Introduction

Recurring payments are the ideal solution for a higher conversion rate. Once your customers have processed a successful transaction including 3-D Secure, you may

Request subsequent transactions on your customers' behalf (i.e. for subscriptions/installments)
Prefill your customers' card data on your payment page

Doing this requires storing sensitive card data. However, to keep your current PCI compliancy level, leave this to us! Our solution allows you to

Store sensitive payment data safely on our platform and use them for planned or unscheduled recurring payments
Enhance your customers’ shopping experience by prefilling fields on the payment page and skipping SCA whenever possible

This feature is available for all credit card payment methods

Understand recurring payments and use cases

The basis for recurring payments is the so-called token. When tokenising a card, we store the card credentials on our platform in a secure vault. In exchange, we return a token to your servers. Storing this token on your server has no impact on your PCI-DSS level. Hence, a token points to a card profile linked to a specific customer. This allows you to re-use the card for subsequent payments to

Smooth out your customers' payment processes by omitting the step to provide most of the card credentials
Skip 3-D Secure authentication in some cases as defined by the SCA ruleset
Initiate payments on your own for (un)scheduled recurring payments

The SCA ruleset and the card scheme’s Credentials-On-File regulation (COF) determine the creation and use of tokens:

You need to request Strong Customer Authentication (SCA) when creating a token. The SCA legitimates the token’s fair use for subsequent transactions without 3-D Secure for Subscriptions/installments / Delayed payments/Pay-per-use and with a chance for frictionless flow for 1-Click-Payments
COF requires you to be consistent and transparent when using tokens. Once you have created a a token, you need to follow the so-called Dynamic Linking principle: You must use a separate token for scheduled recurring payments and another one for unscheduled recurring payments. You are not allowed to cross-use a single token for both scenarios.

Understand use cases

Once you have created a token, you need to use it exclusively for one of the use cases:

Use token for 1-Click-Payments: These cover customer-initated transactions (CIT) for irregular/spontaneous purchases in your webshop, also known as 1-Click-Payments
Use token for subscriptions/installments: These cover regular/planned merchant-initiated transactions (MIT) you request on your customers' behalf for i.e. subscriptions or installments
Use token for delayed payments/Pay-per-use: These cover merchant-initiated transactions (MIT) you request on your customers' behalf for i.e. delayed payments, extra charges or pay-per-use payments
Update token

To ensure the Dynamic Linking principle is applied, your customers' issuers associate every token with a traceId. Our platform sends this traceId in the background to the issuer with every transaction a token is used for. This way the issuers can trace the appropriate use of the token for every transaction. If issuers cannot match a token/traceId with the one used for previous transactions, they might decline the transaction

Process recurring payments

To respect the aforementioned rules, every first/subsequent transaction request requires you to send specific properties along with your request.
Have a look at the relevant properties and how to include them appropriately in specific use cases:

Property	Description
cardPaymentMethodSpecificInput. tokenize token	tokenize: Indicates whether you want to create a token for this transaction Fixed value "true" for creating a new token. Used only when creating the token with the first transaction regardless of the usage pattern token: Points to the card profile stored on our platform you want to use for a recurring payment. Use the value returned in property token from your initial CreatePayment/CreateHostedCheckout request
cardPaymentMethodSpecificInput. unscheduledCardOnFileRequestor unscheduledCardOnFileSequenceIndicator	unscheduledCardOnFileRequestor: COF-specific property that indicates the party initating the transaction. Possible values: "cardholderInitiated": For transactions your customer initiate in your webshop for creating a new token or use case Use token for 1-Click-Payments "merchantInitiated": For transactions you request on behalf of your customers referring to use case Use token for delayed payments/Pay-per-use. For use case Use token for subscriptions/installments, use property isRecurring unscheduledCardOnFileSequenceIndicator: COF-specific property that indicates whether the transaction is the first or subsequent payment of series of recurring transactions. Possible values: "first": For creating a new token "subsequent": For using an existing token. For use case Use token for subscriptions/installments, use property isRecurring
threeDSecure.challengeIndicator	SCA-specific property to indicate the preferred 3-D Secure flow for this transaction Fixed value "challenge-required" for creating a new token to process the transaction with SCA. The SCA legitimates the use of the token for upcoming recurring payments without 3-D Secure (for use cases Use token for subscriptions/installments and Use token for delayed payments/Pay-per-use) or at least with frictionless flow (for use case Use token for 1-Click-Payments). For use case Use token for 1-Click-Payments, we recommend value "no-challenge-requested" to raise the chance of a frictionless flow. Not relevant for any MIT uses cases.
cardPaymentMethodSpecificInput.isRecurring	Used exclusively with fixed value "true" for use case Use token for subscriptions/installments to indicate that COF information is used to process this payment
cardPaymentMethodSpecificInput.transactionChannel	Used exclusively with fixed value "ECOMMERCE" for use case Use token for subscriptions/installments to indicate that COF information is used to process this payment

Find more information about these properties in our Full API reference.

Check out the dedicated chapters to know what to send for each possible use case:

Create token
Use token for 1-Click-Payments
Use token for subscriptions/installments
Use token for delayed payments/Pay-per-use
The same rules apply for the Update token use case

Recurring payments

Introduction

Understand recurring payments and use cases

Understand use cases

Process recurring payments

Was this page helpful?

Do you have any comments?