Off-session payment / merchant-initiated transaction (MIT)
Charging a saved card when the customer is not at the checkout: renewals, usage bills, and no-show fees fire from your side, not theirs.
See it
What it is
Payments split into two worlds. On-session means the customer is at the checkout right now and their bank can throw a challenge at them. Off-session means your cron job is charging a vaulted card at 3am and there is nobody to tap a code. Merchant-initiated transaction is how that charge gets labelled to the issuer: a stored-credential charge tied to an earlier agreement rather than a stranger trying a card number. Most processors put those network indicators on the charge for you when you set the consent up properly and charge a saved credential; skip the setup and approval rates drop for reasons your logs will not explain.
This is what every renewal, metered invoice, auto top-up, no-show fee, and post-stay incidental charge runs on. The rule of thumb: the first charge is on-session and authenticated, every charge after that is off-session and rides on that consent. One thing that is not an MIT, despite showing up on every list: capturing a hold you already authorized. That completes the transaction the customer was present for, it does not start a new merchant-initiated one.
The gotcha everyone hits in Europe: an off-session charge can still come back needing authentication. There is nobody there, so the only recovery is to mark the invoice unpaid and email the customer a link that brings them back on-session to confirm, then retry. Build that path before launch or your dunning turns into silent churn. Also key every attempt idempotently by invoice period, because a retried worker that double-charges is a chargeback with your name on it.
Ask AI for it
Add off-session recurring charges to this billing worker. Establish consent first while the customer is present, with either a PaymentIntent confirmed on-session that declares future off-session usage or a SetupIntent with usage 'off_session', and attach the resulting PaymentMethod to the Customer. Later charges create a PaymentIntent against that stored customer and payment method with off_session true and confirm true; let Stripe populate the network stored-credential indicators rather than inventing a parameter for them. Handle the three failure modes separately: on authentication_required, mark the invoice past due and email a hosted link that reconfirms the payment on-session with 3-D Secure, then retry; on a soft decline, schedule retries with exponential backoff on the dunning schedule; on a hard decline, stop retrying and prompt for a new card. Pass an idempotency key derived from subscription id plus billing period so a replayed job can never double-charge, persist every attempt with its decline code and next retry time, and expose an admin view of accounts currently in recovery.