Skip to main content

Go-live checklist

Configuration we need from you​

  • Deep-link schemes and web return URLs registered — top-up returnUrls are allow-listed
  • Payment gateway credentials configured for your tenant
  • Transaction-type allowlist and caps agreed, and they match what your code posts
  • Wallet types and fund types enabled for your tenant

Code you should have written​

  • Idempotency-Key generated once per logical operation and reused on retry — never regenerated
  • 409 handled as "retry with the same key", not as a failure
  • Amounts parsed as decimals, never floats; fractional sen handled before you send them
  • Errors branched on type, not on detail wording
  • Top-up outcome taken from polling, never from the return URL
  • Every posting carries a referenceId you can reconcile against
  • A nightly reconciliation job, finishing with GET /ledger/health

Tested in sandbox​

  • Happy path end to end: subject → contact verified → wallet → transaction → ledger entry
  • A duplicate Idempotency-Key replays the original response
  • A concurrent duplicate returns 409
  • A 422 you can actually trigger — a disabled transaction type or a balance floor
  • A wrong OTP code, and an exhausted challenge
  • A top-up that you abandon at the gateway
  • A withdrawal attempt by a user who is not KYC-verified — confirm you surface it usefully

Understood, not just read​

  • Your users cannot be marked KYC-verified by you — plan the wait into your onboarding UX
  • SMS verification does not exist; if you need a verified phone at launch, we have talked about it
  • No outbound webhooks yet — your integration polls
  • Your backend can move your users' money without them. A machine token mints a delegated user token for any registered subject, and nothing at the point of payment distinguishes it from a real login. There is no OTP or step-up on money-out today — the design exists, the enforcement does not. Until it ships, the control that a customer authorised a withdrawal is yours to provide, and a disputed transaction has no evidence on our side that they did
  • GET /transactions scopes differently for a machine token and a user token

Before you switch​

  • Production credentials issued and stored somewhere your sandbox keys are not
  • Your privacy notice names GoHubPay as processing your users' identity data
  • Someone on your side owns the reconciliation alert