Any ISO 8583 interface
Nothing is hardcoded to one network. Point FlexSim at a switch, an issuer host, an acquirer front end or a test harness, and describe what that link expects.
Universal ISO 8583 simulator
One simulator. Any ISO 8583 interface.
Describe the message format you actually have to talk to, save your cards and keys once, and drive the link from either end. FlexSim is not built around one scheme — the specification is data you edit, not code someone else compiled.
Windows, macOS and Linux. No installer — unzip and run.
DE-2Primary account numberfrom saved card
DE-3Processing code000000
DE-4Amount, transaction000000015000
DE-11Systems trace audit numberauto
DE-35Track 2 datacomposed
DE-52PIN blockcalculated
DE-55ICC datacalculated
0210 DE-39 00 Rules passed
41 ms
AnyISO 8583 interface
2Modes: acquirer and issuer
3Framing header lengths
5Platform builds
Capabilities
Everything the exchange needs, in one window
Not a message builder with a socket bolted on. FlexSim covers the format, the card data, the calculation, the connection, the checking and the record — because a test that is missing any one of those is not a test.
Any scheme, edited not compiled
Build the message format in the app: fields, lengths, encodings, bitmap format, application headers and nested subfields. Switch the active specification without restarting.
Acquirer and issuer modes
Answer requests as the issuer host, or send them as the acquirer. The same test case definitions serve both directions — it is a setting on the case, not a separate tool.
A rule set per test case
Say what a correct reply looks like — per field, per case — and let the run decide pass or fail instead of you reading hex. Checking can be switched off per case without losing the rules.
Save a card once, use it everywhere
PAN, expiry, service code, PIN, sequence number, track 2 layout and every verification value live on the card. Any test case can reach them, so a card change lands in all of them at once.
Auto-calculated from your keys
Store the keys once and let FlexSim work out the values that depend on them — verification values, PIN blocks, message authentication codes and chip cryptograms — instead of pasting figures from somewhere else.
Server or client, your header length
Dial out as a client or accept connections as a server, with the length header the link actually uses rather than the one a tool assumed.
Every message, parsed on screen
Requests and responses shown as named fields, not a wall of hex — with the raw bytes still there when you need them. Colour-coded and readable at a glance.
Go back through every run
Past exchanges are kept and searchable long after the session that produced them, so a question about last week's test has an answer.
Modes
Whichever end you are missing, FlexSim is it
Testing an authorisation flow always means standing in for the party you do not have. FlexSim stands in for either one, and moving between them is a setting on the test case — not a different tool and not a second set of message definitions to keep in step.
Each mode is named for the system you are testing, and FlexSim plays the other side of the link.
Acquirer mode
Answer requests as the host
You are testing an acquirer — a terminal, an ATM or an acquiring switch. FlexSim stands in for the issuer host: it listens on a port, checks each incoming request against your definition and sends the reply — approval, decline, or any response code you want to see handled.
- Test a terminal or switch when the real host is not available
- Return a specific response code on demand and watch it being handled
- Echo fields straight back from the request, or set them explicitly
- Answer a fixed number of requests, then release the port
Issuer mode
Send requests to a host
You are testing an issuer host. FlexSim stands in for the acquirer: it opens the connection, sends the authorisation request, and checks the reply against the rules on that test case.
- Certify an issuer host or a switch against your message format
- Reproduce a production message from a captured hex dump
- Repeat a case for volume with an iteration count
- Read the response decoded field by field, hex kept alongside
Card data
Enter the card once. Every case gets it.
A saved card carries everything a message might need from it, and test cases reference the card rather than copying values out of it. Change the expiry and every case that uses that card sends the new one.
- PAN, expiry, service code, PIN and card sequence number
- Verification values — CVV, CVV2, iCVV and PVV with its key index
- A track 2 layout saved per card, so the track reproduces exactly
- Keys referenced from a shared store rather than pasted per card
- Stored encrypted on your machine, and left out of any suite you export
Saved card
PAN 476173••••••0009
Expiry 2809
Service code 501
Sequence 01
// calculated from the saved keys
CVV 092
CVV2 418
iCVV 733
PVV 4173 (key index 1)
Expiry 2809
Service code 501
Sequence 01
// calculated from the saved keys
CVV 092
CVV2 418
iCVV 733
PVV 4173 (key index 1)
Referenced from any test case, in any specification.
Calculation
Values worked out, not looked up
Keys are stored once in the key manager and referenced by the cards that use them. Anything derived from a key can then be calculated on demand — so a test stays correct when the card, the amount or the key changes.
- Card verification values, including the chip variant
- PIN verification values, from the PIN and the verification key
- PIN blocks, formatted and encrypted under the PIN key
- Message authentication codes over the assembled message
- Chip cryptograms for the request, and the issuer's answer to them
- Fields that mirror the message itself — trace numbers, amounts, dates, counters
When something needed for a calculation is missing, FlexSim names what it is waiting for rather than quietly leaving the field blank.
Key store
// held once, shared by every card
CVK card verification
PVK PIN verification
ZPK PIN block encryption
MAC message authentication
AC chip cryptogram master
// each shows its check value as you type
KCV verified before the key is saved
CVK card verification
PVK PIN verification
ZPK PIN block encryption
MAC message authentication
AC chip cryptogram master
// each shows its check value as you type
KCV verified before the key is saved
Rotate a key once and every card that references it follows.
Validation
Rules per test case, so a run reports itself
Each case carries its own expectations of the reply. Run a suite and you get pass or fail per case, not a log to read line by line.
Say what a good reply looks like
Rules are attached to the case, so the same message sent in two contexts can be judged by two different standards.
Checking switches off without loss
Turn validation off for a case and it still runs and still sends — the reply simply is not judged, and the rules are waiting when you turn it back on.
Results you can send on
Suite results stream in as each case finishes and export as a spreadsheet or a self-contained report, with the raw bytes kept for anything that failed.
Transport
Server or client, with the header your link uses
ISO 8583 says nothing about how a message is delimited on a stream, which is why every link does it differently. FlexSim makes the framing a setting rather than an assumption, and works from either end of the socket.
- Client mode — dial out to the host under test
- Server mode — listen and accept the connection instead
- Two-byte, four-byte or TPDU length headers
- Application headers ahead of the message, if the specification has them
- Connection state visible while a run is going, and released cleanly on stop
Framing
// two-byte length header
00 86 ISO0050005000800822000…
// four-byte length header
00 00 00 86 ISO0050005000800822…
// TPDU header
60 00 01 00 01 0800822000…
00 86 ISO0050005000800822000…
// four-byte length header
00 00 00 86 ISO0050005000800822…
// TPDU header
60 00 01 00 01 0800822000…
Chosen per connection, not baked into the build.
Visibility
See it, keep it, and make it yours
A simulator is only as useful as what it shows you afterwards. FlexSim parses every message on screen, keeps the history, and writes a plain text copy to disk.
Parsed, colour-coded, readable
Requests and responses broken out into named fields as they happen, with the hex and the character rendering beside them. Nothing is trimmed away mid-run.
Every previous test case
Past exchanges stay in the database, grouped by specification, with their decode intact. Select any one and read it exactly as it looked when it was sent.
Skin it the way you work
Light and dark themes, and log colours you set yourself. Every change applies as you make it, and closing without saving puts it back.
A plain text log is written to disk as well. It mirrors what is on screen, rolls at a size you choose and again at midnight, and lands in a folder you pick — so evidence for a test outlives the window it ran in.
Also in the box
The smaller things you end up needing
The parts that are not headline features but decide whether a testing day goes smoothly.
Group cases and run the tree
Cases live in suites per specification. Run one, run the lot, or set an iteration count to push volume through the same case.
Start from a captured message
Paste a hex dump and FlexSim parses it against the active specification, turning it into a test case with the fields already filled in.
Export suites, keep the secrets
Suites round-trip through JSON and XML so a colleague can import yours. Card and key material is deliberately left out of the file.
The lookups, built in
Response codes, currencies and their minor units, card number and scheme checks, an encoding converter, a TLV decoder and key utilities — no second window on another screen.
A master password, if you want one
Card and key material is encrypted at rest. Set a master password and the database is re-encrypted under it, with the app locked until it is entered.
One file holds your work
Specifications, suites, cards, keys, settings and history live in a single database file. Copy it to another machine and carry on where you stopped.
Install
Two files, no installer, no service
A FlexSim build is the executable and a template database. Everything you create lives in one file in your user data folder, which you can copy to another machine and carry on.
- No administrator rights and nothing written to the registry
- The first run seeds your database from the bundled template
- Rebuilds and cleans cannot reach your data — it sits outside the build folder
- Startup logs the database path, so there is never a question which file is live
What you unzip
FlexSim-win-x64/
FlexSim.exe — self-contained
Assets/
simulator.db — first-run template
// on first launch
Database: %LOCALAPPDATA%\FlexSim\simulator.db
FlexSim.exe — self-contained
Assets/
simulator.db — first-run template
// on first launch
Database: %LOCALAPPDATA%\FlexSim\simulator.db
Time to first window: 2.8 seconds, precompiled ahead of time.
Start sending messages in about a minute
Download the build for your machine, unzip it, run it. The app opens with a working specification and a sample suite already in place.
Windows · macOS · Linux · x64 and ARM64