Going live checklist

Work through this once, top to bottom, before launch. Most production incidents trace back to a skipped line here.

​

Account

• Merchant approved. Onboarding submitted and approved — the API and checkout refuse unapproved merchants.
• Bank details correct. Payouts go to the account from your onboarding profile; a typo here delays your money, not Qint’s.
• Current terms accepted. An Owner or Admin has accepted the Qint terms in the dashboard. Without that, new payments are refused with terms_acceptance_required from the terms’ effective date.
• Branding set. Logo, brand color and support email appear on the hosted checkout — buyers should recognize you.
• Accepted assets reviewed. The default is USDT, USDC, ETH and BTC; enable more assets deliberately, not accidentally.
• Team roles assigned. Give finance staff the Finance role for payouts and underpayment reviews; developers the Developer role for keys and webhooks. Don’t share Owner logins.

​

API integration

• API key stored as a secret — environment variable or secret manager, never in code or a browser. Remember it was shown once.
• Scopes are minimal. Write only where payments are created; Read for reporting jobs.
• Idempotency keys on every create. Your order id, passed as idempotencyKey, makes retries safe.
• Payment limits known. Payments outside CHF 10 to CHF 100’000 (or the equivalent) are refused with amount_out_of_range; if your tickets exceed CHF 100’000, ask support@qint.ch for a custom cap before launch.
• Currency guard. You only send CHF, EUR, USD or GBP — anything else is a 400, and so is a currency Qint has switched off for new payments. Show the buyer a clear message rather than a generic failure.
• returnUrl handled as UX, not truth. The return redirect carries qint_intent and status, but fulfilment waits for settled via webhook or API.
• 429s handled. Back off and retry; with idempotency keys this is always safe.

​

Webhooks

• Endpoint is https and registered in Developers → Webhooks; the whsec_… secret is stored as a secret.
• Signature verification is constant-time and uses the raw body. Test with a tampered payload — it must be rejected.
• Test event passes. Send a ping from the dashboard; the delivery log shows 2xx.
• Handler returns 2xx fast and processes asynchronously.
• Dedupe on X-Qint-Event-Id — retries redeliver the same id.
• All statuses handled, including failed, expired, cancelled — and the underpaid flag.
• Reconciliation fallback exists. A periodic job (or on-return check) calls GET /api/v1/intents/{id} for orders still awaiting payment, so a dead-lettered webhook can’t strand an order.

​

Operations

• Fulfilment fires on settled only. Not confirmed, not the buyer returning to your site.
• Underpayment playbook agreed. Who reviews the queue, and by what rule they accept or decline. Emails go to Owners/Admins when a payment comes up short.
• Payout rhythm chosen. Manual or scheduled; whoever owns finance can find the payout reference for bank reconciliation.
• Key rotation plan. Calendar the rotation; the dashboard’s last-used timestamps show when an old key has gone quiet.
• Delivery log checked after launch. In the first days, glance at webhook deliveries for anything red.

Questions before switching on? support@qint.ch.