Create token

Tokens

Using our tokenization service you can tokenize re-usable payment data like card data, bank account data including Direct Debit Mandates and PayPal BillingAgreementIDs. The main purpose for tokens is re-use of payment details. The additional benefit is that you do not need to store any sensitive payment details on your server, while still having the benefit to be able to re-use them. This allows you to process recurring card transactions without actually having access to the real card data.

Tokens can be used for two types of transactions:

• Recurring: Automatically charging your consumer in a regular, e.g. monthly, time frame;
• One-off: Charge the consumer without the consumer having to re-enter all of their payment details.

The second scenario can be used to facilitate a one-click checkout solution, that would still allow the consumer to enter only their CVV value for a card transaction. CVV values can't be tokenized as they are not allowed to be stored at all.

Besides the re-use of payment data, tokens have one other major use-case: Direct Debit Mandates. Especially SEPA Direct Debit transactions require that the mandate for the transactions is managed through a token with an associated mandate. Mandates are created in one go with the token, but can have a state that requires that they are approved before they can be used. As the mandate process is in most cases an offline process the approval will allow you to set the location and date where and when the mandate was signed by the consumer. Without an approved SEPA mandate you will not be able to process any payments regarding this mandate.

Request

Use this call to tokenize payment details. Note that only basic input validation is performed as no actual transaction is processed. We do not check the validity of the payment details with any of its acquirers or third party payment processors. If you want to only tokenize payment details that have been successfully processed it is advised to create tokens using the tokenize action on successful payments. The payload can, next to the paymentProductID contain one of the following types of objects to tokenize:

• card data
• SEPA Direct Debit data (including mandate information)
• Non SEPA Direct Debit data
• eWallet data

Tokenization using Encrypted Customer Input

Note: this applies only for sending encrypted customer card data, and cannot be used to tokenize (SEPA) Direct Debit or eWallet data

The mandatory and optional fields are the same as for the card group when not using the encrypted customer input.

• cardNumber
• expiryDate
• countryCode

• cardholderName
• additionalInfo
• city
• houseNumber
• stateCode
• street
• zip
• firstName
• surname

PayloadCreateTokenRequest

Request example

Responses

When we are able to tokenize the payment details two possible responses can occur:

• HTTP Response 200 is returned when you try to tokenize card details for a card that has already been tokenized in the past
• HTTP Response 201 is returned when the system successfully created a new token

Response 200 - OKCreateTokenResponse

An HTTP 200 response indicates that the card data was previously tokenized. The previous token is returned again. The evaluation regarding duplication is done purely on the card number. Please note that it is possible that the data other than the card number is different from the stored data, in that case you may need to update the token with the new data.

Response example

Response 201 - CreatedCreateTokenResponse

An HTTP 201 response indicates that the data was successfully tokenized and the newly created token is returned.

Response example

Response 400 - Bad requestErrorResponse

Response example

Response 403 - UnauthorizedErrorResponse

When something is wrong with your credentials you will get a 403 response. This could happen when your account is not allowed to tokenize any payment data.

Response example