CIT and MIT: what changes for a recurring payment?

Understanding when the customer triggers the payment, and when you do

You are integrating Core Checkout and you want to charge a saved card without the customer being present: subscription, usage-based billing. Yet on every charge the customer is sent back to the payment page that asks for the CVV again. This is expected: you are using the CIT flow, while your need is a MIT.

CIT and MIT, in two lines

CIT (Customer Initiated Transaction): the customer is present and triggers the payment themselves. They may authenticate with 3DS.
MIT (Merchant Initiated Transaction): you trigger the charge server-side, without the customer, against a card that is already registered.

	CIT	MIT
Who triggers	The customer	You, server-side
Customer present	Yes	No
3DS / CVV	Possible	Usually not
Card	New or saved	Saved card required (`cardId`)
Endpoint	`POST /transactions`	POST /transactions/rebill

The rule: who triggers, not who commits

What classifies a transaction is not who committed to it. It is who triggers it, and whether the customer is present at that moment.
The customer commits once, at sign-up. That moment is a CIT. Their consent then authorises a series of charges that you trigger yourself: those are MIT.

A subscription = 1 CIT + N MIT

Sign-up (CIT). The customer registers their card, present, with 3DS. You get a cardId and consent for future charges.
Renewals (MIT). At each due date, you charge the saved card with no customer interaction.

Without MIT, every renewal falls back to CIT. That is exactly why the page keeps asking for the CVV.

Which type for which case

Use case	Type
One-off purchase	CIT
First subscription payment, card registration	CIT
One-click payment, customer present	CIT
Fixed-amount subscription renewal	MIT
Usage-based, variable amount	MIT

Where to find each endpoint in the documentation

CIT, standard payment: POST /transactions
Register a card: POST /cards/register, or capture the cardId from a successful payment callback. Card status via GET /cards/{cardId}, validatedAt field. Note: Apple Pay is for paying, it cannot be saved as a reusable card. For MIT, register a card.
MIT, recurring charge: POST /transactions/rebill. The cardId is required.
Refund: the Refund API in the documentation (refunds run through the CIT flow).
Webhooks: the transaction.status.changed callback.

Reading a MIT charge response

On POST /transactions/rebill:

COMPLETED with paymentPageUrl set to null: the card was charged, nothing else to do. This is the expected off-session charge, no CVV or 3DS.
paymentPageUrl returned: the charge did not go through automatically, the issuer requires validation. You may optionally redirect the customer to that URL.
PENDING: the charge is still processing. Wait for the webhook.

The webhook callback remains the source of truth, never the redirect URLs.

Variable amounts and scheduling

The amount is passed in each rebill call, through the amount field. For usage-based billing, you compute the amount on your side and send it each cycle. Today, you trigger the charge at each due date from your own scheduler. Native scheduling, where Core triggers the due dates for you, is on the roadmap.

Native scheduling, where Core triggers the due dates for you, is on the roadmap.

Updated on: 23/06/2026