Last updated
Last updated
Note: You should be fully PCI compliant if you wish to perform tokenization requests Server-to-Server (as it requires that you collect the card data). If you are NOT fully PCI compliant, you can use the tutorial to collect the payment data securely.
Tokenization allows you to store payment data for later use. This can be useful for recurring payment scenarios.
Note: The token (registrationId )will be valid during 13 months if there is no transaction based on the token. Validity will extend by 13 months for each reference transaction (Debit or Preauthorization + Capture using the token).
This guide describes how you can store the data using our Server-to-Server API, how you can subsequently use the stored card details and how to delete stored data.
There are two methods for creating a token:
Store the data during a payment
Store the data as stand-alone
A payment's data can be stored at the same time as the payment by sending the createRegistrationparameter with a value of true. This is done by sending a POST request to the /v1/payments endpoint.
A registration (RG) can also be made by calling the /v1/registrations endpoint as a stand-alone request (i.e. without requesting a payment).
Contrary to the registration as part of a payment, you directly receive a registration object in your response. Therefore the id to reference this data during later payments is the value of field id
For the initial payment request you should send the recurringType parameter with value INITIAL.
For any subsequent payment you should send the recurringType parameter with value REPEATED.
Once stored, a token can be deleted using the HTTP DELETE method against the registrationId
Based on the stored account details, recurring payments become very simple to achieve. All you need to do is to add the parameter recurringTypeto your request. (see ):