> ## Documentation Index > Fetch the complete documentation index at: https://devzone.nayax.com/llms.txt > Use this file to discover all available pages before exploring further. # 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: | Scenario tag | Meaning | | - | - | | `Regular transaction` | A normal transaction, no special scenario detected | | `Multivend` | The tool found a Vend Multi-Request, a multi-product transaction | | `Multisession-capable build` | The build supports multiple parallel sessions (a build capability, not necessarily exercised in this log) | | `Info session (card read only, no vend)` | An information-only session, card details are read but nothing is vended. A "vend denied" outcome here is normal | | `Card rejected — retry requested (unsupported/expired card)` | The card itself was rejected by the reader (status 78/84), usually an unsupported or unreadable card, not an SDK bug | | `Explicit vend failure (no dispense)` | The acquirer approved payment, but the product wasn't dispensed (Vend Failure) | | `Vend denied` | The acquirer or issuer declined the transaction | | `Cancelled / aborted vend` | The user cancelled the transaction (X button or Cancel) | | `Cancelled before card presented` | The user never presented a card before the session closed | | `Session timeout` | The session closed because a timeout expired | | `Settlement failed` | Settlement failed explicitly | | `Communication lost (e.g. SIM removed / no signal)` | No cellular or network connectivity, settlement is stuck | | `eReceipt` | The tool detected a QR or e-receipt in the log | | `Not a recognized Marshall log` | The file or sheet doesn't contain a Marshall log at all, for example source code or a metadata sheet | ## 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: | Category | Checkpoint | What it checks | What each verdict means | | - | - | - | - | | Initialization | SDK boot handshake | Whether the initial pairing sequence (reset, config, transfer\_data, online) completed in full. | **Pass**: all 4 events found, boot completed normally.
**N/A**: this log doesn't include a boot section (a partial capture, which is normal).
**Warning**: only 1-3 of 4 found, the capture may start partway through boot. | | Initialization | Reader reaches idle | Whether the device reached Reader Enable and status 20 (available). | **Pass**: both found.
**Warning / fail**: the device never reported itself available, usually a communication, wiring, or power issue. | | Transaction | Vend/info request issued | Whether a Vend or Info Session request was sent at all. | **Pass**: a request was found.
**N/A**: no vend request in this log (may be a boot-only log, which is fine). | | Transaction | Card read & authorization | Whether card data (`card_type`/`prop_card_uid`) and an MDB (Multi-Drop Bus) approval (code 3 or 5) were both read. | **Pass**: both found.
**Warning**: only partial data, or the card was rejected by the reader itself (status 78/84, normal, not always a bug). | | Transaction | Vend outcome resolved | What the vend outcome was: approved, denied, cancelled, or failed to dispense. | **Pass**: full Vend Success.
**Warning**: denied, cancelled, or Vend Failure (often expected, depending on the scenario).
**Fail**: no outcome was ever received, the flow may have hung. | | Session | Session closed cleanly | Whether end session was received and the device returned to ready/idle. | **Pass**: both found.
**Warning / fail**: the session wasn't fully closed, may still be stuck open. | | Session | Settlement result | Whether settlement completed successfully. | **Pass**: settlement done / success.
**Fail**: an explicit settlement error.
**Warning**: stuck pending, for example due to no cellular connectivity. | | Health | Communication / firmware errors | Count of Mac Send-retry, GUI Task Fail, session timeout, or CPU starvation events. | **Pass**: 0 events, or a low count also seen in known-good logs.
**Warning**: higher than usual, an explicit timeout, or explicit starvation. Refer to the stability guide. | | Health | Response timing | Whether there are time gaps (`+Xms`) above the configured threshold (default 15,000ms). | **Pass**: no unusual gaps.
**Warning / fail**: gaps found. Sometimes this is an intentional wait (24-hour idle test, session timeout, stress test) rather than a real issue, see the next section. | 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. "Clear all" has no undo. Download a report first if you want to keep a copy of the current results. ## 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 The tool itself, with a short intro and the results legend. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.