Payment model field

The PaymentModelfield is included in /checkout and /openContract requests. It tells Reach, the payment processor, and the issuing bank what kind of transaction is being submitted. A PaymentModel value has two parts. The first part is the initiator—who submits the transaction. It can be one of:

• Consumer-initiated transaction (CIT)
• Merchant-initiated transaction (MIT)
• Mail or telephone order (MOTO)

The second part describes whether stored payment credentials are being created, reused, or not involved in the transaction, and if being created, whether future charges follow a fixed schedule. It can be one of:

Why the PaymentModel field matters

Correctly setting the PaymentModel field improves authorization rates, reduces unnecessary 3DS challenges on stored-card transactions, and ensures the transaction is flagged correctly to the card issuer:

PaymentModel values

Pass a PaymentModel value in the request body of every /checkout or /openContract request.

Consumer-initiated (CIT)

The cardholder is present and actively participates in the transaction (for example, completing checkout in their browser).

Merchant-initiated (MIT)

The cardholder is not present. The merchant charges stored payment details based on a prior agreement established by a CIT-Setup-* or MOTO-Setup-* transaction.

Mail or telephone order (MOTO)

The cardholder provides their payment details to the merchant, who keys the transaction (for example, by phone or mail order). Use a MOTO payment model when the merchant needs to indicate that the channel is a keyed transaction rather than a consumer's own online checkout.

Subsequent charges against a contract opened with a MOTO-Setup-* transaction use the matching MIT-Subsequent-* or CIT-Subsequent-Unscheduled value, as shown in the Setup-to-subsequent pairings section.

Choosing the right PaymentModel value

The right value depends on what the transaction is doing now and what is intended for the future. Setup transactions must be paired with the matching subsequent transaction.

One-time purchases

Use CIT-One-Time (or MOTO-One-Time if the transaction is agent-keyed) for one-time purchases where the customer card is not saved.

For one-time purchases where the customer's card is saved for future use (by consumer, not the merchant), provide CIT-Setup-Unscheduled as the PaymentModel value.

When a consumer makes another purchase using the saved card, use CIT-Subsequent-Unscheduled and pass the contract ID provided from the previous CIT-Setup-Unscheduled response.

{
	...
  "PaymentModel": "CIT-One-Time",
  "OpenContract": false,
	...
}

{
	...
  "PaymentModel": "CIT-Setup-Unscheduled",
  "OpenContract": true
	...
}

{
	...
  "PaymentModel": "CIT-Subsequent-Unscheduled",
  "ContractId": "<contract id from setup>"
	...
}

Subscriptions

First, use CIT-Setup-Scheduled to establish the contract between the merchant and the consumer. For each following subscription renewal, use the MIT-Subsequent-Scheduledvalue.

{
  ...
  "PaymentModel": "CIT-Setup-Scheduled",
  "OpenContract": true,
 ...
}

{
 ...
  "PaymentModel": "MIT-Subsequent-Scheduled",
  "ContractId": "<contract id from setup>"
 ...
}

Account top-ups or installments

For instances where the card is stored and charged by the merchant at a later unscheduled time—such as account top-ups or future installment payments—use CIT-Setup-Unscheduled-MIT to establish the contract.

For the subsequent merchant-initiated charges, use MIT-Subsequent-Unscheduled and pass the contract ID provided in the previous CIT-Setup-Unscheduled-MIT response.

{
  ...
  "PaymentModel": "CIT-Setup-Unscheduled-MIT",
  "OpenContract": true
 ...
}

{
 ...
  "PaymentModel": "MIT-Subsequent-Unscheduled",
  "ContractId": "<contract id from setup>"
 ...
}

Setup-to-subsequent pairings

For each use case, provide the initial setup PaymentModel value to establish a contract, followed by the corresponding value for subsequent transactions. Provide the ContractId when required.

Note that mismatched pairings can result in declines.

Querying PaymentModel after a transaction

Use the /query endpoint to retrieve the PaymentModel that was applied to a completed transaction.

This is useful for confirming how Reach classified a request when PaymentModel was omitted from the original call.

For further details on Reach's Checkout API, see the Checkout API page and API reference pages. For details on storing payment credentials, see /openContract.