Token-based payments

Token-based payments allow you to securely store a customer's payment method and use it for subsequent payments without requiring the customer to enter their payment details again.

The first payment is made while the customer is present and their payment details are collected through the Revup SDK. Once the payment method has been successfully tokenized, Revup returns a payment token that can be used for subsequent payments.

This allows you to separate the payment flow into two stages:

1. Initial payment — the customer is present and provides their payment details.
2. Subsequent payments — the merchant uses the payment token to process additional payments without requiring the customer to enter their payment details again.

Subsequent payments can be initiated by the customer (Customer-Initiated Transactions, or CIT) or by the merchant (Merchant-Initiated Transactions, or MIT), depending on the payment flow.

Payment flow

Initial payment

The first step is to complete an initial payment while the customer is present.

This payment follows the same basic flow as a one-off payment:

1. Create an order through the Revup API.
2. Load the Revup SDK on the payment page.
3. Collect the customer's payment details.
4. Submit the payment.
5. Handle the payment result.

The initial payment is also used to establish the payment method that will be used for future transactions.

For information about the complete initial payment flow, see One-off payments.

Collecting payment details

The customer's payment details must be collected through the Revup SDK.

You can use either:

• Revup Form — a complete payment form.
• Revup Frames — individual payment fields for a custom checkout.

For complete information about configuring and using these integrations, see the SDK.

info

Revup Form and Revup Frames are reusable checkout integrations. They are not specific to token-based payments and can also be used for one-off payments and subscriptions.

Creating a payment token

When the initial payment is configured to create a reusable payment method, Revup generates a payment token that represents the customer's payment method.

The payment token allows your backend to reference the stored payment method without handling or storing the customer's raw payment details.

The token should be stored securely by the merchant and associated with the appropriate customer or account in the merchant's system.

warning

The payment token is sensitive payment information. Store it securely and do not expose it unnecessarily to the customer or client-side application.

The fields required to generate a payment token must be included when creating the initial order.

For the complete list of order fields and their requirements, see Order fields.

Using the payment token

Once a payment token has been generated, it can be used for subsequent payments.

The customer does not need to enter their payment details again. Instead, your backend uses the stored payment token when creating the subsequent payment.

The subsequent transaction must also be classified correctly according to whether the customer is actively initiating the payment or the merchant is initiating it.

Customer-Initiated Transactions (CIT)

A Customer-Initiated Transaction (CIT) is a subsequent payment initiated by the customer.

The customer is actively involved in the payment flow, but their payment details do not need to be entered again because the payment token is used to reference the previously stored payment method.

A typical CIT flow is:

1. The customer starts a new payment.
2. Your backend identifies the customer's stored payment token.
3. Your backend creates the payment using the token.
4. Revup processes the transaction.
5. Your integration handles the payment result.

CIT payments are useful when a customer returns to your application and actively chooses to make another payment using a previously stored payment method.

Merchant-Initiated Transactions (MIT)

A Merchant-Initiated Transaction (MIT) is a subsequent payment initiated by the merchant without the customer actively participating in the payment at the time the transaction is processed.

The merchant uses the payment token created during the customer's initial payment to process the transaction.

A typical MIT flow is:

1. The customer previously completed an initial payment.
2. A payment token was generated and stored.
3. A business event triggers a subsequent payment.
4. Your backend uses the stored payment token.
5. Revup processes the transaction.
6. Your integration handles the payment result.

MIT payments can be used for scenarios where the merchant needs to charge a customer after the original customer-present payment.

info

CIT and MIT describe who initiates the subsequent transaction, not how the customer's payment details are collected.

For more information about the distinction between CIT and MIT and the requirements for each flow, see CIT and MIT.

Payment token lifecycle

The payment token represents the customer's stored payment method and can be reused for subsequent transactions according to the applicable payment rules and configuration.

The general lifecycle is:

1. Initial payment

   • Customer is present.
   • Customer provides payment details.
   • Payment is processed.
   • Payment method is tokenized.

2. Token storage

   • Revup returns the payment token.
   • Merchant securely stores the token.
   • The token is associated with the relevant customer or account.

3. Subsequent payment

   • Merchant retrieves the stored token.
   • Merchant creates a new payment using the token.
   • Revup processes the transaction.

4. Payment result

   • Merchant receives the transaction result.
   • The transaction is handled according to its status.

Handling subsequent payment results

Token-based payments must be handled in the same way as other Revup transactions once the payment has been submitted.

Depending on the payment flow, a transaction can have different statuses, including:

• success
• failed
• in_process
• waiting_user_interaction

Your integration should use the appropriate Revup mechanisms to determine the transaction state and handle the result.

For more information about transaction results, callbacks, notifications, and transaction status, see Handle the payment result.

Token-based payments vs. subscriptions

Token-based payments and subscriptions both use a previously stored payment method, but they serve different purposes.

Token-based payments give your application control over when a subsequent payment is created. Your backend decides when to use the payment token and whether the transaction is a CIT or MIT.

Subscriptions are designed for recurring payments associated with a subscription plan. Once the subscription is configured, the recurring payment process is managed according to the subscription configuration.

If you need to implement recurring payments based on a subscription plan, see Subscriptions.

What's next?

After implementing token-based payments, you can use the same payment infrastructure to support recurring business models through subscriptions.

• Subscriptions — configure recurring payments associated with a subscription plan.
• Handle the payment result — learn how to process transaction results and determine the final state of a payment.