Skip to main content

Platform Integrator Sandbox

You are integrating Von Payments into a platform — a CRM, a cart, an ISV product, an order-management system — and need a sandbox to build the connector against without being a Von Payments merchant.

Provisioning​

In the developer dashboard (work-email sign-in with a one-time code), click Activate Evaluation Sandbox. That creates a sandbox merchant record, attaches Von Payments' test emulator so sessions route without boarding a processor, and issues your test keys — vp_sk_test_*, vp_pk_test_*, ss_test_* — shown once at /dashboard/developers/api-keys. If your account holds a business, the sandbox is attached to it; if not, you get one of your own.

Every sandbox expires 30 days after it is created

A personal sandbox is archived when it passes (and if you join a real merchant team); a business-attached one is closed and deleted. Either way the keys go with it, so a CI job wired to a sandbox stops working about a month in and the keys look like the culprit — note the date and re-provision. The keys themselves carry no TTL of their own — they stay active until rotated or revoked, with the same rotation grace as live keys.

What the sandbox does​

Everything the public API surface exposes: create and retrieve sessions, receive signed webhooks at endpoints you register under /dashboard/developers/webhooks (charge.*, payment_intent.* and the rest of the catalog), confirm a payment on the return, and exercise the happy path, a decline and a 3-D Secure challenge. Outcomes are decided by card number (Embedded Fields) or amount (hosted checkout, one decline trigger: 200) as listed on Test mode & test cards; no funds move.

What it does not do: hosted checkout has no 3-D Secure, no issuer-specific declines and no timeouts; there is no per-platform parent account — to simulate ten of your customers, create ten sandboxes; live keys (vp_sk_live_*) follow each merchant's own approval.

How this fits the gateway-adapter pattern​

Your platform's existing gateway integrations take per-merchant keys in a per-merchant gateway-config form; Von Payments fits the same shape. When a merchant of yours chooses Von Payments from your gateway dropdown, your form asks for their vp_sk_live_* (server-side), vp_pk_live_* (publishable) and a webhook endpoint URL on your side — never their ss_live_*, which nothing in the integration uses. Your adapter calls the API server-to-server with that merchant's key, receives webhooks at the registered URL, and verifies each with that endpoint's whsec_* secret. Your sandbox keys stand in for "a merchant of yours that happens to be your dev account", so the whole flow is testable without a real merchant.

The Platforms integration spec is the one-page reference for the API surface, webhook format, idempotency and error catalog; the connector runbook is the sequence; a Node.js reference adapter is at vonpay-samples/platform-integrator-nextjs. To be listed once the connector is live, contact your Von Payments contact.