> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://corebycarlo.crisp.help/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# 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](https://documentation.corebycarlo.com/api-reference/transactions/transaction-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
1. **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`.
2. **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`](https://documentation.corebycarlo.com/api-reference/transactions/transaction-post)
* **Register a card:** [`POST /cards/register`](https://documentation.corebycarlo.com/api-reference/cards/register-card), or capture the `cardId` from a successful payment callback. Card status via [`GET /cards/{cardId}`](https://documentation.corebycarlo.com/api-reference/cards/card-details), `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`](https://documentation.corebycarlo.com/api-reference/transactions/transaction-rebill). The `cardId` is required.
* **Refund:** the Refund API in the documentation (refunds run through the CIT flow).
* **Webhooks:** the [`transaction.status.changed`](https://documentation.corebycarlo.com/api-reference/webhooks/callbacks) 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.