Tab Lifecycle

A tab lets a buyer authorize repeated payments to one seller under a cap and expiry. A session key signs cumulative payment vouchers. The seller verifies those vouchers before providing the service. Settlement transfers the authorized USDC to the seller.

1. The owner approves a session for a seller, spending cap and expiry.
2. The agent confirms the exact signed voucher through its reservation provider.
3. The agent sends the voucher and confirmed reservation receipt to the seller.
4. The seller verifies the voucher before returning the resource.
5. The agent asks the facilitator to settle its latest signed voucher against the Vault.
6. The Vault transfers USDC when settlement confirms. Revocation is a separate operation.

Choose the Payment Path

Use one payment per request for an API call that can settle immediately. A tab adds session management and settlement accounting; it suits repeated purchases from the same seller when both sides support the same voucher format.

The @dexterai/x402@6.0.0 client uses context-bound V2 vouchers with @dexterai/vault@0.43.4. Before releasing a voucher, it asks a reservation provider to confirm that exact obligation on chain. Buyer and seller independently verify the reservation. Configure the provider in the browser integration or Node integration.

Owner Approval

The grant binds a session key to a seller, a lifetime spending cap, and an expiry. It can also set a revolving capacity: the maximum exposure outstanding at once. The owner can lower the proposed cap or shorten the expiry during approval.

The client sets a per-voucher increment limit too. That limit controls how much one signing call may add. Keep it near the seller's quoted price.

The wallet owner keeps the passkey. An agent with the session secret can sign within its delegated scope, so store that secret as a spending credential.

Read a Cumulative Voucher

Suppose each API call costs 0.002 USDC. The buyer signs cumulative amounts of 2000, 4000, then 6000 in atomic USDC. Each step adds 2000; the third voucher represents 0.006 USDC in total.

The client advances its counter after signing and confirming the reservation, before delivery. A failed HTTP request does not undo that authorization or reservation. The seller must preserve its accepted vouchers and delivery records, and the buyer should reconcile uncertain requests before authorizing another increase.

For a resumed grant, the client reads the on-chain spend frontier. Reconcile pending provider operations before resuming: a transaction can have succeeded even when its acknowledgement was lost. Keep one active spender per session and retain the exact voucher and reservation identity across process failures.

Payment Evidence

These are separate events:

A local voucher or successful HTTP response alone does not prove an on-chain reservation. Account for the actual settlement and reservation operations your integration performs. Fees can make the seller's net receipt smaller than the gross amount authorized by the buyer; see Settlement.

Close and Revoke

In the 6.0.0 client, close() attempts to settle the latest signed voucher, then closes the local handle. A tab opened through the browser adapter also requests passkey-authorized revocation. A tab built with tabFromGrant settles without revoking; the owner retains control of revocation.

An unused tab may close without a settlement transaction. A failed close needs reconciliation: preserve the last voucher and any transaction identifier before retrying. Closing a local object, revoking a session, and settling an existing claim have different effects.

Streaming Payments

tab.stream() in 6.0.0 signs one voucher for the full perUnitCap before sending the HTTP request. It then reads the SSE response. It does not negotiate a fresh voucher for each chunk, and the signed amount is independent of how many chunks arrive.

For fixed-price requests, signNextVoucher(incrementAtomic) lets an integration choose the quoted increment explicitly. The seller guide covers validation and delivery accounting.