eMerchantPay#

Configuration (Mozarto back office)#

Pay-In#

POST /v1/api/mozarto/cashier

Required header: x-user-token: Bearer <user-jwt> must be sent with every Pay-In request. See Authentication.

Request body#

3DS v2 browser data: EmerchantPay requires browser fingerprinting for 3DS v2. Populate the browser object from the cardholder's browser at checkout. If omitted, Mozarto falls back to request headers where possible, but the issuer may decline the transaction or force a challenge step.

3DS v2 overrides: threeDs2Control, threeDs2Purchase, and threeDs2MerchantRisk are optional. Mozarto emits safe defaults for every field, so only send these objects to override a specific value for your risk profile.

Example request#

{
  "pspType": "EMERCHANTPAY",
  "type": "PAYIN",
  "baseamount": 100.00,
  "currency": "EUR",
  "firstName": "Jane",
  "lastName": "Doe",
  "email": "player@example.com",
  "phone": "+491701234567",
  "card": {
    "pan": "4111111111111111",
    "cvv": "123",
    "expMonth": "12",
    "expYear": "2027",
    "cardHolderName": "JANE DOE"
  },
  "address": {
    "line1": "123 Main St",
    "postalCode": "10115",
    "city": "Berlin"
  },
  "countryCode": "DE",
  "browser": {
    "userAgent": "Mozilla/5.0 ...",
    "acceptHeader": "text/html,application/xhtml+xml",
    "language": "de-DE",
    "colorDepth": 24,
    "screenHeight": 900,
    "screenWidth": 1440,
    "timeZoneOffset": -60,
    "javaEnabled": false
  }
}

Card data security: Never log, store, or transmit raw card data (pan, cvv) outside of TLS-encrypted channels. The Mozarto backend does not persist raw card data - it is transmitted directly to EmerchantPay and discarded.

Response - direct approval#

{
  "status": "success",
  "isSuccess": true,
  "data": {
    "status": "approved",
    "redirect_url": null,
    "threeds_method_url": null,
    "transaction_id": "mozarto-abc123xyz",
    "unique_id": "emp_unique_id_456",
    "transactionId": "64a1f2b3c4d5e6f7a8b9c0d1",
    "merchantReference": "",
    "transaction_status": "APPROVED",
    "amount": 10000
  }
}

Response - 3DS challenge required#

{
  "status": "success",
  "isSuccess": true,
  "data": {
    "status": "pending_async",
    "redirect_url": "https://3ds.example.com/acs?token=abc",
    "threeds_method_url": null,
    "transaction_id": "mozarto-abc123xyz",
    "unique_id": "emp_unique_id_456",
    "transactionId": "64a1f2b3c4d5e6f7a8b9c0d1",
    "merchantReference": "",
    "transaction_status": "PENDING",
    "amount": 10000
  }
}

Response - 3DS method step#

Webhook#

3DS async: Transactions that require a challenge step will initially resolve to PENDING. The webhook delivers the final status (APPROVED or DECLINED) once the cardholder completes or abandons the 3DS flow. Implement idempotency on your side. See Webhook Setup.

Error codes#

Business rejections (HTTP 200): EmerchantPay may return HTTP 200 with data.status set to "declined" or "error" when the transaction is rejected at the card scheme or risk layer (e.g. insufficient funds, card blocked, 3DS failure). These are not transport errors and do not produce an errorCode response - the full parsed XML data is returned so you can display the appropriate message to the cardholder.