5 posts tagged with "jcard"

Issuing a batch of cards is not simply calling the issuance service in a loop. The operation needs a defined scope, durable progress, a way to recover after interruption, and a result an operator can inspect without reconstructing it from server logs.

The jPOS Control Plane’s bulk-issuance task brings those responsibilities into Job Control. An approved job definition establishes what may run; each execution has its own inputs, status, progress, and reports. The browser submits the request and follows the run. It does not have to remain connected for issuance to continue.

Tokenization is useful when it changes where card data has to live. Replacing a PAN with another number achieves little if every application holding that number can exchange it for the original card.

The jTS integration in the jPOS Control Plane makes that distinction explicit: a token requestor can tokenize a card, but resolving the token back to card data requires a separate station permission.

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.

Reading a payment transaction is still expert work.

An authorization is not just an amount and a response code. It is the incoming ISO 8583 message, the authorization decision, the card and product state, the transaction chain around it, the ledger postings it produced, and the operational context that explains why it ended the way it did.

The new Transaction Log Inspector demo shows a practical way to make that expertise available on demand: explain a transaction in plain language, directly from the jPOS Control Plane, without turning the assistant into a side channel.

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.