Correctly classifying a charge is essential for ensuring high approval rates and accurate reporting. The Silverflow API uses the charge.type object to define the specific characteristics of a charge. It is composed of three distinct fields: intent, cardEntry, and order. This guide outlines how to combine these fields to correctly represent various payment scenarios.

One-Off Customer-Initiated Charges (CIT)

A one-off Customer-Initiated Transaction (CIT) is a standalone transaction pursued by the cardholder. The table below details common scenarios and the corresponding type field values.

Use case	Description	`type.intent`	`type.order`	`type.cardEntry`
Online Purchase	A standard e-commerce checkout for goods or services.	purchase	checkout	e-commerce, token
Pre-Order	A pre-authorization to reserve funds for, such as booking travel or accommodation.	reservation	checkout	e-commerce, token
Account Status Inquiry	A zero-value check to confirm that a cardholder's account is valid and in good standing.	account-status	checkout	e-commerce, token, card-on-file, token-on-file
One-Click	An e-commerce transaction where the customer uses stored payment details to make a purchase.	purchase	one-click	card-on-file, token-on-file
MOTO	A transaction where a merchant enters card details provided by a customer via Mail Order or Telephone Order.	purchase	mail, phone	manual
Merchandise Return	A refund that is not linked to a previous transaction (unreferenced refund).	refund	checkout	e-commerce, token, card-on-file, token-on-file

Recurring & Merchant-Initiated Charges (MIT)

A Merchant-Initiated Transaction (MIT) is a charge processed using stored credentials, based on a prior agreement with the cardholder. To establish this agreement, an initial Customer-Initiated Transaction (CIT) must be performed first. This initial charge verifies the card and sets up the payment sequence. Subsequent MITs can then be processed using the credentials from that initial transaction.

Use case	Description	type.intent	type.order	type.cardEntry (Initial CIT)	type.cardEntry (Subsequent MIT)
Standing Instruction or Recurring	A series of recurring payments with a fixed amount and frequency, such as a subscription service.	purchase	recurring	e-commerce, token, card-on-file, token-on-file	card-on-file, token-on-file
Standing Order	A series of recurring payments with a variable amount and fixed frequency, such as a utility bill.	purchase	standing-order	e-commerce, token, card-on-file, token-on-file	card-on-file, token-on-file
Installment	A payment that is part of a series of fixed-amount transactions to pay for a larger purchase over time.	purchase	installment	e-commerce, token, card-on-file, token-on-file	card-on-file, token-on-file
Unscheduled (UCOF)	An irregular transaction using stored card details, such as an automatic account top-up or a rideshare fee.	purchase	ucof	e-commerce, token, card-on-file, token-on-file	card-on-file, token-on-file

Best Practices for Merchant-Initiated Transactions (MIT)

Establish the Cardholder Agreement (Initial CIT)

You must perform an initial Customer-Initiated Transaction (CIT) before you can run any subsequent MITs. Create it with the Create Charge endpoint. When you create the initial CIT:

Apply Strong Customer Authentication (SCA): Authenticate the initial CIT with 3D Secure where PSD2 SCA applies.
Flag the CIT correctly: Set type.intent, type.order and type.cardEntry for your use case (see the table above).
Save the network references: Store the identifiers returned for the initial transaction. You need them to link every later MIT to this CIT.
- Visa: initialTransactionIdentifier
- Mastercard: initialTraceId and transactionLinkId
- American Express: originalTransactionIdentifier
- Discover: originalNetworkReferenceId and originalAmountValue
- Diners: originalNetworkReferenceId and originalRetrievalReferenceNumber and originalAmountValue
Store the credentials: After a successful, authenticated CIT, you can store the cardholder's payment details for future use. Silverflow's processor tokenization keeps the card data secure and limits your PCI-DSS scope.

Perform the MIT Charge

The MIT charge can be performed via the MIT Charge endpoint. When you create the initial CIT:

Reference the Initial Transaction: You must link the MIT to the original, authenticated CIT. Use the charge.initialTransactionReferences field to provide the respective card network identifiers from the initial CIT.
Provide the 3DS result only if you perform 3RI: Send threeDsAuthenticationResult only if you perform a 3RI for the MIT. Do not send the 3DS result from the initial CIT.

MITs with Apple Pay and Google Pay

You can run MITs on cards that were first added through Apple Pay or Google Pay. The cardholder must authenticate the initial CIT with the wallet.

Initial CIT: Create the charge with type.cardEntry set to token. Set tokenDetails.type to apple-pay or google-pay and send the wallet's threeDsCryptogram.
Store the token and references: Keep the wallet token (MPAN or DPAN), and the network references from the initial CIT (see above).
MIT: Set type.cardEntry to token-on-file and pass the stored wallet token in card. Provide the same initialTransactionReferences.

You do not need a fresh wallet cryptogram for the MIT, so you can leave tokenDetails out. If you do send a fresh cryptogram then send tokenDetails with type set to apple-pay or google-pay and the threeDsCryptogram.

In case of a Google Pay integration where you receive and store the raw credentials and not the wallet token, perform the MIT charge with type.cardEntry to card-on-file.