Pre-authorization is checking a customer's balance and approving a usage event before it runs. In Credyt, the platform authorizes each action against the wallet first, then the event proceeds and is debited.
Pre-authorization is the mechanic that lets billing say "no" before money is spent. In Credyt's model, the platform checks whether a customer has the balance to cover an action before that action runs. If they do, it proceeds and is debited; if not, the platform can block it. It is the difference between preventing overspend and discovering it later.
How Pre-authorization works
When a customer is about to perform a billable action, the platform queries Credyt’s Wallet API for the customer’s balance before the action executes. Credyt returns whether the balance is sufficient, and the platform decides whether to authorize or block. When authorized, the event runs and Credyt debits the wallet the moment it is recorded.
This authorize-before-work step is what separates real-time billing from real-time metering. Metering records usage as it happens; pre-authorization gates usage before it happens, so a customer who is out of balance can be stopped rather than allowed to accrue unrecoverable cost.
Pre-authorization examples
An AI product pre-authorizes each model call against the customer’s token balance; a customer with no balance is blocked before the expensive inference runs. A compute platform pre-authorizes a job against available GPU hours. A credits product checks the balance before letting an action consume a credit.
By default Credyt does not block on insufficient balance, the platform holds that decision, but wallet controls let the platform enforce hard limits where overspend must be prevented.
Pre-authorization vs Post-usage billing
| Pre-authorization | Post-usage billing | |
|---|---|---|
| Decision point | Before the event runs | After, at invoice time |
| Can block overspend | Yes | No |
| Exposure | Capped before spend | Discovered later |
| Best for | High-cost-per-event usage | Trusted, post-paid billing |
Benefits & when to use it
Pre-authorization matters wherever a single action carries real cost the provider cannot recover, the defining condition of AI and compute products. It converts billing from an accounting function into a control: spend is gated at the moment of action, not reconciled weeks later.
It is unnecessary for low-cost, trusted, post-paid relationships, where billing after the fact is fine. The value appears when the gap between “used” and “paid” is risky, which is exactly the AI inference case.
FAQ
What is pre-authorization in billing?
Checking a customer's balance and approving a usage event before it runs. If the balance is sufficient the event proceeds and is debited; if not, the platform can block it, preventing unrecoverable overspend.
How is pre-authorization different from metering?
Metering records usage as it happens, after the fact. Pre-authorization gates usage before it happens by checking the balance first. Metering observes; pre-authorization controls.
Does pre-authorization always block customers who run out?
Not by default in Credyt; the platform decides. Credyt provides the real-time balance state that makes the decision possible, and wallet controls let the platform enforce hard blocking where overspend must be prevented.
How Credyt handles Pre-authorization
Pre-authorization is built into Credyt's real-time model. The platform queries the wallet balance through Credyt before each event, authorizes or blocks based on live state, and Credyt debits the moment the event is recorded. Combined with multi-asset wallets and customer-set auto top-up, it lets products control spend before it happens rather than after. See the platform. Explore Credyt →