Implementation examples
Java Spring
.NET
Node.js
To tokenize your shoppers payment details, you need to include additional fields when you make a /sessions request. If your request is successful, you receive a webhook containing the token that can be used for subsequent payments. You can use the token when making a payment request to offer returning customers a faster checkout experience.
If you are implementing 3D Secure for PSD2 SCA compliance, use our self-service guide to find out about the PSD2 SCA compliance rules that apply to your business when tokenizing shopper payment details.
Set parameters to flag transactions
When you make a /sessions request to create a token or pay with a token, you must include:
When creating a token that you want to use for more than one type of recurring payment (for example, initially Subscription but in future also CardOnFile), use the recurringProcessingModel that is most appropriate at the time of token creation. In subsequent transactions you can then specify the applicable recurringProcessingModel.
Enable the webhook
When you store a shopper's payment details, you receive an asynchronous RECURRING_CONTRACT webhook. You must enable it on the Standard webhook page and the Webhooks settings page.
The webhook includes the token that you use for payments with the shopper's stored payment details:
| Field | Description |
|---|---|
originalReference |
The pspReference for the payment made to store the shopper's payment details. |
additionalData.recurring.recurringDetailReference |
The token for the stored payment details. You must contact our Support Team to enable this parameter in your response. |
additionalData.recurring.shopperReference |
Your unique shopper reference. Use this to associate the shopper with the token. |
pspReference |
The token for the stored payment details. This is the same as recurringDetailReference. |
Create a token
You can use the /sessions endpoint to create tokens for all recurring payment types, but you need to use the /payments endpoint to make subsequent Subscription and UnscheduledCardOnFile payments with tokens.
Select the tab that fits your business model and follow the integration steps:
Result codes
The outcome of the tokenization request depends on the resultCode you get.
| Result code | Description | Action |
|---|---|---|
| Authorised | The payment was successful, and the payment details were tokenized. | Save the token from the RECURRING_CONTRACT webhook. |
| Pending | The payment is pending, and the payment details haven not been tokenized yet. | Wait for the RECURRING_CONTRACT webhook that you get when the payment reaches the Authorised status. |
| Refused | The payment was refused, and the payment details were not tokenized. | Make another payment request to try tokenizing again. |
When you get the token, store it with your shopper reference so that you and the shopper can use it for recurring payments.
Authorised API response
For some API responses with resultCode: Authorised, the token is included. You can enable the feature to get the token in the API response, when available, in the additionalData.recurring.recurringDetailReference. For example:
Because the API response does not always include the token, we recommend always getting it from the RECURRING_CONTRACT webhook.
Pay with a token
Select the type of recurring payment to make:
Test and go live
To receive the recurringDetailReference in the /sessions response when it is available:
- In your Customer Area, go to Developers > Additional data.
- Select Recurring details.
- Select Save.
In your test environment:
- Test that you get the RECURRING_CONTRACT webhook.
- Store a test token.
- Make a test payment with the token.
Before going live:
Enable the RECURRING_CONTRACT webhook in your live Customer Area.