Use cases

The middleware rejects it before your handler runs and responds with a fresh 402 quote. Your application code never sees unverified traffic — there is no "maybe paid" state to handle.

Yes. scaleCost() computes units from request or response context — output tokens, rows scanned, processing time — so dynamic workloads still get exact pricing, billed in integer micro-units with no rounding.

The SDK publishes a payment manifest listing every priced route, its fee, and accepted tokens. Clients and agents read it once instead of probing each endpoint for a 402.

The SDK rejects it before any signature is produced and throws a typed error with the quoted fee. The agent can skip the tool, pick a cheaper provider, or escalate to a human approval flow.

Yes. Spender registration scopes each runtime under the ChannelCash instance id, so every agent signs with its own registered identity while drawing from the shared balance — and any one of them can be revoked individually.

No. Payments are ledger debits authorized by typed-data signatures; settlement gas is batched and amortized on the merchant side. The agent only ever signs messages.

Yes. External payers send to a contract-managed temp deposit address generated per payment. Because sweeps are batched at the contract level, it costs up to 40% less gas than a one-off EOA temp address — and Channel app users skip even that, paying with a zero-fee ledger debit.

Your funds are on the ledger contract under your own wallet, so settlement keeps working — withdrawal is a permissionless contract call that needs no approval from Channel or anyone else.

Yes. The payee is configured per route, per checkout, or per plan, and each payment proof names its payee explicitly — a marketplace can route every seller's share to their own wallet on the same ledger.

Every receipt exports with payer, token, amount, timestamp, source, and transaction id, and each one is backed by a verifiable signature — a complete, audit-grade revenue trail.

The approval screen always shows the resolved wallet address and amount before you sign — what you approve is exactly what executes. Like cash, a signed transfer is final, so the confirmation step is explicit.

No. Receiving requires no action — the credit lands on the ledger immediately and the recipient's wallet picks it up the next time it syncs.

Because there is no correspondent chain — a remittance is the same signed ledger transfer as a local payment. Distance doesn't add hops, and hops are what cost money.

They need connectivity to sign and submit — the same way a card needs the network. But there's no acquirer round-trip, so once the payment is signed it confirms faster than a card authorization.

Each code carries a short validity window so a stale or screenshotted QR can't be reused. If it lapses before the customer scans, the register simply shows a fresh one — the amount never changes.

No batch and no payout schedule. Each payment is already in your wallet the moment it confirms, reconciled against its own signature — there's nothing to wait for or settle later.

The gate simply returns a 402 with a re-subscribe quote. One signature restores access — there's no account state to repair, no dunning sequence, no support ticket.

Publish a new plan with the new price — its id is derived from its parameters. Existing renewal authorizations stay bound to the amount the subscriber actually signed; nobody gets silently repriced.

Yes. subscribe(planId) passes active subscribers straight through, and everyone else falls back to the metered monetize() quote — heavy users subscribe, occasional users pay per call.

Yes — that's the point. The SDK exposes sessions, QR payloads, and payment status; you render them however your product looks. Hosted pages exist for teams that want them, but nothing forces you onto them.

Splits are declared on the route or checkout session, and each payment proof settles every payee's share to their own wallet in the same ledger entry — there's no pooled account that redistributes later.

Settlement is permissionless on the ledger contract — balances stay withdrawable and on-chain settlement keeps working without any Channel service in the loop. Your dependency is the chain, not our uptime.