Sign up


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

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 Abos/Ratenzahlung / Zahlungen/Pay-per-use and with a chance for frictionless flow for Direktkäufe
  • 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:

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

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

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:


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 Token für Abos/Ratenzahlungen gebrauchen and Token für zeitversetzte Zahlungen/Pay-per-use gebrauchen) or at least with frictionless flow (for use case Token für Direktkäufe gebrauchen).

For use case Token für Direktkäufe gebrauchen, 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

Token für Abos/Ratenzahlungen gebrauchen
to indicate that COF information is used to process this payment

cardPaymentMethodSpecificInput.transactionChannel Used exclusively with fixed value "ECOMMERCE" for use case

Token für Abos/Ratenzahlungen gebrauchen
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:

Was this page helpful?

Do you have any comments?

Thank you for your response.