Core resources
The table describes the target payment API. For an executable test, use the payment sandbox and the OpenAPI contract for /mock/v1.
| Method | Route | Purpose |
|---|---|---|
| GET | /v1/capabilities | Operational networks, assets and payment capabilities |
| POST | /v1/quotes | Request eligible payment route and fee quotation |
| POST | /v1/payments | Create authorized, idempotent payment |
| GET | /v1/payments/{id} | Read current status, guarantee and settlement |
| GET | /v1/payments/{id}/events | Retrieve append-only payment events |
Payment status model
AWAITING_DEPOSIT
DEPOSIT_OBSERVED
GUARANTEED
PAYOUT_PENDING
PAID
SETTLEDGuarantee, payout and settlement are separate dimensions. Failed or expired payments require explicit terminal states and recovery rules in the backend contract.
Integration rules
- Use atomic amounts as integer strings, never floating-point amounts.
- Require idempotency for all payment creation requests.
- Validate chain ID, token address, recipient and quote expiry before authorization.
- Verify signed guarantee evidence where applicable.
- Treat route availability and timeout as runtime data.
An OpenAPI contract and actual live API deployment should be versioned together. A static site is not an API implementation.