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:secretandSign 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
- Signature. Sign the compact JSON body: a signature computed over pretty-printed bytes is rejected. See Authentication & signature.
- Both outcomes. Take one payment through to
paidand one through toorder_failed. - The payment page. Confirm that when a status response carries
redirect_data, the buyer is sent toredirect_data.url, passes 3DS there when asked, and returns to yoursuccess_urlorfailure_url. - Polling. Confirm your backend polls
GET /sdk-partner/alternative-mobile-pay/mobile-pay/{id}/statusfrom 5 seconds after the create until the status is final. - Webhooks. Confirm delivery to your callback URL, verify the
X-Signatureover the whole raw request body, and answer with a2xx— see Webhook signature. - Refunds. Issue a partial and a full refund, then replay the same
merchant_refund_idto 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.