_Europe · 2026-09-23_
A dialog can now show a text and offer Print / Do not print instead of printing straight away, above all for the answer of the payment terminal. It is triggered like SIMPLEPRINTOUT — event PRINTOUTDIALOG or command SHOWPRINTDIALOG — so it works over SSE and RabbitMQ alike. The text is drawn as paper, white and centred at the width the printer really has, and each line can carry a control prefix for size and alignment. After 30 seconds without an answer the dialog closes without printing, so a remotely triggered dialog cannot block the machine; an empty printer is reported in the dialog itself and the machine returns to the screen it came from.
Until now the card receipt was always printed. With the new rvm init switch enablePaymentTerminalReceiptDialog the machine offers it in the print dialog instead, and only prints when the customer asks for it. Where the switch is off, or the printer has no paper, the previous behaviour applies unchanged. The receipt is archived along the route the customer's answer takes, so a receipt that was declined is not printed again later by the catch-up.
Fourteen reject workflows share seven returnCode values, so a reject caused by a dead camera looked the same as a hand in the intake. The returnCode 0–9 stays exactly as documented, and the attempt now carries an additional text field rejectReason with one of 24 names that says which reason it actually was. The field becomes visible once the backend takes it; until then it is dropped in the same silent way as other unknown fields.
In a fault case the backend saw a single error event, which for a bag change (bin full and door open) was at best one of two reasons. The status call now carries displayedFaults — exactly the list the machine shows on its screen, live fault first, then every active blocking reason — and an empty list when the machine shows nothing. The on-screen behaviour is unchanged; the backend side of the field is still to come.
The entrance LED ring was blue during processing on every machine. The new rvm init setting processingRingColor decides per machine: BLUE as before, YELLOW for ring and screen, or RED, which turns only the ring red and keeps the screen yellow — a red screen would read as a fault to the customer. Green for accepted and red for a fault are untouched. The hint bar and the processing spinner take the same gold, so the screen does not mix two yellows.