What's new

This is the current version of the MMS Service API, on base path /api/openapi/v1. It covers the four configuration resources you use to onboard a merchant — acquirer profiles, EMV configs, merchants, and terminals — and replaces the earlier /api/v2 Service API, kept for reference under API Reference (Legacy).

Whether you work with one acquirer or several, this is the version to integrate against. The main changes from /api/v2:

• Acquirer bindings live in their own sub-resource. A merchant's acceptance setup is no longer a field on the merchant — it's configured through Merchant payment config, which also lets one merchant settle different payment methods through different acquirer profiles if you need that.
• Acquirer profiles are typed. Each profile has an acqType of card or qr and accepts payment methods of the matching type only — see PaymentMethod.
• currency is explicit. Merchants, EMV configs, and acquirer profiles all carry a currency, and payment-method bindings are made per (acquirer profile, currency) pair.
• Deleting a payment config drops a whole binding, not a single payment method — see Delete Payment Config.

Authentication

Same as before: an Authorization: Bearer {jwt} header, obtained the same way (GET /api/set/key). See Authentication for how to retrieve your token. There is no separate credential to set up for these endpoints.

What happens to the legacy endpoints after the switch

Once your PBO group has been switched over, every legacy configuration endpoint under /api/v2/acquirer, /api/v2/mchInfo, /api/v2/emv, and /api/v2/device — including read (GET) calls — starts rejecting requests with:

{
  "msg": "Your group has open the multi_acquirers;please use the new Service API",
  "code": 13310
}

That switch is set per PBO group as part of onboarding or migration; it is not something you toggle via the API. Treat it as the deadline for moving your integration off /api/v2 — not as a prerequisite for using the endpoints documented here.

Endpoint map

Transaction and Settlement are not versioned with these

Transaction (/api/v2/order) and Settlement (/api/v2/settle) keep working exactly as before, on the same endpoints, whichever version your PBO is on — there is no /api/openapi/v1/order or /api/openapi/v1/settle. Each transaction already records which acquirer profile it settled through at the time it was processed, so looking it up, voiding it, refunding it, or including it in a settlement batch never required knowing "the" acquirer for the merchant as a whole. The version split only applies to the configuration resources above.