ICCSim Dev
A development tool for writing your own test scripts to run on ICCSim cards. Where TMat runs existing scheme tests, Dev lets you reshape the card's behaviour and data freely, developing error cards and profiles for negative testing.
The testing problems this solves
You can create card conditions that the standard scheme suites cannot produce. Deliberately faulty cards — a missing mandatory tag, a malformed field — let you observe how the POS or ATM behaves.
What you can develop
You can reuse existing scripts, clone a real card, or build from scratch.
| Aspect | Coverage |
|---|---|
| How scripts are created | Import an existing ICCSim script; read a physical test card and turn the clone into a template; or build from scratch using Card Configuration and Building Blocks |
| What can be edited | Any EMV tag or byte within the script can be changed |
| Examples of error cards you can build | Missing mandatory tags; incorrect tag length or format; unsupported AIDs; malformed AIP, AFL or CVM List; a mismatch between the PAN and Track 2; expired cards; forced online; offline decline; AAC, ARQC and TC branches; invalid status words; and faulty SDA certificates |
| Supporting features | Tag Change Facility / DES Calculator / Certificate Generator / Card Data Capture / Cloning |
| Project structure | Test Scripts for behaviour scenarios; Components for shared blocks; Data Tables for tags, values and cryptographic data; and the output directory |
| Output | Download the script you have built onto an ICCSim card and use it for POS or ATM testing |
| Interface | Contact / contactless / dual interface |
Supported terminals and environments
The cards you build are for development, debugging, QA and regression testing. They present your own profiles to real POS and ATM equipment.
Formal certification is carried out with ICCSimTMat and its qualified suites. This tool is for building and debugging during development.
Limits regarding certification
Scripts written in ICCSimDev are useful for development, debugging, QA and regression, but writing one does not make it a scheme-approved test case. Formal certification uses the TMat test suites approved by the scheme, with the prescribed test cases.
If you regenerate certificates, they use your own test keys rather than the usual scheme CA keys, so the corresponding new CA public key must be loaded into the test terminal. Certificates created in ICCSimDev are not authenticated by production terminals in the field; they are used in a closed development environment where the terminal has also been switched to the dedicated test key configuration.
Choosing between the ICC Solutions products
The general-purpose ICCSimTMat, the Fiserv-only kit and the Worldpay-only VIABLE are clearly separated.
| Comparison | TMat | TMat for Fiserv | ICCSimDev | Merchant Cards | VIABLE |
|---|---|---|---|---|---|
| General purpose or dedicated | General purpose | Fiserv only | General-purpose development | General-purpose basic cards | Worldpay only |
| Primary audience | Vendors, laboratories and acquirers | Fiserv merchants and ISVs | EMV developers | Stores, maintenance and training | Worldpay merchants and ISVs |
| Level 2 | Suite available | Mainly Level 3 | Custom-developed testing | Not possible | Mainly Level 3 |
| Level 3 | Supported | Supported | Not for formal certification | Not possible | Supported |
| Host integration | External or simulated | Fiserv Portal integration | Outside its purpose | Requires a test host | Built-in closed loop |
| Negative testing | Scheme test case coverage | Fiserv test case coverage | Highly flexible | Limited | Worldpay test case coverage |
| Automated analysis | Yes | Yes | Focused on script development | No | Yes |
| Certification submission | Through suites | For Fiserv | Generally not possible | Not possible | For Worldpay |
| PaytestProbe | Supported | Supported | Focused on generated cards | Not supported | Supported |
Where the product sits in the process
On the issuance side, the Barnes and ICC Solutions products are not competitors; they sit at different stages of the process.
| Process stage | Product | Objective |
|---|---|---|
| Card issuance side | Barnes CPT | Inspects card data, certificates, EMV tags and magnetic stripe data |
| Card and terminal development | ICCSimDev | Develops error cards, custom cards and negative tests |
| Terminal kernel | ICCSimTMat Level 2 | Verifies the EMV kernel and reader application |
| Finished POS and ATM | ICCSimTMat Level 3 | Scheme integration testing |
| Specific acquirer | TMat for Fiserv / VIABLE | The Fiserv and Worldpay certification process |
| After store deployment | Merchant Test Cards | Quick checks, regression testing and staff training |
What we confirm before proposing
Before finalising a configuration we ask about the following.
| Category | Points to confirm |
|---|---|
| Test scope | How far coverage must extend across contact, contactless and magnetic stripe, and whether Level 2, Level 3 or both are needed |
| Scope | Which of POS, ATM, Tap to Phone, transit or fuel applies, and the exact scheme and test suite versions |
| Connects to | Which acquirer you connect to — Fiserv, Worldpay or another |
| Method | Whether physical ICCSim cards or PaytestProbe is used, whether physical cards for fallback testing are included, and whether a host simulator is required |
| Licences and maintenance | Maintenance charges after the first year and what happens if renewal stops, the expiry of the test cards, and how licences are divided between the scheme-qualified suites and development scripts |
| Automation | The API specification for Auto API and robot integration, and compatibility between cards generated in ICCSimDev and TMat |
| Domestic requirements | Is a dedicated L3 test plan available for the local acquirer or payment network? |
Supporting an international brand’s L3 suite and having the local acquirer or payment network accept that result as certification are two separate matters. We confirm the brand, acquirer, payment gateway and terminal configuration before fixing the product configuration.
Choosing the right ICC product
The ICC products divide by purpose. Where each sits is set out in the Level 3 layer.
| Product | If you are considering |
|---|---|
| ICCSimTMat | You need to pass formal scheme approval at Level 2 and Level 3, and want acceptance testing managed and run with qualified suites |
| ICCSimTMat for Fiserv | Merchant and ISV certification through Fiserv, with test logs uploaded directly via the portal |
| ★ ICCSimDev (this page) | You want to build your own card responses and error conditions, for negative testing and debugging |
| VIABLE | You want to run merchant and ISV acceptance testing together in a closed-loop store setup |
| Merchant Test Cards | You want physical cards for checking terminal configuration, regression and staff training |
| Testing and certification services | You would rather not run the testing yourself and want certification handled for you |
Where it is used
- Setting up Level 3 verification for a new development
- Regression after a configuration change or update
- Coverage checks ahead of certification
Relationship to certification
This is a tool for development and debugging. Formal scheme approval is carried out with the qualified suites in ICCSimTMat.