mechanisms/evm/batch-settlement/client

BuildChannelConfig constructs a ChannelConfig from payment requirements and scheme config.

Returns an error when requirements.Extra["receiverAuthorizer"] is missing or zero - without it the derived channelId would not match the onchain channel and the deposit transaction would revert.

CreatePaymentPayload creates a batched payment payload.

The client loads local session state, falls back to onchain recovery when storage is empty, then chooses deposit vs voucher from the resulting context.

CreatePaymentPayloadWithExtensions creates a batched payment payload with extension awareness when paymentRequired.extensions advertises EIP-2612 or ERC-20 approval gas sponsoring.

Behavior matches the exact / upto schemes:

1. Build the base payload (deposit-or-voucher) via the standard CreatePaymentPayload flow.
2. Skip extension enrichment for non-deposit payloads (vouchers don't need a token approve).
3. Skip extension enrichment for non-Permit2 deposits (ERC-3009 carries its own gas-funded transfer authorization).
4. Try EIP-2612 first; on a successful permit signature, attach extensions.eip2612GasSponsoring.info and return.
5. Fall back to ERC-20 approval; on success, attach extensions.erc20ApprovalGasSponsoring.info.
6. If neither extension applies (allowance already sufficient, or token does not advertise EIP-712 domain fields), return the base payload.

Implements the optional x402.ExtensionAwareClient interface so x402Client.CreatePaymentPayload calls this path automatically when the server's 402 contains extension declarations.

GetSession returns the session for the given channel ID.

HasSession checks if a session exists for the given channel ID.

OnPaymentResponse implements x402.PaymentResponseHandler so the transport can auto-sync local session state after every paid response.

On a successful settle (HTTP 200 + PAYMENT-RESPONSE), folds the server-tracked channel snapshot back into the local session so the next request signs a voucher built from the right cumulative base.

On a corrective 402 (PAYMENT-REQUIRED carrying batch_settlement_cumulative_* or signature recovery data), runs ProcessCorrectivePaymentRequired and reports Recovered=true so the transport retries once with a freshly built payload.

ProcessCorrectivePaymentRequired handles a corrective 402 response when the client's cumulative base is out of sync. It validates the server-provided ChannelState (under accept.Extra) against onchain data and updates the local session, falling back to pure onchain recovery if no recovery data is sent. Returns true when the session was resynced and the request can be retried.

ProcessSettleResponse updates local session state from a settle response. It merges present fields into the existing session. Refund-specific reconciliation is handled at the refund call site via UpdateSessionAfterRefund.

RecoverSession rebuilds a client session from onchain channel state. Requires the signer to implement ClientEvmSignerWithReadContract. This allows recovery after a cold start or in-memory session loss.

Refund sends a cooperative refund request to the channel that backs url. On success, the local session is updated (or deleted on full refund) and the parsed SettleResponse is returned.

Scheme returns the scheme identifier.