> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gr4vy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Common scenarios

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=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`

<Note>
  Embed automatically applies the properties in this scenario for new and stored
  payment methods when the `paymentSource` prop is left to its default value.
</Note>

## 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.

<Warning>
  When doing a subsequent MIT transaction without storing the card data in the 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, this logic is handled for you automatically.
</Warning>

## 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.

<Warning>
  When doing an subsequent MIT transaction without storing the card data in the 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, this logic is handled for you automatically.
</Warning>

## 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`

<Warning>
  When doing an subsequent MIT transaction without storing the card data in the 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, this logic is handled for you automatically.
</Warning>

## 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`

<Warning>
  When doing an subsequent MIT transaction without storing the card data in the vault, providing the
  `previous_scheme_transaction_id` where possible is recommended. This should represent the `scheme_transaction_id` returned in the initial
  transaction.

  If you use a stored payment method this logic is handled for you automatically.
</Warning>