Skip to main content
Session payments use an escrow-backed channel on Abstract so the client can pay repeatedly with off-chain vouchers after one initial on-chain open.

Session lifecycle

The client-side session flow has four main actions:
  • open to create the channel and sign the first voucher
  • voucher to increase the cumulative paid amount
  • topUp to add more deposit
  • close to finalize with a last voucher

1. Install the package

2. Create the client session method

deposit is the default human-readable token amount to escrow unless the server challenge provides suggestedDeposit.

3. Register the server session method

4. Request shape

Session requests can include:
  • amount
  • currency
  • decimals
  • unitType
  • optional recipient
  • optional channelId
  • optional escrowContract
  • optional suggestedDeposit
  • optional minVoucherDelta

5. Operational guidance

  • pick a suggestedDeposit that supports several expected requests
  • settle when the open channel has accumulated enough value or when you need finality
  • use topUp instead of reopening when the remaining deposit is too low
  • expect cumulative amounts, not independent per-request signatures

When to use session mode

Use session payments when:
  • your agent will call the same paid API repeatedly
  • per-request on-chain overhead is too high
  • you want the HTTP flow to stay fast after the initial channel open