CIT and MIT

Card payments can be classified according to who initiates the transaction: the customer or the merchant.

Revup supports both Customer-Initiated Transactions (CIT) and Merchant-Initiated Transactions (MIT). This distinction is particularly important when using payment tokens for subsequent payments.

Customer-Initiated Transactions (CIT)

A Customer-Initiated Transaction (CIT) is a payment initiated by the customer.

The customer is actively involved in starting the payment, for example by choosing to make a purchase on the merchant's website.

When a previously generated payment token is used for a CIT, the Order must specify:

{
  "paymentDetails": {
    "type": "consumer_initiated"
  }
}

The consumer_initiated value indicates that:

• the Order is created by the consumer;
• the payment is performed using a previously generated token;
• the customer is initiating the payment.

The merchant does not need to request the customer's card details again when the token is used.

CIT flow

A CIT is generally a single customer-initiated payment rather than a scheduled recurring payment.

Merchant-Initiated Transactions (MIT)

A Merchant-Initiated Transaction (MIT) is a payment initiated by the merchant without the customer actively starting the payment at that time.

In Revup, merchant-initiated recurring payments are represented by:

{
  "paymentDetails": {
    "type": "recurrence"
  }
}

This type of transaction can be used for recurring payments such as subscriptions.

The customer is present during the initial payment, where their payment details are provided and a payment token can be generated. Subsequent payments can then be initiated by the merchant using that token.

MIT flow

Revup does not automatically execute recurring payments according to a schedule. The merchant is responsible for determining when a payment should be made and for creating the corresponding Order.

CIT vs MIT

The main difference between CIT and MIT is who initiates the transaction.

	Customer-Initiated Transaction (CIT)	Merchant-Initiated Transaction (MIT)
Initiated by	Customer	Merchant
Revup paymentDetails.type	consumer_initiated	recurrence
Typical use	Customer makes a new purchase	Subscription or recurring charge
Customer actively starts the payment	Yes	No
Payment token	Can be used	Used for subsequent recurring payments
Merchant creates the Order	Yes	Yes
Scheduling	Customer decides when to pay	Merchant determines when to charge

The distinction can be summarized as:

CIT: the customer starts the payment.

MIT: the merchant starts the payment.

CIT with a payment token

A token can be used when a customer initiates a new payment without having to enter their card details again.

For example, a customer may have previously saved their payment details and generated a payment token. When the customer later starts a new purchase, the merchant can create an Order with:

{
  "paymentDetails": {
    "type": "consumer_initiated"
  }
}

The token identifies the customer's previously stored payment details.

The generateToken field must not be enabled for a non-initial consumer_initiated payment:

{
  "generateToken": false,
  "paymentDetails": {
    "type": "consumer_initiated"
  }
}

If a parentTransactionId is required for the specific payment flow, it identifies the transaction from which the payment is derived.

MIT and recurring payments

MIT is particularly relevant to recurring payments.

The initial payment is performed while the customer is present. The merchant requests token generation:

{
  "generateToken": true,
  "paymentDetails": {
    "type": "recurrence",
    "sequence": "initial"
  }
}

After the successful initial payment, Revup generates the payment token.

For a subsequent recurring payment, the merchant creates a new Order:

{
  "generateToken": false,
  "paymentDetails": {
    "type": "recurrence",
    "sequence": "recurring"
  },
  "parentTransactionId": "INITIAL_TRANSACTION_ID"
}

The parentTransactionId references the transaction associated with the initial recurrence.

The merchant then uses the token when calling the Payment endpoint:

POST /orders/{orderId}/pay

with:

{
  "data": "TOKEN_ID",
  "paymentMethod": "credit_card_token"
}

This allows the merchant to initiate the recurring payment without requiring the customer to provide their card details again.

Initial payment vs subsequent payment

It is important to distinguish the initial customer-present payment from subsequent token payments.

Initial payment

The customer is present and provides their payment details.

For an initial recurrence:

{
  "generateToken": true,
  "paymentDetails": {
    "type": "recurrence",
    "sequence": "initial"
  }
}

The resulting transaction provides the basis for the subsequent recurring payments.

Subsequent CIT

If the customer later initiates a payment using the token:

{
  "generateToken": false,
  "paymentDetails": {
    "type": "consumer_initiated"
  }
}

This is a Customer-Initiated Transaction because the customer starts the payment.

Subsequent MIT

If the merchant later initiates a scheduled recurring payment:

{
  "generateToken": false,
  "paymentDetails": {
    "type": "recurrence",
    "sequence": "recurring"
  },
  "parentTransactionId": "INITIAL_TRANSACTION_ID"
}

This is a Merchant-Initiated Transaction because the merchant starts the payment.

Relationship with payment tokens

CIT and MIT should not be confused with the payment token itself.

The token is a mechanism that allows previously provided payment details to be reused. CIT and MIT describe who initiates the transaction.

The same token can therefore be involved in different payment scenarios:

The distinction is determined by the payment flow and reflected in the Order's paymentDetails.type.

MIT recurrence lifecycle

For a recurring payment sequence, Revup uses the sequence field to identify the stage of the recurrence:

paymentDetails.sequence	Meaning
initial	Initial recurrence where the customer is present and the token is generated.
recurring	Subsequent recurring payment initiated by the merchant.
final	Final payment in the recurring sequence.

A typical MIT recurring flow is therefore:

parentTransactionId

parentTransactionId is important when the payment is derived from a previous transaction.

For recurring payments, subsequent and final recurrences use the transaction ID associated with the initial recurrence.

For example:

{
  "paymentDetails": {
    "type": "recurrence",
    "sequence": "recurring"
  },
  "parentTransactionId": "INITIAL_TRANSACTION_ID"
}

The parentTransactionId should reference the successful initial recurrence that established the recurring payment relationship.

This allows Revup to associate the subsequent recurring transaction with the original transaction.

Payment method for MIT token payments

When the merchant initiates a recurring payment using a payment token, the Payment endpoint uses:

{
  "data": "TOKEN_ID",
  "paymentMethod": "credit_card_token"
}

The data field contains the token ID.

The paymentMethod must be:

credit_card_token

The merchant must also check the resulting transaction status rather than assuming that an HTTP 200 response means that the payment was successful.

Possible transaction statuses include:

• success
• failed
• in_process
• waiting_user_interaction

Summary

CIT and MIT describe who initiates a payment.

• CIT (consumer_initiated) — the customer initiates the payment.
• MIT (recurrence) — the merchant initiates the payment, typically as part of a recurring payment flow.
• The initial payment for a recurring flow is performed while the customer is present and can generate the payment token.
• Subsequent recurring payments can be initiated by the merchant using the token.
• parentTransactionId links subsequent recurring payments to the initial recurrence.
• paymentDetails.sequence identifies the initial, recurring, or final stage of a recurring payment.
• The token is used in the Payment endpoint with paymentMethod: "credit_card_token".

---

For more information, see the Payment tokens, Order fields, Payment API reference, and Token-based payments documentation.