What you need
- A sandbox account at merchant.sandbox.vestrapay.app and a test secret key (
sk_test_) from Settings → Developers. - API calls to https://api.sandbox.vestrapay.app/v1 and checkout on https://checkout.sandbox.vestrapay.app.
- A sandbox webhook endpoint registered in the sandbox dashboard. See Webhooks.
Test cards
On the sandbox mock card processor, these card numbers succeed:
Any other card number is rejected, which gives you a simple way to test the decline path. Use any expiry date in the future and any security code.
When CyberSource or MPGS is the active test processor, use that processor’s own test card numbers instead. Hosted checkout works the same either way. If you are building your own card form, remember that the processor decides which numbers are valid. See Pay with card.
Test transfers
You cannot move real money in the sandbox, so Vestrapay lets you decide how a transfer ends. After requesting a virtual account, call the simulate endpoint with the access code:
The endpoint is forbidden on live and returns HTTP 403 there. When the GTBank sandbox is the active transfer processor,
success creates a sandbox virtual account and funds it, so the payment completes through the same webhook path as production.
A test plan
Run every item below before you go live. Each one catches a class of bug that is expensive to find in production.1
Successful card payment
Pay with
4111111111111111. Confirm that a webhook arrives, the signature validates, verify returns success with the right amount, and the order is fulfilled exactly once.2
Declined card
Pay with a number the mock processor rejects. Confirm the customer sees a clear message, can try again, and the order is not fulfilled.
3
Successful transfer
Request a virtual account, then simulate
success. Confirm the same chain as for card.4
Failed and abandoned transfers
Simulate
failed and abandoned. Confirm you receive payment.failed and payment.abandoned, release any held stock, and do not fulfil.5
Repeat delivery
Replay the same webhook, or send it twice. Confirm the second delivery does nothing. Reload your callback page and confirm it does not fulfil twice.
6
Bad signature
Post a request with a wrong or missing signature to your webhook route. Confirm it returns 401 and does no work.
7
Amount mismatch
Alter an order amount in your own data before verify, and confirm your code refuses to fulfil.
8
Expired session
Wait out an access code, or use an old one, and confirm your pay screen handles
session.expired by starting a new payment.9
Splits, if you use them
Configure a service with splits, initialise with a distribution, complete a payment and inspect verify and the dashboard. Confirm the primary account receives the remainder. See Distribution.
Tips
- Make a habit of logging the reference, the X-Request-Id header and the webhook event for every test, so you can trace failures.
- Reuse the same test order IDs in metadata to see how your correlation logic behaves when a customer retries.
- Test with the exact webhook route, proxy and TLS set-up you will use on live. Many signature problems come from a proxy that rewrites the body.
- Sandbox data is separate from live. Services, splits, payment links and webhook endpoints you create here must be recreated on live.