Sub flows

Reader Always on

This configuration is relevant for peripherals which wants to start the transaction with product selection (PreSelection flow) but don't have a way to start a transaction from the peripheral- meaning they want the transaction process to be initiated from a consumer selecting a product on Nayax's device's screen which would then trigger the peripheral to send the product's details. In rare case, a consumer's card presentation can be the trigger for the peripheral to send the product selection, but as mentioned, this option in not very common.

Always Idle

The transaction starts with the consumer selecting a product (PreSelection flow) on the peripheral which would then have the peripheral sending the "Vend request" command without waiting for a "Begin Session" trigger prior to sending it (the "Vend request"). This flow is very commonly used in the far east.

Features

Display Control

A feature for peripherals which require the option for the Marshall master to define different types of selection screens on the device before sending the request for a specific price. This way, the product selection comes from Nayax's device instead of the peripheral, and is useful in cases in which the peripheral has no screen or way for consumers to select a product on it's end.

More on that in the Display Control page.

eReceipt

A feature which would enable a digital receipt file to be generated on the device's end (as well as have the file's link be sent to the peripheral via the SDK) via a QR code once the transaction has been settled. In order to enable said feature, you should set the following configurations in Nayax Core:

• Payment tab -> Transaction Options -> Enable eReceipt on Transaction end - V • Receipt Button Display Duration - 20 • Receipt QR Display Duration - 40 • Vend Flow Options - Dynamic Receipt

On older SDK versions the URL would appear in the SDK in hex, so in order to parse it you should convert it to ASCII https://www.rapidtables.com/convert/number/hex-to-ascii.html

On newer ones it would appear something as follows:

marshall-c-sdk-demo: received ereceipt: https://ereceipt.nayax.com/qr/2470412964/0123456478901234/2

How to get the eReceipt product name to not be "unknown"?

The product names are taken from our product map, so you can create products inside of it and name them (to match the product codes you send in the SDK). Just keep in mind that Marshall does not use any of the information in the product map, meaning you can put whichever information inside of it and it won't matter to the transaction flow, including the prices (the only field which is relevant for you is the product code name and it would appear in Last Sales and eReceipt file)

You can add new products to your device's product map by going to the "product map" tab, clicking on "Map"-> "Add BIN", and then add the product code and product group, PA code and MDB code (this is the one which should match the product code in the SDK), and then of course click on "save".

Info Session

An informative non-vending session which provides the peripheral the consumer's card details upon their card presentation. The consumer is not charged (is notified by that via "card read successfully"), and the transaction ends with "Vend Denied" (as there is actual authorization, nor is there a need to proceed to a vending process).
Used mostly for consumer re-identification by having the consumer present the same card he started the transaction process with.
Usually relevant for rentals and EV chargers.

• Important note- this feature requires the peripheral to have a screen/ a way to distinguish between a vending session and info session, as it's up for the peripheral to know which type of session to initiate.

Incremental authorization

What is Incremental Authorization

Incremental authorizations can be used to increase the total amount authorized if the amount of the estimate/initial authorization is insufficient. An incremental authorization request may also be based on a revised estimate of what the cardholder may spend. Incremental authorizations do not replace the original authorization — they are additional to previously authorized amounts — the sum of all linked estimated and incremental authorizations represent the Total amount authorized for a given transaction.

❗️

Supported billing providers

As of October 2025, the only billing providers which support this feature are Heartland (US), Chase (US) , Credorax (Europe), First Data (Australia), Adyen (US only as of now, also Europe in the future). Should your devices have any other billing provider set up- Incremental Authorization won't work.

How Incremental Authorization works

The incremental feature has 2 "Default Credit" parameter- the regular one and "Maximum Default Credit". The regular default credit is the one that the consumer would initially be authorized for, just like in any PreAuthorization transaction you're familiar with (if there is not sufficient credit for the Default Credit the transaction would be cancelled on this step). Should the consumer take items worth less than the Default Credit amount- the consumer would only be charged for those items (as per usual).

An example of using Incremental Authorization:

Default Credit of 10.00$, Maximum Default Credit of 50.00$: Should the consumer take items worth more than the Default Credit amount but less than the Maximum Default Credit amount (for example- items worth 17.00$)- the device would go through a 2nd authorization process for the difference between the "final price" and Default Credit amount (7.00$):

• Should the 2nd authorization be approved- the consumer would be charged for the desired amount (17.00$). It would look something like this in Last Sales (one line record, in which the settlement amount is higher than the authorization amount):

  

• Should the 2nd authorization fail- the consumer would only be charged for the amount of the first authorization, meaning of the Default Credit (10.00$). In such case the risk is on the machine's operator, meaning the loss of the 2nd authorization being failed would be on his end.

Should the consumer have taken items worth more than the Maximum Default Credit (for example- items worth 60.00$)- it's up for the machine to send the final price to be the Maximum Default Credit, as otherwise the transaction would be cancelled. In such case, once again the risk is on the machine's operator should the 2nd authorization not be successful, as well as the machine not being able to charge the consumer for more than the Maximum Default Credit (meaning there's at least a 10.00$ loss).