All endpoints

Base URL https://hub.stablezact.com. Prefix every path with /api/v1. See Versioning.

Most of these need authentication. A few do not, because a checkout page in the customer’s browser has to reach them: /payments/public/{paymentId}, /payments/contract/{chainId}, /deposits/chains, /payments/cross-chain/sources, /currency/rates and /payments/health.

Note

This is the complete list of what exists. Most of these have full request and response detail under API reference; a handful do not yet, and are listed here so nothing looks missing.

Payments

Method	Path	Purpose
POST	/payments/create	create a payment
GET	/payments/{paymentId}	read a payment, including payout progress
GET	/payments/{paymentId}/status	has the customer paid
GET	/payments/status/{paymentId}	the same, alternate path
GET	/payments/public/{paymentId}	limited detail, safe for a checkout page
POST	/payments/process	submit an on-chain transaction for verification
POST	/payments/fail	mark a payment failed, cancelled or expired
POST	/payments/verify-qr	verify a QR-initiated payment
GET	/payments/contract/{chainId}	contract address and ABI for a chain
GET	/payments/merchant/list	your payments, paginated (API key and secret)
GET	/payments/merchant/stats	totals for your account (API key and secret)
GET	/payments/health	service health

Retrying safely

Payment creation is idempotent. The server decides whether a request is a repeat using the first of these it finds:

1. an Idempotency-Key request header, which is the mechanism to prefer
2. an orderId in the body
3. a fingerprint of the whole request body

So an identical retry is recognised even if you send neither, but relying on that is fragile: change one field and it becomes a new payment. Send an Idempotency-Key on anything you might retry.

Idempotency-Key: order-1234-attempt-1

Keys are scoped to your account and to the endpoint, and the versioned and unversioned paths share a key, so retrying against /api/payments/create after /api/v1/payments/create will not create a second payment.

Deposit addresses

A deposit-address payment gives the customer a unique address to send to, and the funds are forwarded on to your settlement wallet.

Method	Path	Purpose
POST	/deposits/create	create a deposit-address payment
GET	/deposits/status/{paymentId}	status of the deposit
GET	/deposits/balance/{paymentId}	what has arrived so far
GET	/deposits/chains	chains supporting deposit addresses
POST	/deposits/refund-request/{paymentId}	supply an address for a refund

Cross-chain

For customers paying from a chain other than the one invoiced.

Method	Path	Purpose
POST	/payments/cross-chain/create	create a cross-chain payment
GET	/payments/cross-chain/sources	chains a customer can pay from
GET	/payments/cross-chain/status/{paymentId}	bridge progress

Networks and rates

Method	Path	Purpose
GET	/networks	every supported network
GET	/networks/payable	networks that can currently accept payment
GET	/networks/stablecoins	supported tokens
GET	/networks/payable/stablecoins	tokens on payable networks
GET	/currency/rates	exchange rates used for conversion

Service

Method	Path	Purpose
GET	/api/health	is the service up, not versioned
GET	/api/versions	supported versions, not versioned

Those two are the exception to the /api/v1 rule. Checking whether the service is up, and asking which versions exist, cannot require knowing a version first. /api/v1/health returns 404 by design.