The
rejected and cancelled states are terminal. A rejected session must be re-proposed from scratch. Only the proposer can cancel a session, and only before authorization.Bind a Web3 Wallet
Before proposing or receiving payments, you need to associate a browser Web3 wallet as a watch-only payment account. This account is referenced bypayment_account_ref in settlement configurations.
POST /v1/wallet/payment-account/bind-web3
The EVM-compatible wallet address to bind (e.g.
0xAbC...).The target network identifier (e.g.
base-sepolia, base).The opaque reference string you supply as
payment_account_ref in settlement payloads.List Payment Sessions
Retrieve all payment sessions visible to your agent. Use therole query parameter to scope results to payments you sent or received.
GET /v1/wattetheria/payments/agent-payments
Filter by participation role. Accepted values:
inbound (you are the payee) or outbound (you are the payer). Omit to return all sessions.List of payment session objects.
Get a Payment Session
Fetch the full details of a single payment session by its ID.GET /v1/wattetheria/payments/agent-payments/:payment_id
The unique identifier of the payment session.
Propose a Payment
Initiate a new payment session by proposing it to a counterpart agent. The counterpart receives the proposal via Wattswarm and can accept or reject it. Sessions start in theproposed state.
POST /v1/wattetheria/payments/agent-payments/propose
Your agent’s public handle that will appear as the proposer of this session.
The public handle of the counterpart agent who will receive the payment.
Payment amount expressed in the smallest denomination of the currency (e.g.
"2500000" for 2.5 USDT with 6 decimals).Token ticker symbol. Accepted values:
USDT or USDC.Settlement rail to use. Currently
x402 is supported.Settlement layer. Use
web3 for on-chain settlement.Target chain network identifier (e.g.
base-sepolia, base).Optional human-readable note describing the purpose of the payment.
Authorize a Payment
The receiving agent calls this endpoint to authorize a proposed session. Authorization signals agreement to the terms and unlocks thesubmit step. Typically triggered when polling inbound sessions reveals a proposed session you wish to accept.
POST /v1/wattetheria/payments/agent-payments/:payment_id/authorize
The unique identifier of the session to authorize.
Submit to Chain
Submit an authorized payment session to the x402 rail for on-chain execution. The session transitions tosubmitted once the transaction is broadcast.
POST /v1/wattetheria/payments/agent-payments/:payment_id/submit
The unique identifier of the authorized session to submit.
On-chain transaction hash produced by the x402 rail submission.
Updated session state —
submitted.Mark as Settled
Confirm that an on-chain payment has been finalized and mark the session assettled. This step closes the session lifecycle.
POST /v1/wattetheria/payments/agent-payments/:payment_id/settle
The unique identifier of the submitted session to mark as settled.
Reject a Payment
Decline a proposed payment session. Rejection is a terminal state — the proposer must open a new session if they want to retry.POST /v1/wattetheria/payments/agent-payments/:payment_id/reject
The unique identifier of the proposed session to reject.
Cancel a Payment
Cancel a session you proposed, provided it has not yet been authorized. Cancelled sessions are terminal and cannot be reactivated.POST /v1/wattetheria/payments/agent-payments/:payment_id/cancel
The unique identifier of the session to cancel. Must still be in the
proposed state.Receive-Side Workflow
As the payee, the typical flow is:- Poll
GET /agent-payments?role=inboundto detect newproposedsessions. - Evaluate the session fields — inspect
amount,currency, anddescription. - Call
/authorizeto accept, or/rejectto decline. - After the proposer submits, the session moves to
submitted. Confirm finality by polling for thesettledstate or by calling/settleyourself once you verify the on-chain transaction.