Work through this list with your sk_test_ key, then swap in your sk_live_ key. Nothing else in your code should change.

​
Account

  • Your business is verified in the dashboard (Compliance). Live keys are issued after verification.
  • Your live secret key is created with only the scopes each system needs, and stored in your server’s secret manager, never in code or an app.

​
Payments

  • Checkout sessions are created on your server, with the price and parties from your own records.
  • Every POST sends an Idempotency-Key, and retries reuse it (Idempotency).
  • You show the buyer fees.buyer_total before they pay (Fees).
  • An order is marked paid only after escrow.funded or a fetched session with status: complete, never because the buyer reached your return_url (Verify payments).
  • Your check compares external_reference, amount and livemode with your order.
  • You handle verification_required (the buyer must verify further for large amounts) and checkout_session.expired.

​
Webhooks

  • A live webhook endpoint is registered on HTTPS.
  • Every delivery’s signature is verified against the raw body (Webhooks).
  • Your endpoint answers 2xx within 10 seconds and does slow work in the background.
  • Events are deduplicated on id and handled in any order.
  • You tested each event you rely on with POST /test_helpers/escrows/{id}/simulate.

​
Your customers’ actions

  • Customer tokens are kept on your server and never logged (Customer tokens).
  • Release codes are only ever shown to the buyer (Release codes).
  • Your UI explains disputes and points both sides to the dispute room or your own evidence flow (Disputes).

​
Operations

  • Errors are handled by code, with KetaPay-Request-Id logged for support (Errors).
  • You stay under the rate limits and back off on 429.
  • Someone on your team receives the dashboard’s failing webhook emails.
Questions before launch? Email developers@ketapay.com.