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
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
- 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.
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
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
|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:
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
|Used exclusively with fixed value "ECOMMERCE" for use case
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: