Skip to content
StraventaDocs
Guides

Going Live

Pre-production checklist for 505pay integration — KYB, credentials, webhooks, 3DS, and settlement verification

Going Live

Complete this checklist before switching your integration from sandbox to production. Each item must be verified before your first real transaction can process.

Production transactions move real money. Complete every item below before enabling production credentials in your application.

Checklist

Business verification

  • KYB documents submitted — Submit Know Your Business documentation via dashboard.505pay.link under Settings → Verification. Required documents: business registration certificate (NIB/SIUP), tax ID (NPWP), director ID (KTP), and bank account ownership proof.
  • KYB approved by ops — Verification takes 1–3 business days. You will receive an email confirmation when approved. Do not proceed until KYB status shows Approved.

API credentials

  • Production API credentials issued — After KYB approval, generate production CLIENT_ID and CLIENT_SECRET under Settings → API Credentials. These are separate from sandbox credentials.

  • Credentials stored securely — Store production secrets in a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager, etc.). Never commit them to source control or log them.

  • Production base URL configured — Update all API calls to use the production aggregating host. Every API surface routes through api.505pay.link in production (mirroring the sandbox.505pay.link host you used in development):

    • All services (auth, payments, recon, pos): https://api.505pay.link

    The docs-console's environment toggle (top-right) flips every code sample between sandbox.505pay.link and api.505pay.link — so the same recipe runs unchanged across both.

Webhooks

  • Production webhook URL configured — Register your production webhook endpoint with the production API. The endpoint must be publicly accessible over HTTPS.
  • Webhook secret rotated for production — Generate a new signing secret for your production webhook subscription. Never reuse the sandbox secret.
  • Signature verification implemented — Confirm your webhook handler verifies X-Straventa-Signature on every delivery. See Webhooks for the verification implementation.
  • Webhook endpoint tested end-to-end — Trigger a test delivery from the dashboard and confirm your handler processes it correctly.

3DS (card payments)

  • 3DS production keys configured (MPI integration) — If you are processing card payments, configure your 3DS MPI (Merchant Plug-in) with production keys issued by your acquiring bank. Sandbox 3DS does not require real MPI keys — production does.
  • 3DS flow tested with a real card — Complete at least one end-to-end 3DS authentication with a real test card on the production environment before go-live.

Settlement

  • Settlement bank account verified by ops — Provide your settlement bank account details under Settings → Settlement. Ops will perform a micro-deposit verification (typically 1–2 business days).
  • Settlement schedule confirmed — Review your settlement schedule (T+1 or T+2 depending on your merchant tier) under Settings → Settlement.

Compliance and security

  • Callback domain added to CORS allowlist — Add your production frontend domain(s) under Settings → Security → Allowed Origins to prevent CORS rejections on browser-initiated API calls.
  • Idempotency keys implemented — Confirm all payment creation and refund requests send X-Idempotency-Key to prevent duplicate charges on network retries. See Idempotency.
  • Error handling tested for production error codes — Test your error handling paths using the production sandbox simulator before accepting real traffic. See Errors.
  • Rate limit handling implemented — Confirm your integration handles 429 Too Many Requests with exponential backoff. See Rate Limits.

Final review

  • End-to-end test on production credentials in staging — Run a full happy-path transaction (create payment → simulate completion → receive webhook → verify status) using production credentials against a staging environment before directing real customers.
  • Monitoring and alerting configured — Set up alerts for elevated 4xx/5xx rates on your side and for webhook delivery failures.
  • Runbook documented — Document your rollback procedure in case of integration issues post-launch.

After go-live

  • Monitor X-RateLimit-Remaining headers and contact support proactively if you anticipate traffic spikes.
  • Subscribe to the status page for incident notifications.
  • Review settlement reports daily during the first week to confirm amounts match expectations.

Support

For go-live assistance, contact [email protected] with subject Go-live request — [your business name]. Include your tenant_id and planned launch date.

Was this page helpful?

On this page