Skip to content

Explore Zenq Pay

Sections of the home page, pricing and developer docs.

Sign in

Merchant dashboard

Hosted checkout

Every invoice has a hosted payment page at checkout_url (/pay/{public_id}). The customer chooses how to pay, sends the funds, and watches the payment confirm. You never handle addresses or exchange rates yourself.

What the customer sees

  1. Choose a coin and network. The checkout lists the assets active for your store's environment: test networks for a test store, main networks for a live store. If you passed allowed_asset_ids when creating the invoice, only those are offered. USDT and USDC are the same symbol on several networks, but each (symbol, network) pair is a separate asset with its own contract and decimals.
  2. Get a quote and a deposit address. Choosing an asset creates a quote: the exact token amount, the rate it was priced at, and a deposit address created for this invoice. A quote is valid for 15 minutes and never beyond the invoice expiry. Stablecoins are priced 1:1 to USD by configuration. If no price can be produced the checkout shows an error (pricing_unavailable); there is no fallback rate.
  3. Pay. The customer sends exactly the quoted amount of exactly that token on exactly that network. The warning under the address is generated by the server for the selected pair.
  4. Confirmation. The checkout polls the payment status and shows confirmations as they accumulate. A payment is credited only after the network's required confirmation depth is reached and the block is re-verified.

Switching to another coin or network replaces the quote and allocates a new address. The earlier quote is kept, so a late payment to it can still be traced, but such a payment is held for review rather than credited automatically. A customer can change the selection at most 10 times per invoice (option_change_limit).

Invoice statuses

StatusMeaning
pendingWaiting for a payment.
confirmingA transfer was seen and is waiting for enough confirmations. Not yet credited.
paidConfirmed. Fulfil the order. Overpayments also count as paid.
partialLess than the quoted amount was confirmed. A further payment before expiry can still complete it.
expiredNo payment arrived before expires_at. Only pending invoices expire.
late_reviewMoney arrived after expiry or to a replaced quote. A person reviews it; it is never paid automatically.
cancelledCancelled by you (POST /v1/invoices/{id}/cancel, pending invoices only) or closed after review.

Invoices expire after one hour by default. If every transfer that moved an invoice to confirming is dropped by a chain reorganisation, the invoice returns to pending (or expired).

Each status change sends a webhook: invoice.confirming, invoice.paid, invoice.partial, invoice.expired, invoice.late_review, invoice.cancelled. Only invoice.paid should fulfil an order.

Returning to your site

Add success_url and cancel_url when you create the invoice to give the customer a way back to your store. Both must be absolute http:// or https:// URLs without credentials; anything else is rejected with 422.

Checkout stateLink shownURL used
paid"Return to store name"success_url
expired or cancelled"Back to store name"cancel_url
any other statenone—

Zenq Pay appends two query parameters so your page knows which invoice it is about:

https://shop.example/thanks?ref=1&nexus_invoice=chk_…&nexus_status=paid
https://shop.example/cart?nexus_invoice=chk_…&nexus_status=expired

The parameters are added with & when your URL already has a query string, otherwise with ?. The customer has to click the link; there is no automatic redirect. If you set only success_url, an expired invoice shows no link.

Do not fulfil on the return URL. Anyone can open it with any parameters. Use it to show a "thanks, we are confirming your payment" page, and fulfil from the signed invoice.paid webhook.

Embedding the checkout

The checkout can open as a modal on your own site instead of a full-page redirect. In the dashboard, add your site's origin under Settings → Store & branding → Sites allowed to embed the checkout (one HTTPS origin per line); it becomes the frame-ancestors policy for your checkout pages. With no origin configured, the checkout refuses to be framed. Setup steps are in Embeddable checkout.

Checkout API

The checkout page uses these public endpoints, keyed by public_id. They need no API key, by design, and you normally never call them yourself:

  • GET /v1/checkout/{public_id}: invoice summary and the assets on offer.
  • POST /v1/checkout/{public_id}/option with {"asset_id": "…"}: create or replace the quote.
  • GET /v1/checkout/{public_id}/status: received amount, confirmations and status.
  • GET /v1/checkout/{public_id}/receipt: available once the invoice is paid.