Skip to main content

jPOS Transaction Log Inspector: Explain with AI

· 5 min read
Ing. Josefina Revilla
Ing. Josefina Revilla
Senior Software Engineer

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.

What the demo shows​

The video follows a live transaction-log workflow in the jPOS Control Plane:

  • sign in and work inside the ACME entity
  • open the Transaction Log Inspector
  • browse recent card traffic and drill into one transaction
  • inspect base transaction facts, authorization details, related chain activity, and review flags
  • click Explain with AI from the transaction detail page
  • read the assistant's explanation in the floating chat panel and full-page chat view
  • open the transaction access-audit trail
  • filter the audit trail to explain events and find the AI explanation request

The point is not that the model can summarize a row. The point is that the Control Plane gives the model a bounded, read-only tool for one transaction, then keeps the operator in the same UI where the evidence can be inspected.

From fields to a story​

Transaction logs are dense by design. They preserve detail. That is useful for forensic work, but it also means that a normal operator has to assemble the story manually:

  • What kind of transaction was this?
  • Was it approved, declined, reversed, advised, or captured?
  • Which card and account were involved?
  • What did the issuer decide?
  • Did anything else recently happen on the same card?
  • Did the ledger linkage make sense?

The explain tool does that first pass. It gathers the transaction facts the page already exposes and related context that matters, such as general-ledger linkage and recent activity on the same card. It then asks the assistant to explain the transaction in operational language.

That is a good use of AI: not replacing the record, but helping a human read it faster.

The model does not get the database​

The important design detail is the boundary.

The assistant is not handed a database connection. It does not get to decide which tables to query or which tenant to inspect. It receives a server-side tool result for one transaction, assembled under the current authenticated session, active entity, and permission set.

The model sees facts, not unrestricted storage.

Sensitive data is handled the same way. Anything shaped like cardholder data is masked before it reaches the model. The assistant can explain what happened without seeing a PAN or data that would widen PCI scope unnecessarily.

That keeps the architecture boring in the right places:

  • the user stays authenticated through the Control Plane session
  • entity scope comes from the backend session
  • permission checks happen before the tool runs
  • the tool is read-only
  • sensitive fields are masked before model input
  • the UI remains the place where the operator verifies the answer

AI features in payment systems fail when they become a second security model. This one is deliberately wired into the existing one.

Audit as a first-class feature​

The second half of the demo matters as much as the explanation.

After asking the assistant to explain a transaction, the video opens /tx/audit: the transaction inspector's access-audit trail. Searches, detail views, and explain requests are recorded as durable rows in the tenant database.

For each access event, the trail captures the useful compliance facts: who acted, when they acted, what kind of read they performed, and which transaction was involved.

The audit page is not just a dump. It can filter by actor, date range, transaction, and event type. Narrowing the list to explain events shows the AI request made moments earlier.

That is the right shape for regulated operations. Reading the ledger leaves a ledger.

Why this matters​

Payment systems need both speed and accountability.

During an incident, operators need to understand a transaction quickly. During an audit, the organization needs to prove who looked at what and why. Those goals can work together if the assistant is treated as an operator aid inside the application, not as a privileged observer outside it.

The Transaction Log Inspector now has that pattern:

  • durable transaction evidence
  • AI-assisted reading
  • tenant and permission scope
  • PCI-aware masking
  • read-audit records for every important access

The assistant does the reading. The operator keeps the controls.