"Card-on-file" Payment Scenarios

1. COF / MIT product offers for merchants

PayXpert provides several MIT (Merchant‑Initiated Transaction) setups depending on your PCI posture and who manages rebills / card data.

Merchant profile	Solution

Merchant profile	Solution
Non‑PCI merchants who do not want to manage rebills	Configure a Subscription Offer in Central → use a CIT to initiate MIT chain → payXpert manages MITs + retries
Non‑PCI merchants who want to manage rebills OR PCI merchants w/o tokens	Use a CIT to initiate MIT chains → merchant sends MITs using the Rebill operation (merchant manages retries)
PCI merchants who manage card info / tokenisation themselves (“external token”)	Combinations of: do only CIT with payXpert, only MIT with payXpert, or both CIT & MIT with payXpert using full card data

When sending a transaction, you must populate the payment.context field to tell payXpert which payment case applies.

#	Business case (merchant view)	`payment.context` value

#	Business case (merchant view)	`payment.context` value
1	CIT – single payment (not COF, one‑off purchase)	`singlePayment`
2	CIT – subscription chain initiation (first payment of a subscription)	`subscriptionInitiation`
3	CIT – split / instalment payment initiation (first instalment)	`installmentInitiation`
4	CIT – unscheduled MIT chain initiation (first payment creating a uCOF)	`unscheduledMitInitiation`
5	MIT – subscription iteration (subsequent fixed subscription charges)	`subscriptionIteration`
6	MIT – instalment iteration (2nd, 3rd… instalment of a known total)	`installmentIteration`
7	MIT – unscheduled MIT (ad‑hoc/variable follow‑up charges)	`unscheduledMitIteration`

Use when

Flow

Configure subscription offer in Central
- Create an offer in Central:
  Subscription offers
- You receive an offerID.
- subscriptionType determines chain type:
  - "normal" → recurring payments
  - "partpayment" → instalments / split payments
  - "infinite" → uCOF payments
Initiate MIT chain with a CIT
- Via API, send a Sale or Authorize with:
  - payment.context = subscriptionInitiation / installmentInitiation / unscheduledMitInitiation
  - offerID = ID of configured subscription offer.
- Internally (e.g. Carte Bancaire), these currently go as “single payment”; this can increase soft declines because issuers expect a properly flagged COF CIT.
MITs are triggered by payXpert
- payXpert runs Rebill operations automatically.
- Retry strategy is managed by payXpert (details in Central / docs).
- You can monitor in Central:
  - Subscriptions page: Subscriptions
  - Or via API > subscription endpoints.

Use when

Flow

Initiate MIT chain with CIT
- Via API, send Sale or Authorize with:
  - payment.context for initiation (subscriptionInitiation, installmentInitiation, unscheduledMitInitiation)
  - Subscription characteristics in subscriptionXXX fields:
    - subscriptionType
    - rebillAmount
    - rebillPeriod
    - rebillMaxIteration
    - trialPeriod
- You receive the transactionId of the CIT (this is your chain anchor).
- API doc: https://developers.payxpert.com/gateway/transactions-ccsale/
Trigger MITs via Rebill
- For each MIT, call Rebill with:
  - transactionId = CIT from step 1
  - amount = rebill amount
- No card data is required (card is on file with payXpert).
- API doc: https://developers.payxpert.com/gateway/transactions-rebill/
- Retry strategy is fully managed by you (additional Rebill calls).
- Required configuration: “On the fly subscriptions via API = Enabled” on the originator.

Use when

Card data you must store

Scheme transaction IDs

payXpert’s schemeTransactionId has a leading digit identifying the scheme.
You must handle this for both:
- CIT response: schemeTransactionId
- MIT request: originalSchemeTransactionId

Acquirer note

Ideally use the same acquirer for both CIT and MIT.
For 2025‑11‑25, if you use external 3DS + external tokenisation, some controls must be removed at terminal level:
- “3DS process belonging” should not restrict these transactions.

Scenario: orchestration – payXpert for SCA/CIT; other PSP for MITs.
CIT request: Sale or Authorize with subscription fields:
- subscriptionType, rebillAmount, rebillPeriod, rebillMaxIteration, trialPeriod
CIT response returns:
- schemeTransactionId
- processingScheme
You pass this schemeTransactionId to your other PSP for MITs.
To receive schemeTransactionId in the response, a specific option must be configured on the originator (see page).

Scenario: orchestration – other PSP does initial CIT & COF flagging.
You call payXpert Sale or Authorize for each MIT with:
- All standard fields: amount, payment.context, etc.
- Card data (PAN, expiry, cardholder name)
- originalSchemeTransactionId = scheme transaction ID from the initial CIT (at other PSP).
Dedicated doc:
Processing MITs in "external MIT mode"

For PCI merchants who want all COF traffic at payXpert.
Workflow = CIT creation flow (“Do only the CIT with payXpert”) → then MIT processing flow (“Do only the MIT with payXpert”) using the same schemeTransactionId.