Exchange is excluded from this API/CLI release. Any historical Exchange API or CLI example in this guide is unavailable; native portal behavior is outside this exclusion. See [current release scope](/developers/guides/release-scope?lang=en).

# Authorization during billing

An approved API quote preserves the purchase intent and prepares the real resources and held tasks before billing starts. The durable billing attempt and spending reservation are recorded once. That receipt does not authorize a revoked connection to keep sending new supplier calls.

The shared checkout can therefore receive an explicit backend check. Every actual WeFact call and every Mollie SDK call rechecks the same original connection, original token ceiling, current company and required permissions. Batch children are checked individually. The check does not repeat an order, spending reservation or billing journal. Browser checkout and background processes gain no implicit API user context.

If permissions expire during debtor retrieval, no invoice request follows. If they expire during an already accepted invoice response, the received invoice ID is retained and subsequent subscription, mail and payment requests stop. A Mollie customer ID already received is likewise retained before a next payment request can be refused.

An uncertain order stays on its original intent; prepared tasks remain held. Investigate the original operation and financial references. Do not create a new quote or idempotency key to bill an unknown outcome again. Revoking a connection does not reverse an already accepted payment or invoice; handling that requires the designated cancellation or recovery workflow.

Paid changes to an existing spam filter also use the same current check for the quoted change at subscription, filter and DNS calls. Synchronous processing of an already received payment preserves this check when creating overdue subscriptions. Existing background receipts receive no fabricated interactive user.

This check complements existing current task authorization at delivery. The callback is exclusively a trusted backend argument and cannot be enabled, replaced or skipped with an HTTP field or header.

A recurring WeFact subscription likewise receives a durable creation record before `subscription.add`, including a server-generated attempt reference in the internal supplier comment. An existing unconfirmed, failed or unknown record cannot start another `add`, even when a hard-stopped process stored no error. A received subscription ID is retained separately before the local terminal status. An unknown agreement without a supplier ID cannot be marked as confirmed terminated.

The [WeFact subscription creation documentation](https://developer.wefact.com/subscription/add) describes both creation and any invoicing. We therefore do not infer a guaranteed rollback of every step from an error response. The attempt reference helps investigation; it does not make the supplier call idempotent. Unconfirmed invoice lines remain visible for investigation and are not automatically resubmitted by a subsequent background run. This adds no unproven automatic recovery action.