Sandbox & Testing

The test environment mirrors the production contract: the same endpoints, the same signature scheme, the same statuses.

Environment Host
Test https://pay-in-api.mrcr.io
Production https://pay-in-api.mercuryo.io

Before you start

  • Test credentials (service_id:secret and Sign Key) and wallet test accounts come from your integration manager.
  • Your server IP(s) must be allow-listed for the test environment as well as production.
  • Apple Pay requires the domain that hosts the payment sheet to be registered for the test environment — see Apple Pay onboarding.

What to verify

  1. Signature. Sign the compact JSON body: a signature computed over pretty-printed bytes is rejected. See Authentication & signature.
  2. Both outcomes. Take one payment through to paid and one through to order_failed.
  3. The payment page. Confirm that when a status response carries redirect_data, the buyer is sent to redirect_data.url, passes 3DS there when asked, and returns to your success_url or failure_url.
  4. Polling. Confirm your backend polls GET /sdk-partner/alternative-mobile-pay/mobile-pay/{id}/status from 5 seconds after the create until the status is final.
  5. Webhooks. Confirm delivery to your callback URL, verify the X-Signature over the whole raw request body, and answer with a 2xx — see Webhook signature.
  6. Refunds. Issue a partial and a full refund, then replay the same merchant_refund_id to confirm your idempotency handling — see Refunds.

Going live

Production uses separate credentials, a separate allow-list, and a separate Apple Pay domain registration. Request them from your integration manager once the checks above pass; no code changes beyond the host and credentials are required.