nozle
    nozle

    Entitlements & wallets | Nozle

    Paid is one thing. Permitted is another.

    One balance, debited on the event. One real-time gate — so 'paid' becomes 'permitted' before the next request lands.

    Five moves a wallet has to make. Ours runs them on one balance.

    From the gate in your backend to a restore after payment — every step reads and writes one balance.

    Cyclegate → debit → top-up → revoke → restore
    1. 01
      Gate in one call
      One call: can this customer do this thing? Plan, balance, and overage rules return a single yes/no with a reason.
    2. 02
      Debit on the event
      Each metered event drains the wallet as it lands. Balances reflect reality, not last night's batch.
    3. 03
      Top up automatically
      Auto-reload, granted credits, plan refresh — all add to the same balance with full provenance.
    4. 04
      Revoke on plan change
      Downgrades, cancellations and trial expiry change the subscription — and the gate follows it on the next check.
    5. 05
      Restore on payment
      Top-up paid, credits land — access returns on the next check. Same balance, same history, no resets.

    A nightly cron isn't a wallet. A balance is.

    When entitlements lag, customers get cut off mid-call or run free for hours. Both cost you trust.

    Nightly entitlementsruns at 2am · reads yesterday
    2:14pm
    over cap
    2:14pm
    served
    2am
    cron
    DAY → +12h
    12h free traffic · refunds Monday · CS ticket
    LATE
    What you can't tell
    who's over, who paid, who's still spending.
    TICKET-?
    Live walletreads on the event · writes on the event
    2:14pm
    at cap
    2:14pm
    gated
    2:15pm
    topped up
    ACME · WALLET
    balance 0 → $200 top-up → access restored
    OK
    What you ship
    who's over, who paid, who's mid-flight.
    WALLET-7741

    Four parts. One balance read by every surface that matters.

    The gate that answers in one call, the wallet ledger that holds every debit and credit, the dunning that chases failed payments, and the surfaces that show the same balance.

    Prefer the schema?Read the entitlement docs
    GET /api/v1/can · acme
    deny · balance exhausted
    Balance · inference_tokens
    1.4M0−100%
    Plan
    growth · v17
    Included
    1.4M / mo
    Overage
    off (customer policy)
    Reason
    usage_limit_exceeded

    nozle.can() returns allowed: false with a reason code. Your UI renders the top-up link — no string parsing.

    Step 01 of 04

    Your code asks. Your processor funds. One balance answers both.

    Gate in one call. Top up through your processor. Read from anywhere.

    01 · Runtime gate in one call

    One check call. Yes or no, with a reason.

    SDKs for the languages you ship. One call from your backend.

    sdk.check
    node: @nozle-js/node · nozle.can()
    python: nozle-sdk · nozle.can()
    react: @nozle-js/react · gates
    rest: GET /api/v1/can
    • Margin floor checked on the same call.
    • Reason codes your UI can show as-is.
    02 · Top-ups your processor, our balance

    Stripe or Razorpay charges. The balance moves on payment.

    Auto-reload, one-time top-ups, granted credits — all one ledger.

    Stripe
    Adyen (coming soon)
    Razorpay
    • Idempotent. Retries never double-credit.
    • Refunds debit the same wallet, same row.
    03 · Everything downstream same balance

    Portal, support, dashboard — one wallet.

    Customer sees a balance. Support sees the same one. Your dashboard logs every move.

    fanout.live
    portal: balance + txn history
    dashboard: grant credits · attached to wallet
    billing: invoice line ↔ wallet txn
    • Webhooks on wallet changes.
    • Audit trail per debit and credit.
    Every change ·wallet_idbalanceplan_versionpolicytxns[]linked_invoice

    Stop guessing what's allowed. Read it.

    One balance. One gate. One call from your backend.

    Gate
    one call
    Balance freshness
    real-time
    Double-spends
    none
    State drift
    none