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

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.

Official test cards

Some schemes provide test cards, these cards can be used with our Dummy setup or in an end to end preproduction environment if we have a MID to configure against the expected acquirer.

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 when used against our Dummy server which emulates response.  Some cards expect actual issuer data which we are unable to return to the card when used in an emulated environment.

Response simulation

Our Dummy connector allow us to emulate some scenario and responses based on entered amount to help you with integration:

AmountResult triggered
11.00Do Not Honor: generic decline (BRC 100)
11.01Expired card (BRC 101)
11.04Restricted card (BRC 104)
11.06Allowable PIN tries exceeded (BRC 106)
11.09Invalid merchant (BRC 109)
11.16Not sufficient funds (BRC 116)
16.20Partial authorisation (authorised = 16.20 − €0.50), if configured
19.07Card issuer inoperatible (BRC 907): Host timeout with 30 seconds delay
19.09System malfunction (BRC 909): triggers offline if configured

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