Checkpoints & Scenario Tags

This page is the full checkpoint and scenario-tag reference for the Log Trace Comparator tool. Read it if the short legend on the tool page isn’t enough, or if you’re not sure whether a result is a real issue.

​

Anatomy of a result card

Each log or sheet gets its own card:

• File / sheet name: formatted as filename.xlsx → SheetName, so it’s clear which result came from which file or sheet when several are uploaded together.
• Verdict badge: ALL CHECKS PASSED, REVIEW RECOMMENDED, or FAILED CHECKS FOUND. See the legend on the main tool page.
• Scenario tags: automatic detection of the transaction type or scenario, such as Vend denied or Multivend. Full list below.
• Trace strip: one dot per checkpoint, in the same order the checkpoints are listed below. The color legend is on the tool page.
• Suggested fix box: appears when a checkpoint gets a warning or a failure, with a concrete recommendation and a “Learn more” link to the relevant documentation page.
• Evidence line: the exact log line the checkpoint was based on, so you don’t have to search for it manually.

​

Scenario tags

The tool tags each result with the scenario it detected, based on patterns in the log:

​

The 9 checkpoints

Every result runs through the same 9 checkpoints, grouped into four categories that match the trace-strip order on the tool page. Each row shows what a checkpoint checks and what each verdict means: Before those nine run, the tool checks that the input looks like a Marshall log at all. If it finds none of the expected markers, it stops there and reports a single File format check result instead, tagged “Not a recognized Marshall log”. That badge means the file was not recognized as a log, not that the log has a problem. Check that you uploaded the right file or sheet, and that it isn’t a cover page or a notes sheet.

​

Is it a real issue or a false positive?

The tool is a fast first-pass filter. It doesn’t replace professional judgment. Before you report an issue to your Nayax integrator, check this list:

• Does the sheet or test name suggest intentional behavior, such as timeout, idle, stress, or cancel? A warning or failure on timing or on the vend outcome may be exactly what that test is meant to demonstrate.
• Is this an info session? “Vend denied” is correct there, not a bug. The tool already recognizes this and marks it as passed, but it’s worth double-checking.
• Is the only failing checkpoint response timing, with everything else passing? That’s very likely a wait, not a real issue.
• Is there a suggested fix box? Read it and follow the “Learn more” link. It explains whether the behavior is normal for the protocol, or whether it needs a fix in your implementation.
• Was the sheet even recognized as a log? If you got “Not a recognized Marshall log,” check that you uploaded the right sheet and that it isn’t a metadata or notes sheet.

Whenever in doubt, open the evidence line and read the exact log line in its full context in the original log. Here is what that looks like in practice. A certification file for a multisession, always-idle flow might include a test called “24 hours in idle mode” that fails only on response timing, with 4 gaps above the threshold. That is not a bug: it is the point of the test. The right move is to ignore that failure, or to raise the timing threshold before running the comparison, rather than reporting it as an issue.

​

Exporting a report, or starting over

Once you’ve reviewed the results, two actions are available in the footer:

• Download report (.txt): downloads a full text summary of all results, including detail and recommendations. Useful for attaching to a support ticket, or for sending to your Nayax integrator.
• Clear all: clears all files and results to start a fresh check.

​

Known limitations

Keep these in mind before treating a result as final:

• The tool only detects the first request of each kind, for example the first Vend request. In a log with dozens of back-to-back transactions, such as a stress test, the detail refers to the first transaction only, not each one.
• The response timing checkpoint can’t distinguish an intentional wait from a real problem; human judgment is required, see the section above.
• All the logic is based on text patterns derived from real examples. If the SDK changes existing message wording, a checkpoint might miss it.
• The tool never sends data anywhere. All analysis happens locally in the browser. Only the “Learn more” links open a connection to the internet, and only if you click them.

​

See also