Test your integration

Test your integration

Testing your ECR integration lets you confirm that your Point of Sale (POS) communicates correctly with the Market Pay payment terminal before moving to production. A structured test campaign catches integration defects before moving to production.

Pre-requisite

You should have a pre-production terminal connected to the Market Pay test (Dummy) acquiring host. No real funds move: declines and approvals are simulated.

The POS Integration Test Suite

The POS Integration Test Suite is a self-contained test book that walks you through a complete integration campaign and lets you record your results, no account and no server required. Everything is stored locally in your browser. This tool allows you to:

  • Filter tests to your scope. Select your protocol (Cloud API, Local API HTTP or TCP/IP, App2App) and toggle optional features (pre-auth, DCC, tip, surcharge, S&F, etc.). The book hides tests that do not apply — for example, the Session category is removed automatically for Cloud API.
  • Cover the full standard book across six categories: Session, Transaction, Decline Scenarios, Abort & Cancel, Resilience, Special Transactions.
  • Give each test a scenario, the exact trigger amount, the expected response fields, and a developer hint — plus per-protocol request/response message examples.
  • Record pass / fail / not-run per test and lets you export a JSON snapshot to share with your Market Pay contact or archive for certification.
  • Customize: add, edit, or remove tests and whole categories when your integration needs something beyond the standard book.

Note

You can download the POS Test Suite in this page.

Which cards to test with

Card emulator (recommended)

The primary tool for the campaign is scheme card emulator together with the Dummy Server. Scenarios are triggered by the transaction amount: the Dummy Server returns a specific Bank Response Code (BRC) based on the amount you send. This gives you deterministic, repeatable control over declines, errors, partial approvals, and special flows, without needing different physical cards.

For example:

AmountResult triggered
11.00Do Not Honor — generic decline (BRC 100)
16.20Partial authorisation (authorised = 16.20 − €0.50)

Using your own personal cards

You can also use your own personal cards in pre-production. Because the pre-production environment is connected to the Dummy acquiring host, there is no financial impact, no real authorisation, capture, or settlement takes place against your card.

This is a useful complement to the emulator when you want to validate real-card behaviour: contactless taps, real chip reads, real PIN entry, and the cardholder experience on the terminal screen.

Warning

Contact (chip) transactions only: depending on the card, a contact / chip transaction may be declined. This is expected and is a property of the card, not a defect in your integration. Contactless taps are generally unaffected. If you need a guaranteed approval or a specific decline reason, use the card emulator with the corresponding trigger amount instead.

Reading the result correctly

When checking a transaction outcome, verify the response at field level, not just the HTTP status:

  • Approval/decline lives in the message, not only the HTTP code. An HTTP 200 can still carry a declined payment. Check the result field inside the response message.
  • Local API HTTP uses a POST → poll pattern. POST returns 202 Accepted; you then GET-poll. A 206 means in progress — keep polling; a 200 is the final result. Never close a transaction on 206.
  • Store the POITransactionID returned by the terminal. Reversals, refunds, and status queries reference it — not your own sale reference.
  • Keep ServiceID unique per transaction within a session. Reusing it breaks duplicate-payment protection.
  • Flag offline approvals separately. When the result indicates an offline approval, your POS should record it distinctly from online approvals.

Completion criteria: when are you done?

  • All MANDATORY tests pass. These are blocking for go-live.
  • RECOMMENDED tests pass, or any failures are documented and accepted.
  • CONDITIONAL tests pass for every optional feature in your scope (pre-auth, DCC, tip, surcharge, S&F, etc.).
  • Your completed campaign (Export from the test suite) is shared with your Market Pay contact.

Need help with your campaign? Contact your Market Pay integration contact or raise a request through Market Pay Assist.

Attachments

Attachments