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

> Set the recurring payment flags for common checkout scenarios, from one-off payments to subscriptions and installments.

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

<Note>
  Some payment services set how a stored payment method can be used from the first transaction that
  stores it, based on its `payment_source`. On these services, a payment method first stored with
  `card_on_file` may not support later merchant-initiated recurring or installment payments. Pick the
  scenario that matches every way you plan to charge the payment method, and check the
  [connection](/connections/payments/overview) for your payment service.
</Note>

## 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>
  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](./overview#scheme-transaction-ids-on-stored-payment-methods).
</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>
  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](./overview#scheme-transaction-ids-on-stored-payment-methods).
</Warning>

## Installments split by the issuer

An installment series, as in the [Installments](#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=3`
* `payment_source=ecommerce`
* `merchant_initiated=false`
* `is_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](/connections/payments/adyen-card),
[dLocal](/connections/payments/dlocal-card), [Fiserv](/connections/payments/fiserv-card),
[Stripe](/connections/payments/stripe-card), and [Worldpay WPG](/connections/payments/worldpaywpg-card).

## 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>
  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](./overview#scheme-transaction-ids-on-stored-payment-methods).
</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>
  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](./overview#scheme-transaction-ids-on-stored-payment-methods).
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.