To support recurring billing some connections (mainly card processors) require transactions to be marked accordingly to properly indicate if a transaction is part of a recurring sequence of transactions. It is important to set these indicators correctly to ensure a successful authorization for subsequent transactions.

Recurring transactions can generally be categorized as scheduled payments, unscheduled payments, subscriptions, or installments.

​
Recurring payment flags

To facilitate recurring payments we support three properties that can be set when creating a new card transaction.

  • payment_source - The source of the transaction. This defaults to ecommerce and can be set to recurring, installment, or card_on_file.
  • merchant_initiated - Indicates whether the transaction was initiated by the merchant (true) or if the customer was present (false).
  • is_subsequent_payment - Indicates whether the transaction represents a subsequent payment. Please note this flag is only compatible when the payment_source is set to recurring, installment, or card_on_file and will be ignored for other values or if payment_source is not present.

We will automatically map these 3 properties to your downstream payment service’s properties, where they apply. Currently, these mostly only apply to card processors.

When performing an subsequent MIT transaction without storing the card data in our vault, it’s recommended to provide the previous_scheme_transaction_id where possible. This should represent the scheme_transaction_id returned in the initial transaction.

If you use a stored payment method we will handle this logic for you automatically.

​
Best practices

Please follow the following best practices when creating recurring payments.

  • When created a customer-initiated transaction (CIT), with merchant_initiated=false, providing the security_code (CVV) is highly recommended. Not doing so could result in declined transactions.
  • Before creating a merchant-initiated transaction (MIT), with merchant_initiated=true, it’s highly recommended to make an initial CIT first so the customer gives their authorization. Any subsequent transaction will then be identified as being authorized by this first transaction.
  • When performing a subsequent MIT transaction without storing the card data in our vault, it’s recommended to provide the previous_scheme_transaction_id where possible. This should represent the scheme_transaction_id returned in the initial transaction. If you use a stored payment method we will handle this logic for you automatically.