Sandbox

Sandbox playground

Interactive console at sandbox.key2pay.ai/sandbox/login — fire test transactions and simulate any scenario from the UI.

Before wiring the API into your code, log into the sandbox playground and exercise every scenario by hand. The console is purpose-built for integrators — initiate payments, force specific status transitions, replay webhook deliveries, and walk every failure branch in the cascade without writing a line of code.

Open sandbox.key2pay.ai/sandbox/login →

How to log in

The login is API-key only — no separate username/password, no email confirmation flow. Paste your sandbox secret key and you're in. Same credential your code will use, so anything you can do in the playground is something your integration can do programmatically.

  1. Open sandbox.key2pay.ai/sandbox/login.
  2. Paste your sandbox secret key — the sk_test_… from your dashboard. Only sk_test_… is accepted (a publishable pk_test_…is rejected); it's the same credential your code uses, so anything you do here your integration can do programmatically.
  3. Hit Enter — the session lasts until you close the tab.
Only sandbox keys are accepted. Pasting an sk_live_… on this page is rejected — production credentials never reach the test console.

What the playground lets you do

Fire test transactions
Pick a built-in test method (sbx_pix, sbx_spei, sbx_card, sbx_pse, sbx_cash), set the amount and country, and submit. The call goes through POST /api/v1/payments using your own sk_test_… — same code path your backend will run.
Test all endpoints
One click runs the FULL suite against the live sandbox API with your key — ping, /me, balance, methods, create/get/list payments, simulate every status, refund, checkout, payouts (balance, methods, create + simulate completed/failed) and webhooks CRUD — and reports pass/fail per endpoint. The fastest way to confirm the whole API works before you integrate.
Drive status with one click
Expand any transaction in the activity feed and use the colored buttons: Mark paid, Mark failed, Expire, Refund, Chargeback. Each one transitions the tx and fires the matching webhook to your registered subscriptions.
See webhook deliveries live
Below each transaction you get a real-time feed of every webhook attempt: event name, target URL, HTTP status your endpoint returned, attempt count, and retry timestamps. Verify your handler end-to-end before you ship.
Walk every failure branch
Trigger fraud blocks, cascade exhaustion, rate-limit errors, invalid-credential paths — exact same error envelopes your code will see in production.

Simulation actions → webhook events

Each click in the playground corresponds to a specific status transition and a precise set of webhook events. These are the same events your handler will receive in production.

ButtonFrom → toWebhook event(s)
Mark paidpending → completedpayment.completed
Mark failedpending → failedpayment.failed
Expirepending → expiredpayment.failed
Refundcompleted → refundedpayment.refunded
Chargebackcompleted (claim opens)chargeback.created, claim.opened
Every webhook delivered from the playground includes sandbox: true and sandboxAction: "mark_paid" in the payload — your handler can branch on these in test environments and ignore them in production.

Recommended day-zero flow

  1. Register a webhook endpoint pointing at a tool like webhook.site so you can inspect the payloads:POST /api/v1/webhooks   body: { url: "https://webhook.site/...", events: ["*"] }
  2. Log into the playground and fire a test transaction.
  3. Expand the transaction in the activity feed, click Mark paid.
  4. Watch the deliveries feed: event name, URL, HTTP status from your handler — all live.
  5. Repeat for failed / expired / refund / chargeback. Verify your handler is idempotent and signature-checks every payload.
  6. When everything looks right, swap sk_test_… for sk_live_… in your code. Done.