Quick Start

A pay-in takes five steps: get credentials, collect a wallet token, create the payment, poll the status and send the buyer where redirect_data points, confirm the final status.

1. Get credentials

Your integration manager issues:

Sdk-Partner-Token credentials in the form service_id:secret;
a Sign Key for the X-Signature header;
an allow-list entry for your server IP(s), per environment.

Apple Pay also requires domain registration — see Apple Pay onboarding.

2. Collect a wallet token

Collect the payment token on your frontend with the wallet's own API and pass it to your backend. pay_token is always Base64, and each wallet has its own payload inside:

Apple Pay — Base64 of the token.paymentData JSON. See Apple Pay.
Google Pay — Base64 of paymentData.paymentMethodData.tokenizationData.token. See Google Pay.

3. Create the payment

Send the token and the buyer's details from your backend. Sign the compact JSON body with your Sign Key — see Authentication & signature.

curl -X POST https://pay-in-api.mrcr.io/sdk-partner/alternative-mobile-pay/mobile-pay \
  -H 'Sdk-Partner-Token: 42:your-secret' \
  -H 'X-Signature: <hex HMAC-SHA256 of the compact JSON body>' \
  -H 'Content-Type: application/json' \
  -d '{"pay_system":"apple","pay_token":"<base64 payment token>","merchant_transaction_id":"order-8841","email":"john.doe@example.com","name":"John Doe","fiat_amount":"10.00","fiat_currency":"USD","ip":"203.0.113.10","billing_address":{"country_code":"DE","city":"Berlin","zip_code":"12345"},"success_url":"https://shop.example.com/checkout/success","failure_url":"https://shop.example.com/checkout/failure"}'

{
  "status": 200,
  "data": { "id": "28a3c125a28075453", "status": "pending" }
}

Include success_url and failure_url (HTTPS): the payment page returns the buyer there. Google Pay requires them.

4. Send the buyer to the payment page

Poll GET /sdk-partner/alternative-mobile-pay/mobile-pay/{id}/status from 5 seconds after the create ({id} is data.id). When a response carries redirect_data, redirect the buyer's browser to redirect_data.url. It leads to the Mercuryo payment page, which runs the 3DS device check and the 3DS challenge when the issuer asks for it, then returns the buyer to your success_url or failure_url. Some payments start only after the buyer opens this page — see Apple Pay.

5. Confirm the final status

New payments start as pending. Assign your own merchant_transaction_id before the first request and reuse it for every retry of that payment — the rules for retries and unresolved outcomes are in Handling errors.

Start polling GET /mobile-pay/{id}/status 5 seconds after the create and continue until the status is final; webhooks can bring the result sooner. Follow Payment statuses for final outcomes, required actions, and handling an unknown or long-running status. A browser redirect to your success_url is not payment confirmation.

Ready for the details? Continue with Sandbox & Testing.

Overview

Sandbox & Testing