Skip to main content
GET /api/v2/checkout/{reference} is the JSON behind SouthPay’s hosted checkout. It is the endpoint to build against when you want your own payment page instead of hosted checkout or the checkout widget. It is public and unauthenticated, keyed by the intent’s reference, and cross-origin requests are allowed from any origin. Call it directly from the browser — no API key, no proxy.
Because it needs no key, anyone with a reference can read it. Treat the reference as the secret. Do not put it in a URL you index, log it to a third party, or reuse it across orders.
Reading the checkout does not require your customer to be signed in to anything, but it is not free of side effects: a pending intent whose window has closed is expired by this call.

Get the checkout

GET /checkout/{reference}. No authentication.

Fields

string
The intent’s reference, echoed back.
string
The intent’s id. Use it when talking to support, and to match against the authenticated API.
string
The payment intent status: pending, processing, completed, failed, expired or refunded. See Payment lifecycle.
string | null
Why the intent is in that status, for example pending_confirmations, completed_exact, completed_overpaid, completed_underpaid, processing_underpaid, failed_underpaid, failed_overpaid, expired_timeout, canceled_by_merchant, canceled_by_agent or refund_completed.
boolean
Whether the payment has finished for display purposes. True for completed, expired, refunded and failed. Stop polling when this is true.
boolean
Whether expires_at is in the past. A pending intent can read expired: true for the moment before the status catches up.
integer
The order total in minor units of settlement_currency. This is the fiat price, not the crypto due.
boolean
Whether SouthPay’s fee is added on top of the customer’s amount. Drives whether fee_crypto_atomic and base_crypto_atomic appear on each address.
string | null
The total fee rate as a decimal fraction, for example "0.0199" for 1.99%. Null when no fee applies.
object[]
One entry per asset the customer may pay in. Show all of them and let the customer choose.
object[]
Deposits seen so far, oldest first. Empty until the customer pays. Drive your confirmation progress from this.
object | null
image_url, line_items, total_cents and currency, from what you sent at creation. Null when the intent has neither line items nor an image.
object
Whether this checkout can be funded by card. available and providers. See Card payments.
object | null
logo_url, brand_name, primary_color, secondary_color and remove_southpay_branding, when white-label branding is configured for the store. Null otherwise. Building your own checkout, you can ignore this and use your own design.
string | null
Where to send the customer once the payment completes.
string | null
Where to send the customer if they abandon or the payment fails.
Errors are {"error": "Checkout not found"} with 404 when no intent matches the reference.

Poll for completion

There is no customer-facing webhook and no websocket. Poll this endpoint, and stop when terminal is true.
Poll every few seconds, not every few hundred milliseconds. GET requests under /api/v2/checkout/ are rate limited per checkout, and a tight loop will throttle the customer out of their own payment page.
Poll for your display only. Never release goods on what the browser saw — a customer can close the tab, and anyone can call this endpoint with the reference. Fulfil on the payment_intent.completed webhook delivered to your backend.
Convert amounts with BigInt throughout:

Adding card payments

If onramp.available is true, you can offer a card option alongside the wallet addresses. The request flow, pricing and session creation are covered in Card payments. One constraint shapes the design, so decide on it before you build:
The card flow does not return the customer to your page. After paying, the provider sends them to SouthPay’s hosted checkout at https://pay.southpay.io/{reference}, which waits for settlement and then forwards them to your success_url. You cannot override that return target.
So a custom checkout offering card payments hands the customer to SouthPay for the waiting period and gets them back at success_url. Wallet payments stay on your page throughout. If keeping the customer on your own domain end to end matters more than offering cards, offer wallet payments only.
Last modified on August 31, 2026