pay.sh docs
Building with payPayment channels

Concept

What a payment channel is — deposit a ceiling once, spend off-chain with no per-request transaction, and settle the actual amount on-chain at the end.

A payment channel lets a buyer deposit a ceiling once, spend against it off-chain, and settle the actual amount on-chain only at the end — refunding whatever they didn't use.

Think of a bar tab or a prepaid meter: you put money down up front, run up usage without paying for each drink at the counter, and square up once when you leave. The deposit caps what you can be charged; you only pay for what you actually consumed.

Why not just settle every request?

Settling each request as its own on-chain transaction works for a fixed, one-off charge — but it's slow and costs a network fee every time. That's a poor fit for two common shapes:

  • One call whose cost you only know afterward — an LLM completion billed per token, a job billed per byte or per second of compute.
  • A stream of many small deliveries — a token-by-token SSE response, or a burst of cheap calls in one session.

A payment channel amortizes the on-chain work down to one open and one settle, no matter how much metering happens in between.

The two flavors

pay.sh offers payment channels through two schemes. Both are channels — deposit a ceiling, meter off-chain, settle the real amount, refund the rest — but they suit different shapes:

  • Usage charges — x402 upto. Authorize a ceiling for a single metered call. Your handler runs, the operator settles the one actual amount, and refunds the difference. Best when one call's cost is unknown until it runs. See Usage charges.
  • Streaming sessions — MPP session. Open a channel and stream many metered deliveries, each authorized by a running (cumulative) voucher; settle once when the session idle-closes. Best for streams and many-small-calls. See Streaming sessions.

Shared shape

Whichever you pick, the moving parts are the same:

  • Deposit / escrow — funds are held by an on-chain channel program, not by the server. The server can only claim with a valid signature; the buyer can always recover the unspent remainder.
  • Off-chain authorization — spend is authorized by signed messages, not a transaction per request.
  • Settle + refund — at the end the operator settles the actual amount on-chain and the unused deposit is refunded.
  • Operator-sponsored fees — the operator can fee-pay the open and settle transactions, so the buyer needs only the stablecoin, not SOL.

Not sure which to reach for? The short rule: one metered call → upto; a stream of many deliveries → session. The full comparison is on upto vs sessions.

Next

On this page