Go-live checklist and underwriting

What underwriting needs

BazPay underwrites low-risk merchants only, which is what keeps approval rates stable for everyone on the platform. Review usually takes two to five working days once the file is complete — and "complete" is the operative word, because a missing document restarts the clock rather than pausing it.

The technical checklist

Twelve checks. Every one has cost somebody a live incident, which is why it is on the list rather than in a paragraph of general advice.

Credentials and configuration

1. Live keys come from configuration, never from source. Grep the repository for sk_ before you ship.
2. The API version is pinned explicitly in your client, not left to the account default.
3. The live webhook endpoint has its own whsec_, and it is not the sandbox one.
4. A key-rotation runbook exists and someone other than its author has read it.

Payment flow

1. Fulfilment triggers on payment.succeeded only — never on the browser return.
2. Every write sends an Idempotency-Key, and a timeout resends the same key rather than a new one.
3. Declines render a specific message per code, not one generic apology.
4. Manual-capture authorisations are captured or cancelled before the 7-day expiry.

Events and observability

1. The webhook handler verifies the signature on raw bytes and checks the timestamp.
2. Event ids are stored with a unique constraint, so a duplicate delivery is a no-op.
3. The handler answers within 10 seconds and queues everything slow.
4. BazPay-Request-Id is logged on every response, success or failure.

Switching keys

The cut-over itself is four configuration values. Nothing about the request bodies, the URLs or the field names differs between modes — if your code needs a branch on environment beyond reading different secrets, something has been special-cased that should not have been.

# the whole cut-over, in configurationBAZPAY_SECRET_KEY   = sk_live_…      # was sk_test_…BAZPAY_PUBLIC_KEY   = pk_live_…      # was pk_test_…BAZPAY_WEBHOOK_SEC  = whsec_…        # DIFFERENT per endpointBAZPAY_API_VERSION  = 2026-04-01     # pin it explicitly​# no request body, no URL and no field name changes

The webhook secret is per endpoint, not per account. Copying the sandbox secret into production is the single most common cut-over mistake and it presents as every signature failing.

Then take one real payment before you send any traffic at it.

# first live transaction — smallest amount you can chargePOST /v1/payments   amount: 100  currency: EUR  method: card→ 201  { "id": "pay_7Yb4Rk", "status": "requires_action" }​# check all four, in this order1. payment.succeeded reached YOUR endpoint, signature verified2. the order moved to paid in YOUR database3. the payer's statement shows your trading name4. the refund settles and refund.settled arrives

Refund it afterwards. The pair costs a few cents in fees and exercises the entire chain — underwriting, routing, a live issuer, settlement, your webhook, your database and your reconciliation — in a way no sandbox run can.

Watching day one

For the first day, watch four numbers rather than the whole dashboard. Each has a level at which you should stop and look rather than wait and hope.

All four are on real-time analytics, broken down by method, issuer country and decline reason. The breakdown matters more than the headline: an authorisation rate that drops five points because one issuer is having a bad hour needs no action, and the same drop spread evenly across issuers usually means your own rules.

If something is wrong

Rolling back a payments integration is not the same as rolling back a deployment: money has already moved and the schemes have already been told. What you can do is stop new exposure quickly, in this order.

• Stop new payments Disable the method in your checkout rather than revoking the key. Revoking breaks refunds and webhook reads too, which makes recovery harder.
• Leave webhooks running Events for payments already in flight still need to land. Turning the endpoint off strands them until the retry window closes.
• Cancel, do not refund Uncaptured authorisations should be cancelled — it releases the hold at no cost and never shows on the payer's statement.
• Replay after the fix Failed deliveries stay in history for 30 days. Replay the range once your handler is correct and the ledger catches up on its own.

Tell us early. With a request id or a payment id we can see exactly what the rail returned, and on a live incident we can freeze payout creation on the account within minutes while you work. Reach the team through contact.

Reconciliation from here

Once traffic is steady the work changes shape: less integration, more matching money to orders. Three habits keep that cheap.

• Put your order id in reference on every payment. It travels to the settlement line, so reconciliation is a join rather than a search.
• Reconcile against the settlement report, not against the payment list. Settlement is what arrived in your bank account, net of fees, refunds and any reserve.
• Pull reports on settlement.created instead of on a nightly cron. The event fires when the file is ready, so you never process a partial one.

Fee structure and interchange++ breakdowns: pricing · report fields and export formats: real-time analytics · commercial and compliance questions: the gateway FAQ.