Recurring Transactions

A Recurring Transaction / Merchant Initiated Transaction (MIT) is a payment that is triggered by the merchant without the customer being actively present in the checkout flow. This is commonly used for subscription renewals, recurring billing, usage-based charges, installment plans, or delayed charges. Unlike a Customer Initiated Transaction (CIT), an MIT runs off-session, meaning the customer is not interacting with the payment interface at the time of charge.

However, before an MIT can be executed, a Customer Initiated Transaction (CIT) must first take place to establish consent and securely store the payment method.

Step 1: Initial CIT (Consent + Setup for Future Usage)

During the first transaction (when the customer is present), the merchant performs a CIT with the appropriate parameters:

"setup_future_usage": "off_session",
"customer_acceptance": {
  "acceptance_type": "offline",
  "accepted_at": "1963-05-03T04:07:52.723Z",
  "online": {
    "ip_address": "in sit",
    "user_agent": "amet irure esse"
  }
}

These parameters serve two important purposes:

• setup_future_usage: "off_session" signals that the payment method will be reused later when the customer is not present.

• customer_acceptance captures proof of consent including timestamp, IP address, and user agent which is critical for regulatory compliance and network rules.

As part of this CIT, the payment method is tokenized and securely stored (vaulted), and customer consent for future off-session debits is recorded. Once this transaction succeeds, the merchant now has a saved payment_method_id that can be used for future MIT executions.

Step 2: Executing the MIT (Off-Session Charge)

When it is time to charge the customer again for example, during a subscription billing cycle the merchant triggers:

POST /payments
{
  "off_session": true,
  "recurring_details": {...},
  "payment_method_id": "saved_method_id"
}

In this flow:

• off_session: true indicates the customer is not actively participating.

• recurring_details identify this as a recurring or merchant-initiated transaction.

• The saved payment_method_id is used instead of collecting new payment details.

Because the payment method is already stored and consent has been captured, the lifecycle proceeds directly into processing. Conceptually, the state transitions are:

RequiresConfirmation → Processing → Successful (or another terminal state depending on the processor response)

There is no RequiresCustomerAction state in a standard MIT execution because the customer is not redirected for authentication under normal circumstances. However, depending on issuer rules, an off-session attempt may occasionally be declined and require fallback to a fresh CIT flow.