Continuous payment testing
Test card payment systems the way you test the rest of your software
Simulated issuers, switches and HSMs that fail on purpose, ISO 8583 scenarios that run in CI, and load runs that find your limits. Self-hosted, so payment traffic, keys and specs stay in your environment.
Simulation
Counterparties that behave like production, including when it goes wrong
Failure on purpose
Hosts answer by rules: approve, decline with any response code, answer late, never answer, close the connection, answer twice or answer malformed, by card range, amount, message type or any field.
Issuers with real state
Balances, holds, limits and card status that move with every message. An authorization holds funds, a completion posts them, a reversal gives them back, and a repeated request gets the same answer.
Links like production
Sign-on before traffic, echoes, cutover at the end of the business day, and duplicate detection, per connection, as on a real network link.
An HSM to test against
An HSM simulator that speaks the payShield host command format: keys, PINs, MACs and card verification values, under the published test LMK or your own.
Your network's dialect
Model the field layouts of your network, switch or processor from your own specifications, down to sub-elements such as 48.10 or 55.9F26, and every host and scenario speaks it.
TLS on every link
TLS and mutual TLS for hosts, scenarios, load runs and the HSM, with a test certificate authority and a key vault built in.
Tests as code
Scenarios live in your repository and run on every change
A scenario is a readable file: the messages to send and the answers to expect. Review it in a pull request, run it from CI with one command, and get a JUnit report your build understands. The console edits the same files.
Run scenarios against a simulated host or your own system by address, with the test-data guard making sure only test card numbers are ever sent.
name: Authorization basics
target: {simulated_host: Issuer, timeout_ms: 3000}
variables:
pan: "4111111111111111" # test card numbers only
steps:
- name: Small amount is approved
send: {sample: auth, pan: "{{pan}}", amount: 1000}
expect:
fields: {39: "00"}
present: [38]
max_latency_ms: 1000
- name: Large amount is declined
send: {sample: auth, pan: "{{pan}}", amount: 90000}
expect: {fields: {39: "51"}, absent: [38]}Performance
Load, soak and spike, and the highest rate you sustain
load:
search: {from: 500, to: 20000}
workers: auto
mix: [{sample: auth}]
thresholds:
p99_ms: 50
error_rate: 0.001Profiles that match the day
Ramps, steps and spikes, or a steady rate for up to seven days, judged second by second against p95 and p99 latency, errors and the rate achieved.
Find the limit
A search doubles the rate until a threshold is missed, then narrows in, and reports the highest rate your system sustains.
Shared across generators
One run can be sent by several load generators at once, starting together and judged as one.
Honest numbers
Each load generator reports when it falls behind, so a slow generator is never mistaken for a slow system.
Insight
Every message, readable
A log of every exchange
Every message each host sends and receives, decoded field by field, with card numbers masked.
Explained in plain language
An assistant explains any message or failed run, using the model you choose, or none at all.
For your agents too
An MCP server lets AI agents parse and build messages and drive the Platform, with the same roles and limits as people.
Self-hosted
Runs in your environment, not ours
Your data stays put
The Platform runs on your servers or in your cloud account. Payment traffic, keys and specifications never leave it.
Test data only
A test-data guard blocks card numbers outside known test ranges, card numbers are masked everywhere, and results are kept as long as your policy says.
Built on open source
The Platform builds on iso8583sim, the open-source ISO 8583 library for Python, which anyone can inspect and use.
See it running
A live Platform with simulated hosts, scenarios and load runs to explore.