Worthy Payments

Going live

View as Markdown

You build entirely in test mode, then swap to live keys. Nothing else in your code changes. This checklist covers the switch.

Before you flip#

Read the full list once: Integration hard rules (also on the reference checkout).

  • Charges: a successful charge returns status: "succeeded"; you store the id.
  • Declines: a test decline (an amount below 1.00, "amount": 99; the sandbox has no decline card) is handled gracefully (you branch on code, not crash). Buyer UI shows a generic message, never raw fraud reasons. See Testing and Errors.
  • 3-D Secure: status: "requires_action" is handled; you complete the step-up and resubmit the same charge with three_ds.session_id added (never client cavv/eci). See 3-D Secure.
  • Client IP: browser + pk_ charge (buyer peer), server sk_ charge with the buyer's device_session, or, if you proxy /check, body ip = shopper. A server charge without a session is never scored on (or blocked by) your egress IP; it just has no buyer IP. See Charges → Client IP.
  • PAN: only ev: or wp:v1: tokens on charges; raw digits never hit the API.
  • Idempotency: every charge and refund sends a stable Idempotency-Key per order (not a new UUID on every Pay click).
  • /check / decision token: not pre-approval; token optional but strict if sent; send card_bin + last4 when you have them. See Decision token.
  • Device signals: fingerprint / Kount present when CSP allows; empty fails open (sale still runs). See Device data.
  • Keys: sk_ server-only; pk_ + Allowed Domains for browser. Mode on the key, not body.
  • Refunds: full and partial refunds work; you verify with GET /v1/refunds/:id.
  • Rate limits: you back off on 429 honoring Retry-After. See Rate limits.
  • Webhooks: your endpoint is registered, verifies signatures, returns 2xx fast, and is idempotent (dedupes on the event/charge id).
  • Versioning: your key is pinned to a version.

The switch#

  1. Create live keys in the dashboard (pk_live_… / sk_live_… / rk_live_…). Use a restricted key (rk_) scoped to only what each service needs, not a full secret key, wherever possible. See Authentication.
  2. Move secrets to your secret manager. Never commit a live sk_/rk_ key.
  3. Configure your live webhook endpoint and store its signing secret.
  4. Set an IP allowlist on server keys if your infrastructure has stable egress IPs.
  5. Swap the key prefix in your config from _test_ to _live_. Done.

After launch#

  • Monitor the Request-Id on failures and keep them for support.
  • Reconcile periodically with GET /v1/charges (and /v1/events) so a missed webhook never leaves your records out of sync.
  • Roll keys with the dashboard's roll action. The old key keeps working during a short grace window so deploys can drain without an outage.
  • Need higher rate limits for your live volume? Contact support.