The following is a list of common scenarios that merchants use when creating
transactions. Your use case depends 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=ecommercemerchant_initiated=falseis_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_filemerchant_initiated=falseis_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_filemerchant_initiated=falseis_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_filemerchant_initiated=falseis_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_filemerchant_initiated=trueis_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.
If you don’t store the card with Gr4vy, provide previous_scheme_transaction_id and previous_transaction_link_id
on each subsequent MIT transaction where possible. Use the scheme_transaction_id and transaction_link_id returned
on the customer-initiated transaction that set up the series.If you use a stored payment method, Gr4vy sends the IDs stored on the payment method for you. See
Scheme transaction IDs on stored payment methods. Installments
A customer at checkout agrees to pay for goods over a certain amount of
installments.
payment_source=installmentmerchant_initiated=falseis_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=installmentmerchant_initiated=trueis_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.
If you don’t store the card with Gr4vy, provide previous_scheme_transaction_id and previous_transaction_link_id
on each subsequent MIT transaction where possible. Use the scheme_transaction_id and transaction_link_id returned
on the customer-initiated transaction that set up the series.If you use a stored payment method, Gr4vy sends the IDs stored on the payment method for you. See
Scheme transaction IDs on stored payment methods. Installments split by the issuer
An installment series, as in the Installments scenario, is a set of separate transactions that you
charge over time. In some markets, the card issuer or acquirer can instead split one payment into installments. You
create a single customer-initiated payment, and the buyer repays it in installments.
To request this, set installment_count to the number of installments. The payment itself is a one-off
customer-initiated payment, so don’t set payment_source to installment, which marks a series of
merchant-initiated payments.
installment_count=3payment_source=ecommercemerchant_initiated=falseis_subsequent_payment=false
The value can be from 1 to 100 and has no default. Gr4vy passes it to the payment service on connections that
support issuer-based installments, such as Adyen,
dLocal, Fiserv,
Stripe, and Worldpay WPG.
Subscriptions
A customer at checkout agrees to pay for a regular recurring subscription for a
certain amount, paid at a fixed interval.
payment_source=recurringmerchant_initiated=falseis_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=recurringmerchant_initiated=trueis_subsequent_payment=true
If you don’t store the card with Gr4vy, provide previous_scheme_transaction_id and previous_transaction_link_id
on each subsequent MIT transaction where possible. Use the scheme_transaction_id and transaction_link_id returned
on the customer-initiated transaction that set up the series.If you use a stored payment method, Gr4vy sends the IDs stored on the payment method for you. See
Scheme transaction IDs on stored payment methods. 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=motomerchant_initiated=falseis_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_filemerchant_initiated=trueis_subsequent_payment=true
A transaction with payment_source=moto doesn’t store a scheme transaction ID on the payment method, even when the card
is stored. Provide previous_scheme_transaction_id and previous_transaction_link_id on each subsequent MIT
transaction where possible, using the scheme_transaction_id and transaction_link_id returned on the MOTO transaction.
See Scheme transaction IDs on stored payment methods. 
