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 and this payment method cannot be used for multiple difference recurring payments 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 and this payment method cannot be used for multiple difference recurring payments we will handle this logic for you automatically.