- Get Started
- Guides
- Integrations
- References
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Merchant
- Corporate
- Recipient
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Job
- Risk
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Payment Methods
- Transaction Flows
- Regression Testing
- Data Retention Policy
- Release Notes
- API Reference
- Support
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 COPYandPAY 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
standingInstruction
to your requests:- For the initial payment request you should send the
standingInstruction.mode
with valueINITIAL
andstandingInstruction.type
with valueUNSCHEDULED
andstandingInstruction.source
with valueCIT
. - For any subsequent payment you should send the
standingInstruction.mode
with valueREPEATED
.andstandingInstruction.type
with valueUNSCHEDULED
,standingInstruction.source
with valueMIT
andstandingInstruction.initialTransactionId
with a value as ID received in the response of the initial CIT transaction.
The Recurring Payment tutorial explains this scenario in more detail. Follow the section Card On File for possible
standingInstruction
parameters. - 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
: