During the initial payment, the customer’s card is securely saved and associated with a Subscription Token. This token can then be used to charge the customer again without requiring them to re-enter their card details.

Recurring payments are commonly used for:

subscriptions
memberships
instalment billing
scheduled payments

Recurring Payment Flow

The recurring payment process consists of the following steps:

Create an initial transaction token
Enable recurrence during the first payment
Verify the payment
Retrieve the customer's subscription token
Charge the saved payment method for future payments

flowchart TD
A[Create Token] --> B[Customer completes payment]
B --> C[Verify Token]
C --> D[Retrieve Subscription Token]
D --> E[Charge Token Recurrent]

Step 1 — Create the Initial Payment Token

Start by creating a transaction using the createToken request.

To enable recurring payments, include the following parameter inside the transaction request:

<AllowRecurrent>1</AllowRecurrent>

This tells the gateway to save the customer's payment details for future recurring charges.

After creating the token, redirect the customer to the hosted payment page to complete the transaction.

Step 2 — Verify the Initial Transaction

Once the customer completes the payment, confirm the transaction using the verifyToken request.

This step ensures the initial payment was successful before attempting to store or reuse the payment method.

Step 3 — Retrieve the Subscription Token

After the successful payment, retrieve the SubscriptionToken using the getSubscriptionToken request.

This token identifies the saved payment method associated with the customer.

The response typically includes:

SubscriptionToken – identifier for the saved payment method
CustomerToken – identifier for the customer

These values are required for future recurring charges.

Step 4 — Charge the Saved Payment Method

To perform a recurring charge:

Create a new transaction token using createToken
Use the chargeTokenRecurrent request with:

TransactionToken
SubscriptionToken

This will charge the customer's saved card without requiring further input from the customer.

Step 5 — Managing Stored Cards

If required, stored payment methods can be removed using the deleteCard request.

This allows merchants to remove a saved card or subscription from the Super Wallet.

Try it as a guided flow

Follow a step-by-step implementation using the Recurring Subscription (Tokenised Payments) recipe.

Related API Endpoints

The following Super Wallet endpoints are used for recurring payments:

Endpoint	Description
`createToken`	Create a transaction token
`verifyToken`	Verify the initial transaction
`getSubscriptionToken`	Retrieve stored payment token
`chargeTokenRecurrent`	Charge a saved payment method
`deleteCard`	Remove stored card

Each endpoint is documented in the Super Wallet API Reference.

Important Notes

The first transaction must include <AllowRecurrent>1</AllowRecurrent> to enable tokenisation.
Recurring payments require a valid SubscriptionToken.
The initial transaction must be successfully verified before performing recurring charges.