Verify your integration before accepting customers

The dashboard [API Simulator](https://dashboard.payerone.com/developer/docs/simulator) shows request examples for checkout, Express Wallet and order lookup. It is a request preview: the page does not send requests, validate your integration or use your credentials.

Prepare the server

Use the current merchant Payments API at `https://api.payerone.com`. Keep the Merchant Token and webhook Private Key in server-side configuration. Replace the example customer and website values with your own controlled test data. Confirm your notification URL is public HTTPS.

PayerOne’s public sandbox is retired. Dashboard credentials are live, and a real request can create live checkout activity. Do not use retired sandbox paths or assume provider test settings are available. Obtain the merchant’s approval for any real payment used in acceptance testing.

Verify these paths

1. Create a checkout from your server and save the returned PayerOne order ID.

2. Confirm the returned checkout URL opens the correct order amount and currency.

3. Send a dashboard **Test Webhook** and verify the signature against the raw body.

4. Confirm a signed test event is accepted without crediting a customer or fulfilling an order.

5. Check authenticated order lookup and the customer-facing waiting state.

6. Confirm the browser return alone cannot set the local order to paid.

Verify repeat handling

Replay a previously accepted event into your own isolated test receiver and confirm it causes no duplicate fulfillment or wallet credit. Exercise your own application’s pending, failed, expired and partially paid handling using controlled fixtures. Do not create a real refund or payment solely to test a UI path without approving that financial action.

If your integration supports refunds, test request construction, stable idempotency keys, non-final statuses and reconciliation. The same intended refund must keep the same key after a timeout. Check that unsupported methods cannot expose a working refund action.

Record which paths you verified locally and which you verified with an approved live payment. Request examples, a delivered test webhook and a completed customer payment prove different parts of the integration.