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 our our 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
2. 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 PSD2 ruleset
- Initiate payments on your own for (un)scheduled recurring payments
The PSD2 ruleset and the card scheme’s Credentials-On-File regulation (COF) determine the creation and use of tokens:
- PSD2 obliges you 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
The image above shows the dynamic linking principle as three separate series of payments linked to individual tokens.
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:
tokenize: Indicates whether you want to create a token for this transaction
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
|unscheduledCardOnFileRequestor: COF-specific property that indicates the party initating the transaction. Possible values:
unscheduledCardOnFileSequenceIndicator: COF-specific property that indicates whether the transaction is the first or subsequent payment of series of recurring transactions. Possible values:
PSD2-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.
||Used exclusively with fixed value "true" for use case
Use token for subscriptions/installments
|cardPaymentMethodSpecificInput.transactionChannel||Used exclusively with fixed value "ECOMMERCE" for use case
Use token for subscriptions/installments
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