- Getting Started
- Tutorials
- Reference
- API Reference
- Basic Payment
- Authentication
- Card Account
- Virtual Account
- Bank Account
- Customer
- Billing Address
- Shipping Address
- Corporate
- Merchant
- Cart
- Airline
- Tokenization
- Recurring
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Risk
- Point of Sale
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Brands Reference
- API Reference
- FAQ
- Imprint

Tokenization & Registration
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 COPY+PAY tokenization tutorial to collect the payment data securely.
Tokenization allows you to store the payment data for later use. This can be useful for recurring and/or one-click payment scenarios.
This guide describes how you can store the data using our Server-to-Server API, how you can subsequently use the stored card details for a one-click payment and how to delete stored data.
Storing the payment data
There are two methods for creating a token
- Store the data during a payment
- Store the data as stand-alone
Store the data during a payment
A payment's data can be stored at the same time as the payment by sending the createRegistration
parameter with a value of true
. This is done by sending a POST request to the /payments endpoint.
Try it out in the interactive editor below and you will find that you get the additional response parameter registrationId
. This parameter allows you to access the stored payment data during subsequent operations (see use cases below).

Store the data as stand-alone
A registration can also be made by calling the /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

-
Using the stored payment data
Use Case 1: Recurring Payments
Based on the stored account details recurring payments become very simple to achieve.
All you need to do is to add the parameter
recurringType
to your requests:- For the initial payment request you should send the
recurringType
with valueINITIAL
. - For any subsequent payment you should send the
recurringType
with valueREPEATED
.
The Recurring Payment tutorial explains this scenario in more detail.
- For the initial payment request you should send the
-
Use Case 2: One-Click Payments
After storing a customer's account details, it is possible to offer a 'one-click payment' checkout, to simplify subsequent purchases.
Basically you're using the token you've received in the original payment's response in the field
registrationId/id
to reference and even prefill a customer's payment form.The One-click Payment tutorial explains this scenario in more detail.
Deleting the stored payment data
Once stored, a token can be deleted using the HTTP DELETE
method against the registration.id
:
