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 before anyone approves you as a Von Payments merchant.

Provisioning​

A test sandbox belongs to a business, so first start an application (work-email sign-in with a one-time code). Starting it sets up your business; nothing has to be approved before you can build. Then, in the developer dashboard, click Activate Evaluation Sandbox. Only an admin of the business can do this. That creates a sandbox merchant record attached to your business and issues a secret key (vp_sk_test_*) and a publishable key (vp_pk_test_*). They are shown once, when the sandbox is created, so store them then. Without a business, activating is refused with 409 sandbox_needs_a_business.

A sandbox created on or after 16 September 2026 has no expiry date, so a CI job can stay wired to one. The keys 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 and a decline. No funds move.

Test requests run on the sandbox's own processor test account. That processor decides the outcome by order total, and runs real 3-D Secure challenges and issuer declines; use the cards it publishes. A sandbox with no processor test account attached cannot take a test payment: every test request is refused with 422 sandbox_account_required. GET /v1/capabilities reports the connection you are on.

Each business has one test sandbox, and there is no per-platform parent account, so you build and test the connector against your own sandbox. 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.