Testing

Test mode is designed to exercise the payment flow without moving real funds on-chain. It uses the same https://apa.app/v1API shape and the same event names you'll see in production, so your integration can rehearse order handling before live settlement.

Test-mode API keys are planned and will be clearly labelled so they can never be confused with live credentials. Calls made with a test key never settle to a real wallet and never appear in your live payment list.

Send a sample event to one of your registered endpoints with POST /v1/webhooks/test. The payload is signed with that endpoint's real whsec_ secret, so it exercises the exact same HMAC verification path as production traffic — a true test of your handler, not a stub.

curl https://apa.app/v1/webhooks/test \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "endpoint_id": "we_123", "event": "payment.paid" }'

200 OK
{ "data": { "delivered": true, "response_code": 200 }, "request_id": "req_7qP1zM5x" }

Fire the failure events too — payment.failed and payment.expired — and confirm your order states recover cleanly. Make handlers idempotent: an event may be delivered more than once.

Once test-mode sessions are enabled for your account, you will be able to create sessions that simulate the customer flow so you can drive your UI through every state — created, paid, failed — without a real wallet or on-chain settlement. A sandbox session uses the same request and response shape as a live one, then emits lifecycle webhooks against an isolated sandbox ledger.

curl https://apa.app/v1/checkout/sessions \
  -H "Authorization: Bearer sk_test_…" \
  -H "Content-Type: application/json" \
  -d '{
    "payout_wallet_id": "pp_test_123",
    "amount": "10.00",
    "currency": "USD",
    "order_id": "test-001"
  }'

# → marks paid against the sandbox ledger and
#   emits the same payment.paid webhook as live mode.