How it works
Stand up your own card program in minutes and write the rules that govern it. Sixteen rule kinds, no sales call, no five-figure minimum.
An agent, a script or a person states what they are about to buy — merchant, amount, category. Nothing is chargeable and no credential exists.
Every rule in your rulebook runs. No short-circuit, so a refusal returns every reason rather than the first one.
Approve, decline, review or partial. A review parks the request and notifies a named person.
A single-use card is created and loaded to the approved amount. Afterwards it is swept and closed.
The part that is hard to copy
Because the decision happens before a purchase exists, there is no clock running. A rule can wait four minutes or four hours for somebody to answer.
| Inside an authorization | APPEN | |
|---|---|---|
| Time to decide | About two seconds | As long as it needs |
| Ask a person | Not possible | The normal case |
| Call your own system | No time | A webhook, before funding |
| If it refuses | A decline on a live card | No card was created |
| What you get back | Yes or no | Every rule, and its reason |
Enforcement
Eight of the sixteen kinds are enforced by funding — the card never holds money it should not; condition steers branches and repeat gates the loop. Five need merchant identity, so they are enforced by issuing one card per approved purchase plus category controls. One hands the decision to you.
Amount, spend cap, velocity, time window, uses, cooldown, duplicate guard, approval threshold. The money is simply never there.
Merchant lock and block, category, new-merchant review, per-merchant caps. A card only ever exists in the context that approved it.
webhook_check. If you can express it in code, the card can enforce it.