Agent
1
Read the 402
Use the merchant’s payment requirement as-is. Keep
orderRef stable. One orderRef uses one payment Idempotency-Key for every retry, including after a policy accept or an expired intent.2
Prepare
Call
prepare_x402_payment. It creates or resumes the spend intent, runs policy, reserves credit, and on allow returns VOUCHER_ISSUED with an unsigned voucher.get_context can say a payment looks allowed. Prepare still rechecks. Do not skip prepare because context looked fine.3
Sign
Sign with
@sohopay/agent-signer and send the PAYMENT-SIGNATURE header back to the merchant. If the signature field on the voucher is null, that is expected before you sign.4
Wait for the merchant
You do not submit the batch. Poll
get_settlement_status about every 2 seconds if you need to tell the borrower the payment landed. CONFIRMED means the batch entry settled. Available credit updates after that, not at voucher signing.create_spend_intent and evaluate_spend_policy remain for spend that is not an x402 402. Do not use them to reimplement prepare, and do not call execute_payment on a 402.
Recoverable stops
Merchant side of the same payment
The merchant posts the signed envelope toPOST /api/v1/facilitator/capture and polls by paymentId. Capture returning 200 means the payment is queued for the next batch, which flushes about every 60 seconds. Fulfillment waits for CONFIRMED. See Merchant integration.
Next steps
Settlements
Status values and when to release goods.
Errors
Codes you will actually see.

