Nayax and Vending Machines: Getting Sales Data Out for Analysis

Nayax sales data does not come out of the management API. Nayax Core configures a separate transaction reporting channel: Amazon SQS in real time, or a scheduled file over SFTP or email. The management API, Lynx, covers machines, devices, inventory and cards - not the transaction rows themselves.

Three different doors into the same system

Nayax publishes several interface families on its developer portal, and each answers a different question. The common mistake is trying to extract sales data through the wrong door:

• Lynx is described as the Management API: managing machines, devices, inventory and cards from your own environment. The documented base URLs are https://qa-lynx.nayax.com/operational for QA and https://lynx.nayax.com/operational for production. This is the operations interface, not the reporting one.
• Transaction reporting is an entirely separate channel, configured in the management interface rather than in code: SQS, SFTP or email.
• Cortina is the payment side on the device itself - credit card, QR, prepaid card - with documented flows for sale, cancel, refund and decline reasons.

Anyone starting from Lynx because it is the thing labelled API will burn days before discovering the transactions simply are not there.

How do you actually extract transaction rows from Nayax?

Through configuration in the interface, not through a call. The documented path is Administration, then Operator, select the operator, then the Transactions Report tab. That is where you choose the delivery method and what is sent.

The fields sent over SQS are selectable, in the same way you pick columns for a scheduled report. For the scheduled report you also choose the file type, the delimiter - tab, semicolon, comma, space, pipe or a custom one - and whether to include a header row. Delivery frequency is either hourly, choosing the minute, or daily, choosing the time of day.

Two user roles are documented as prerequisites for configuring any of it at all: Transaction Dispatcher and Transactions Report Subscriber. If you can see the tab but cannot save, that is the first thing to check.

Real time or a scheduled file - which do you actually need?

The answer follows from the question you are answering, not from how impressive the architecture sounds.

• If the question is "how much did we sell this month by machine and by product", a daily file is entirely sufficient and far easier to maintain.
• If the question is "has a machine stopped selling in the last two hours", you need a real-time stream and alerting logic on top of it.
• If the question is "did the payment failure this customer reported also hit other customers", you need declined transactions too, and that is a separate selection.
• If you are building both alerts and reports, take both: SQS for what is urgent, a daily file for the historical truth.

The rule that saves the most work: the scheduled file is the source of truth and the real-time stream is an alerting mechanism. The reverse produces reports that change every time you look at them.

What a vending dataset has to contain

Before anyone opens a chart, make sure these fields exist on every row. Without them no business question can be answered:

• A machine identifier and the identifier of the device fitted to it, because devices get swapped while the machine stays.
• The selection or product identifier as it is configured in the machine, not as marketing names it.
• The transaction time with an explicit timezone. This is the mistake that ruins day-over-day comparisons.
• The amount, the currency and the payment method.
• The transaction status, including whether it is a refund, a cancellation, a free vend or a declined attempt.
• A unique transaction identifier, used to prevent duplicates when a batch is ingested twice.

Nayax lets you explicitly select the special types in the report: Free Transactions, Cancelled Transactions, Refund Transactions and Declined Transactions. That is not a technical question but a business definition: a report that includes declines without flagging them inflates sales, and one that omits them entirely hides a recurring payment fault.

What you can answer once the data is yours

• Which machines produce most of the revenue, and which barely cover the cost of their location.
• Which selections sell at each site and which are occupying a tray.
• What the real buying hours are, per machine rather than as a national average.
• The share of declined attempts per machine, and whether it spikes on one device.
• How long passes between a refill and a sale, once you join against replenishment records.
• Whether a price change moved volume or only revenue.

What goes wrong on ingestion, and how you find out

• Duplicates. A message queue guarantees delivery, not single delivery. Ingestion that is not idempotent will count sales twice.
• Timezone. An hourly report on one clock and analysis on another produce a "day" that is not a day.
• A swapped device. Attributing history by device identifier instead of machine identifier breaks the time series precisely on the day something happened.
• A file that never arrived. Silence is not success. You need an alert on a missing file, not only on a malformed one.
• A column change. Someone picks columns in the interface and forgets the schema, so a valid file is ingested incorrectly.
• Mixing payment reports with machine audit reports. These are two different sources counting different things.

This is a technical description of the reporting channels as documented on the Nayax developer portal in September 2026. Screen and field names change between versions, and should be verified against your own interface.

Related: what a data pipeline is, automating business reports, reconciling card transactions.

Sources

• Nayax Developer Portal - Set Up Transaction Delivery
• Nayax Developer Portal - Lynx API Overview