Pay-ins
Accept card payments made through a native mobile wallet. Every pay-in is created through one endpoint — POST /sdk-partner/alternative-mobile-pay/mobile-pay — where the pay_system field identifies the wallet. Status tracking, refunds, and webhooks are common to every method.
Base URLs
| Environment | Host |
|---|---|
| Test | https://pay-in-api.mrcr.io |
| Production | https://pay-in-api.mercuryo.io |
Your integration manager issues credentials and allow-lists your server IP(s) for the target environment.
Payment methods
| Method | pay_system |
Guide |
|---|---|---|
| Apple Pay | apple |
Apple Pay |
| Google Pay | google |
Google Pay |
| Card payments | — | Card payments — coming soon |
Common to every pay-in
- Authentication & signature — the
Sdk-Partner-TokenandX-Signatureheaders. - Payment statuses — status values, polling, and the status response.
- Webhooks — final-status delivery for payments and refunds.
- Refunds — full and partial refunds, with idempotency.
New to the API? Start with the Quick Start.
Handling errors
For JSON pay-in and refund endpoints, errors contain status, code, and message; validation errors may also contain data with messages for individual fields. Use the documented HTTP status and operation semantics to decide how to handle the error. Keep code and message for diagnostics and support; do not depend on exact error text or an exhaustive list of numeric codes. The API Reference defines the response shapes and provides representative examples.
| Response | What to do |
|---|---|
400 — invalid request |
Correct the request using data field errors, when provided. Repeating the unchanged request will not fix it. |
401 — authentication failed |
Check the credentials for the target environment and the request signature. |
403 — access denied |
Check the shop's enabled features and access settings with your integration manager. |
404 — payment not found |
Use the payment's data.id from the create response, with the same shop and environment. This is not a payment failure status. |
409 — refund idempotency conflict |
Check the original refund request. Reuse its key and parameters for a retry; use a new key only for an intentionally separate refund. See Refunds. |
422 — operation rejected |
Check the reason and the payment's current state before submitting again. For example, a payment that has not completed cannot be refunded. |
5xx or no response |
Treat the outcome as unresolved. Check the status if you have the payment id; retry with a delay and preserve the original operation key. |
These responses apply where listed for the endpoint. A network timeout or server error does not prove that an operation failed. Assign and save your own merchant_transaction_id before the first create request, even though the field is optional. The id must be unique across all of your shops and operations: an existing operation is looked up by merchant and id, so an id already used in another shop, or as a merchant_refund_id, returns that earlier operation instead of creating a payment. If omitted, each request receives a generated key, so repeating the request can create another payment. When retrying creation, keep the same merchant_transaction_id or merchant_refund_id to avoid creating a second operation. Set a limit on automated retries and waiting; if the result remains unresolved, contact support and continue accepting late webhooks. See Payment statuses.
Payouts use a separate XML contract: HTTP 200 can carry a business error. See Payout statuses and the payout endpoint's API Reference.
Support
Visit the Help Center for Merchants.