REST API | Visa Platform Connect

Customer-Initiated Recurring Payment with
TMS

A recurring payment is a credentials-on-file (COF) transaction in a series of payments that you bill to a customer at a fixed amount, at regular intervals that do not exceed one year between transactions. The series of recurring payments is the result of an agreement between you and the customer for the purchase of goods or services that are provided at regular intervals.
Mastercard uses standing order and subscription payments instead of recurring payments. See Mastercard Standing Order Payments and Mastercard Subscription Payments.

Prerequisites

The first transaction in a recurring payment is a customer-initiated transaction (CIT). Before you can perform a subsequent merchant-initiated transaction (MIT), you must store the customer's credentials for later use. Before you can store the customer's credentials, you must get their consent to store their private information. This is also known as establishing a relationship with the customer.

Recurring Billing Service for Recurring Payments

IMPORTANT
Do not use this document for the Recurring Billing service.
Use the
Recurring Billing Developer Guide
. When you use the Recurring Billing service,
Cybersource
saves and stores payment credentials for recurring transactions, ensuring compliance with COF best practices.

Creating a
TMS
Token

When sending the initial CIT, you can create a
TMS
token to store the customer's credentials for the subsequent MITs. To create a
TMS
token, include the
processingInformation.actionTokenTypes
field in the authorization request. Set the field to one of these values based on the
TMS
token type you want to create:
Customer
Customer tokens store one or more customer payment instrument tokens and shipping address tokens.
Including a customer token in subsequent MITs eliminates the need to include billing information, card information, and the previous transaction's ID.
"processingInformation": { "actionTokenTypes": [ "customer" ]
For more information about this
TMS
token type, see Customer Tokens in the
Token Management Service
Developer Guide
.
Payment Instrument
Payment instrument tokens store an instrument identifier token, card information, and billing information. Payment instruments are not linked to a customer token. Including a payment instrument in subsequent MITs eliminates the need to include billing information, card information, and the previous transaction's ID.
"processingInformation": { "actionTokenTypes": [ "paymentInstrument" ]
For more information about this
TMS
token type, see Payment Instrument Token in the
Token Management Service
Developer Guide
.
Instrument Identifier
Instrument identifier tokens store a PAN. Including an instrument identifier in subsequent MITs eliminates the need to include a PAN and the previous transaction's ID.
"processingInformation": { "actionTokenTypes": [ "instrumentIdentifier" ]
For more information about this TMS token type, see Instrument Identifier Token in the
Token Management Service
Developer Guide
.
Instrument Identifier, Payment Instrument, and Customer Identifier
You can also create multiple
TMS
token types in the same authorization. This example includes an instrument identifier, a payment instrument, and a customer token in the same authorization:
"processingInformation": { "actionTokenTypes": [ "instrumentIdentifier", "paymentInstrument", "customer" ]

Endpoint

Production:
POST
https://api.cybersource.com
/pts/v2/payments
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments