The following is a list of common scenarios that merchants use when creating transactions. Your use case will really depend on how your checkout is handled.

​
E-commerce

A customer provides their payment details for a one-off payment and the payment method is not stored. The transaction is created directly after the payment details are provided.
  • payment_source=ecommerce
  • merchant_initiated=false
  • is_subsequent_payment=false
This is the end of this scenario. There is no merchant-initiated part.

​
Fast checkout

A customer at checkout agrees to store their card for quicker checkouts in the future.
  • payment_source=card_on_file
  • merchant_initiated=false
  • is_subsequent_payment=false
The same customer then returns to the checkout at a later point and decides to checkout with this stored card.
  • payment_source=card_on_file
  • merchant_initiated=false
  • is_subsequent_payment=true
Embed automatically applies the properties in this scenario for new and stored payment methods when the paymentSource prop is left to its default value.

​
Unscheduled payments

A customer at checkout agrees to store their card for future transactions, and allows the merchant to initiate an unscheduled transaction in the case that there are any additional charges they incur on their account.
  • payment_source=card_on_file
  • merchant_initiated=false
  • is_subsequent_payment=false
At a later point, this same customer might incur some extra charges on their account. The merchant can then charge the card while the customer is not present.
  • payment_source=card_on_file
  • merchant_initiated=true
  • is_subsequent_payment=true
The key difference between this scenario and a subscription is that a subscription is generally handled as a scheduled payment with a predictable amount and recurrence, where an unscheduled payment can occur outside of a schedule and for any amount.
When doing 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.

​
Installments

A customer at checkout agrees to pay for goods over a certain amount of installments.
  • payment_source=installment
  • merchant_initiated=false
  • is_subsequent_payment=false
A customer is then charged for each subsequent installment by the merchant when the payment is due. The customer is not present for this transaction.
  • payment_source=installment
  • merchant_initiated=true
  • is_subsequent_payment=true
The key difference between this scenario and a subscription is that an installment has a finite number of transactions, where a subscription is generally recurring until the subscription is canceled.
When doing 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.

​
Subscriptions

A customer at checkout agrees to pay for a regular recurring subscription for a certain amount, paid at a fixed interval.
  • payment_source=recurring
  • merchant_initiated=false
  • is_subsequent_payment=false
This customer is then charged for each subsequent payment when the payment is due. The customer is not present for this transaction.
  • payment_source=recurring
  • merchant_initiated=true
  • is_subsequent_payment=true
When doing 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.

​
MOTO

Customer’s card data is collected via mail (Mail Order) or telephone (Telephone Order) and typed in by a support agent or an automated scanning process.
  • payment_source=moto
  • merchant_initiated=false
  • is_subsequent_payment=false
Optionally, a merchant can then charge the customer when a recurring payment is due. The customer is not present for this and so the transaction should be created as a MIT transaction.
  • payment_source=recurring, installment, or card_on_file
  • merchant_initiated=true
  • is_subsequent_payment=true
When doing 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.