CIT and MIT: what changes for a recurring payment?

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

You want to charge a saved card without the customer being present: a no-show fee, a balance top-up, usage-based billing or a subscription. Yet on every charge the customer is sent back to the payment page, which 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. A CVV or 3DS step is possible.
MIT (Merchant Initiated Transaction): you trigger the charge from your server, 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	Very rarely
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 who triggers it, and whether the customer is present at that moment. The customer commits once, when they register their card: that is a CIT. Their consent then allows you to charge the card yourself: those charges are MIT.

Register once, charge when you decide

Registration (CIT). The customer registers their card, present. The CVV is always requested, and 3D Secure may apply: it is not mandatory and is decided by the payment provider. You get a cardId.
Charges (MIT). You charge the saved card whenever you decide, with no customer interaction. The trigger is yours: a no-show, a balance running out, a usage threshold, or your own recurring schedule.

The rebill endpoint is not tied to a fixed due date. Keep a proof of the customer’s consent (amount, trigger conditions, date, IP address).

Which type for which case

Use case	Type
One-off purchase	CIT
Card registration	CIT
One-click payment, customer present	CIT
Fixed-amount subscription renewalCharge you trigger on a saved card (no-show, top-up, usage-based)	MIT
Usage-based, variable amount	MIT
Subscription renewal	MIT today; Subscription module coming

Bank cards only

Registration and MIT work with bank cards only. Apple Pay cannot be saved as a reusable card, and a Carlo App payment is always approved by the customer in the app, so neither can be charged later by you.

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 call, through the amount field, so a variable amount is simple: you compute it on your side. If you need due dates, you trigger the charge from your own scheduler today.
Subscriptions. A dedicated Subscription module is coming, to manage recurring subscriptions. Charges you trigger yourself on a saved card keep working as described here.

Updated on: 28/10/2026