Use cases

Payments

Bounded spending authority with idempotency and an honest UNKNOWN.

The problem

Money moves once. Every layer between the decision and the merchant is a place where a retry becomes a second payment.

Without Bengar

• A shared key with a spending limit set in somebody else's dashboard.
• Retry logic that cannot distinguish “refused” from “we lost the answer”.
• Reconciliation as a monthly spreadsheet.

With Bengar

• Per-transaction and cumulative limits in the permit, enforced before the call.
• A nonce that binds one execution to one action.
• UNKNOWN as a first-class outcome that holds the budget and waits for a person.
• A resolution recorded as somebody's statement about what they checked.

The flow

1. Authorize with an execution block and a nonce.
2. SUCCEEDED, FAILED or UNKNOWN comes back.
3. UNKNOWN is investigated and resolved; it is never retried automatically.

Components used

Permits · Policy · Execution · Audit

Example

// The same nonce, sent twice, calls the merchant once.
const first  = await bengar.authorize({ ...request, execution: { ...block, nonce } });
const second = await bengar.authorize({ ...request, execution: { ...block, nonce } });

second.decision;            // "REPLAY"
second.execution?.status;   // the stored outcome — nothing was called again

Security properties

Try it →