Recurring Payments

The following 2 API fields are required for recurring payment transactions:

• PaymentServiceType
• CardOnFileScenario

PaymentServiceType

The following table provides several use cases and examples of recurring payments and includes the values for PaymentServiceTypeas well as whether they are:

• customer-initiated-transactions (CIT) or
• merchant-initiated-transactions (MIT).

Use Case	PaymentServiceType	CIT/MIT
Customer pays with card for transaction and does not save card. Example: Customer pays at online merchant, enters card details with CVV and does not save card.	CardNotPresent	N/A
Customer saves card, for current (and future payments) and uses card for transaction. Example: Customer pays at merchant, enters card details with CVV and saves card.	CardNotPresent or CardNotPresentRecurring	CIT
Returning customer uses saved card for subsequent transactions and enters CVV. Example: Returning customer pays at merchant using saved card. Customer confirms card by entering CVV.	CardNotPresent or CardNotPresentRecurring	CIT
Returning customer uses saved card for subsequent transactions and does not enter CVV. Example: Returning customer pays at merchant using saved card. Customer confirms card by entering CVV.	CardNotPresentRecurring	CIT
Merchant processes a payment without direct customer involvement using a saved card (no CVV). Example: Netflix processes monthly subscription payment from customer.	CardNotPresentRecurring	MIT

CardOnFileScenario

The CardOnFileScenario field is required for all transactions that use stored card details. These are also known as Card-on-File (CoF) transactions. This is applicable to the following methods:

• Authorize
• Payment
• Refund

The value of the CardOnFileScenariofield is determined by:

1. The transaction initiator - customer (CIT) or merchant (MIT) and
2. The scenario as listed in the tables below:

Customer initiated transactions

Use case	CardOnFileScenario	Scenario
Customer pays for goods or services and saves their card to their wallet. They agree to an arrangement where further payments can be made by the merchant (a “CoF” arrangement).	CIT1	Card-on-File (first use)
Customer agrees to a CoF arrangement with a merchant for a series of recurring payments of variable amount and fixed frequency and initiates the first payment.	CIT2	Standing Order (variable amount, fixed frequency)
Customer agrees to a CoF arrangement with a merchant for a series of recurring payments with a fixed amount and fixed frequency and is initiating the first payment. The subscription may include a price increase agreement.	CIT3	Subscription (fixed amount, fixed frequency)
Customer agrees to a CoF arrangement with a merchant for an instalment billing plan where the payments for a purchase are split over several fixed amounts with fixed frequency for a specific duration. The customer is initiating the first of these payments.	CIT4	Instalment (fixed amount, fixed frequency, fixed duration)

Merchant Initiated transactions

Use case	CardOnFileScenario	Scenario
Customer agrees to a CoF arrangement with a merchant for use in one or more subsequent transactions.	MIT1	Unscheduled Card-on-File
Customer agrees to a CoF arrangement with a merchant for a series of recurring payments with variable amounts and fixed frequency.	MIT2	Standing Order (variable amount, fixed frequency)
Customer agrees to a CoF arrangement with a merchant for a series of recurring payments with fixed amounts and fixed frequency. May include a price increase agreement.	MIT3	Subscription (fixed amount, fixed frequency)
Customer agrees to a CoF arrangement with a merchant for an instalment billing plan where the payments for a purchase are split over several fixed amounts with fixed frequency for a specific duration.	MIT4	Instalment (fixed amount, fixed frequency, fixed duration)
One or more items in the customer’s purchase order was out of stock at the time of payment. The merchant initiates a separate transaction for the remaining items when ready to be shipped.	MIT5	Partial Shipment
After completing a payment, the customer owes an additional amount to the merchant based on the original transaction terms. Example: customer is charged for extra items used.	MIT6	Related/Delayed Charge
Under the merchant’s guaranteed reservation service policy, the customer owes a no-show fee. Example: customer does not cancel a reservation within the cancellation period.	MIT7	No-show
The merchant’s previous attempt to obtain authorization for a transaction was declined and the bank’s response does not prohibit the merchant from trying again later. Example: merchant initiates an authorization request after receiving a previous “insufficient funds/over credit limit” response.	MIT8	Resubmission

Steps for merchant-initiated-transactions:

In general, the following steps are recommended for MIT recurring card payments (e.g. subscriptions, collections / standing orders, instalments):

Step 1:

Perform an initial transaction to register the card for recurring payments where the customer enters their card details and authenticates the transaction using 3D Secure. This can be done by sending:

• Authorize and Capture (dual message): and save the AuthCode from the Authorize response for subsequent transactions.
  Use case: customer signs up for a subscription and an initial payment is made to the merchant.
• Authorize and Void: save the AuthCode from the Authorize response for subsequent transactions.
  Use case: customer signs up for a subscription and agrees to pay the merchant an amount at agreed-upon intervals. Customer then provides their card details for the merchant to debit their account beginning at an agreed-upon date.
• Payment (single message): save the AuthCodefrom the Payment response for subsequent transactions.
  Use case: customer signs up for a subscription and an initial payment is made to the merchant.

Step 2:

Save customer’s card details using the API AddCard method or Hosted AddCard.

Step 3:

Perform subsequent transactions using the card details without customer interaction.