A fee schedule is a business policy, not just a percentage. The same amount may attract different charges at an ATM, at a contactless terminal, or online. A merchant category may carry a surcharge. Small transactions may need a floor, large ones a ceiling. Several independently disclosed charges may apply together.
Hard-coding each variation turns pricing changes into software releases. Making everything freely editable creates a different problem: one configuration change can affect every transaction on a product. jCard brings these concerns together—expressive pricing rules, a controlled approval lifecycle, and evidence of what was actually charged.
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.
Most jPOS-based applications are monitored using Elasticsearch, Kibana, and Grafana, or commercial alternatives such as Datadog, Splunk, and New Relic—and I never liked that.
External monitoring solutions usually rely on a Java agent that gives a remote server access to the JVM. These applications are often PCI certified because many QSAs don't fully understand what a JVM is or how powerful a javaagent can be. Otherwise, they would probably be considered uncertifiable or, at the very least, could extend the scope of your CDE to the remote provider. That's one of the reasons I wrote SensitiveStrings: to keep in-JVM sensitive data encrypted most of the time, adding a little defense-in-depth and flying under the radar of scripts looking for sensitive card data.
Elasticsearch is an awesome tool, but it's overkill to dump all your payload into it, such as verbose jPOS logs. We use it together with Debezium to store pointers to transaction data, not the transaction data itself, which would otherwise just replicate primary storage. Kibana is excellent for monitoring indexed business data, but log data is inherently unstructured. It evolves over time, and the queries evolve with it.
Grafana is also a great product, but dashboards are typically designed once, tweaked during development, and then left untouched for years. Eventually, a new DevOps team member inherits them without really knowing how they were built or how to modify them.
Those concerns led me to integrate metrics directly into jPOS using Micrometer, producing native Prometheus and OpenTelemetry metrics so we can eliminate remote Java agents altogether. I also worked on Structured Logging so logs are precise enough that you don't have to rely on regular expressions to search for information, and instrumented jPOS with Java Flight Recorder for the situations where we need to perform deep JVM forensics.
All those pieces are finally coming together in the integrated Metrics Explorer and Log Viewer. When you're investigating a problem, you can click on a graph and jump directly to the corresponding structured log messages with a single click. Instead of being limited to predefined dashboards, you have the full power of PromQL at your fingertips.
And then comes the final piece: integrated AI.
You can simply ask, "Please check if we have GC pressure over the last six hours," click the jPOS AI icon, and immediately have that free-text request translated into PromQL. No need to know the metric names, labels, or query syntax—the AI does that for you.
The goal isn't to replace Prometheus, Grafana, Elasticsearch, or Kibana. They remain fantastic tools. The goal is to make jPOS itself understand its own runtime well enough that the most common operational and forensic tasks can be performed from a single, integrated environment, without shipping logs and JVM internals to external systems by default.
Metrics are excellent at telling you that something changed. They are less good at explaining why.
That gap usually sends an operator across several tools: a dashboard for the symptom, a query editor to narrow it down, a log system for the events around it, and perhaps documentation to reconstruct the right query. The latest jPOS Control Plane demo brings those steps together without making the result opaque.
The Metrics Explorer works with the Prometheus metrics exposed by a running jPOS application. It lets an operator move from a chart to the relevant logs, ask questions in plain language, and inspect or run the generated PromQL before relying on it.
In Latest and Greatest, we recommended a simple rule: use the latest -SNAPSHOT while developing, then pin the exact timestamped build that passed QA before deploying it.
The rule is simple. The manual version was not.
Someone had to find Maven metadata, copy the timestamped version, edit gradle/libs.versions.toml, make sure every related library was considered, and later remember which value used to be a moving snapshot. That is precisely the kind of release step that should be boring and repeatable.
jPOS Gradle Plugin 0.0.19 adds three tasks for that job: pins, pin, and unpin.
Operators should not have to discover that something went wrong.
A failed job, a locked account, or an error during a release is useful only if it reaches the person who can act on it. The new jPOS Control Plane notifications demo shows that path end to end: from an operational event, through routing and delivery, to the operator’s inbox and the channels the team already watches.
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.
the TransactionManager can do two useful things. First, it can abort early if a
required input is missing. Second, when requires or optional is present, it
can call the participant with a restricted clone of the Context and later merge
back only the keys listed in provides.
That makes the TM configuration more than a list of Java classes. It becomes a
readable contract for the transaction flow: this participant needs these inputs,
may look at these optional values, and is expected to produce these outputs.
