6 posts tagged with "iso8583"

The XML-based Client Simulator in jPOS-EE has been useful for generating ISO 8583 traffic and checking responses for many years. The new Client Simulator is a major overhaul of that work, integrated into the jPOS Control Plane.

Sending a message is only part of an automated test. Before an authorization can produce a meaningful result, somebody has to provision the card, fund its account, and put its velocity counters into a known state. Afterward, checking the response code is not enough: the test may also need to verify the hold, the fee, or the entries posted to the ledger.

When those operations live outside the simulator, the test depends on setup scripts and assumptions about what happened during the previous run. The Control Plane brings them into the test itself. A case can combine platform operations with ISO 8583 exchanges and assertions, preparing its own state and checking the financial consequences. The messages still go to a live issuer; the surrounding work becomes part of a repeatable test.

The updated video shows this against jCard, including how a result connects to the messages on the wire, the issuer’s participant trace, and the resulting ledger entries.

The first Counterpart demonstration used Bitcoin because it makes the cost of two copies impossible to ignore. A transaction on a public network and a ledger entry inside an institution are plainly different things. Somebody has to connect them, explain the confidence of that connection, and deal honestly with reversals.

This video starts closer to home: two entities on the same Control Plane. ACME Services raises an invoice. Beta Retail sees it as a proposed payable and accepts it. Both sides settle the same advice.

Payment systems are only as trustworthy as the testing behind them.

For an issuer, correctness is not just a response code. It is the ISO 8583 message on the wire, the product rules that shaped the decision, the ledger entries that were posted, and the evidence an operator can inspect later.

The new Client Simulator demo shows that loop end to end on the jPOS Control Plane: a live jCard issuer, a real CMF channel, a functional test suite, raw logs, and a reconciled general ledger.

The jPOS Common Message Format specification is getting an update. CMF v3 is still a work in progress, but an early-access draft is available at jpos.org/doc/jPOS-CMFv3.pdf for anyone who wants to follow along. The most significant addition in v3 is first-class support for the ISO 8583 dataset model—and that's what this post is about.

Since ISO 8583:2003, the standard has defined three types of data elements: primitive, constructed, and composite. Primitive and constructed fields have always had first-class support in jPOS. The third type—composite fields—has historically been treated as opaque binary blobs, with application code responsible for parsing their contents manually.

jPOS 3.0.2 changes that.

The jPOS tutorial has been expanded with several new sections covering some of the most commonly used — and most commonly misunderstood — parts of the framework.