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 toecommerce
and can be set torecurring
,installment
, orcard_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 thepayment_source
is set torecurring
,installment
, orcard_on_file
and will be ignored for other values or ifpayment_source
is not present.
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 thesecurity_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 thescheme_transaction_id
returned in the initial transaction. If you use a stored payment method we will handle this logic for you automatically.