FAQ- General

Proprietary cards supported

Nayax supports both swipe (Magstripe) and RFID cards.

The RFID supported are working in frequency 13.56 MHz: Nayax' reader is working in frequency 13.56 MHz and supports ISO 14443 Type A and Type B cards (e.g. MiFare Classis and MiFare Plus) + ISO 15693 (e.g. HID iClass). The most popular and simple RFID card supported by Nayax' card reader is of type: MiFare Classic 1K (or 4K).

Magstripe cards are supported as well- should they be compatible with a non credit card standard, i.e. do not contain any '=' in the card's data and UID is in range 4-40. Should they have and of those features- there is a possibility of supporting those but it may require an additional integration (Cortina Prepaid)

Vend denied- why Nayax doesn't provide a reason to the peripheral

As the device is unattended, we wouldn't like to embarrass consumers if their card is blocked etc.

How to locate which virtual COM port matches the physical connection

Go to "Device Manager" -> "Ports":

Marshall over ETH- using the same cable for both Marshall communication as well as the device's with Nayax's servers

The supported configuration is communicating via Ethernet both with the (Marshall) peripheral and with Nayax's servers.
It’s the router’s role to provide access to the external world in parallel to the peripheral.
Having the device communicate with the peripheral via Ethernet and with the servers via eSIM is currently not supported, as technically this setup is less natural for Android.

Enabling alerts

In order to be able to see the alerts sent from the SDK in the Nayax Core you should have the following configuration (even if your machine is not an EV charger)

In addition to that, you can't make up an alert ID, you should use an ID that exist in our database (and can be configurable). For example, you can use ID number 2, which is a "Door event" (you can change the event data as you desire):

• Alert ID of 200 or 810 does nothing. Best practice is to use alert ID 2.

m_vmc.general.alert((short) 2, "Back door opened");

vmc_instance.general.alert(2, "alert test");

uint8_t alert_str[32];
sprintf((char*)&alert_str,"Back door opened");
vmc_general_alert((short)2, (char*)&alert_str, strlen((char*)&alert_str));

Product map

This is a feature which allows you to manage products via Nayax Core for your peripherals. This feature is irrelevant for Marshall, as in Marshall there is no use of the Product map. The only relevancy of it is that should you look in Last Sales/ Dynamic Transaction Monitor, you'd see in the transaction details the product name which appears in the product map for the product code that the peripheral has sent.

Should managing a product map be relevant for you- Our Support team has sent me links for our Nayax U in which there are guides about that:
Setting up a Product Map: https://nayax-u.nayax.com/scenario/how-to-create-a-product-map-template-administration-2349
Setting up a product in the Procut Map:
https://nayax-u.nayax.com/scenario/how-to-create-a-product-administration-937

Example:

The peripheral has sent a "Vend Request" for product code 1 and price of 10.00, and the product map has a row regarding product code 1 which has the name of "Apple" and price of 20.00- the price that the consumer would be charged for would be 10.00, and in Last Sales/ Dynamic Transaction Monitor you'd see that the transaction is for product code 1 and alongside the product code you'd see "Apple"

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".

Static IP

There's a requirement to define static IP for the machine as when information returns it would hit a firewall, making the data not to know where to be routed

Refund request

Refund is a when a transaction was completed and settled, yet a consumer would like to get his money back due (refund) to some reason. Marshall does not have a refund feature, as it does not relate to the communication between the customer's machine and our device but rather to the payment aspect of things. You can have a transaction cancelled or a consumer not be charger is you were unable to provide the goods, though: if there was an issue with dispensing of product you should simply respond in "Vend Failure" instead of "Vend Success".

If the transaction was completed successfully (the consumer was charged) and you'd want to get a refund for it you can do it through Nayax Core: go to the Dynamic Transactions Monitor page, select the relevant transaction and press right click on it, select Request refund and confirm. Nayax's team will be approving the request and once approved you should be see the funds back account within 1-2 days.

Unit of measure values

Gtrace retrieval

Gtrace is a log which allows you to receive general information about the device's behavior unrelated to the communication with your machine it would not show up in the SDK's commands and logs, but on the Gtrace- another type of log file, but this one is one generated by Nayax's reader and is sent to Nayax Core.
Should it be relevant to you, you can retrieve a Gtrace the following way (note that in order to retrieve it your device should be on, as you can imagine):

For VPOST/Onyx:

Once you've selected your desired machine you should select "Actions"-> "Request Gtrace":

For VPOSTM

Once you've selected your desired machine you should go to the "Device Features" dropdown, and insert the relevant timeframe of the log in the "Device logs request":

In the following format:

<Session_id_uniqe>;<from_date_time>;<duration_min>;<adr>;<0>;<100>  

For example- Gtrace request from 10.03.25 at 15:00 for a duration of 120 minutes (meaning a Gtrace between 10.3.25 15:00 until 17:00) :

fallback3;1003251500;120;adr;0;100

And then click on the checkbox to the left of the parameter, then to to Actions-> Update Queue:

Once you've sent the request (whether it be from VPOST, Onyx or VPOSM), you would see that under the "Dex" tab there would appear a new line/s in the table with the Dex Source of GtraceV2:

Once you click on the desired log (on a specific line in the table) and on the "View Parsed" button- you'd be able to see the full log.

• Important note!- the device must be online in order for the Grace to be collected
• Note- sometimes it takes a few minutes/ hours for the log to appear, depending on how often our servers take to have the information replicated between themselves.

Last Alerts retrieval

Last Alerts is a log which appears in Nayax Core under your relevant device's virtual machine. Said log provides you with information of alerts sent between the device and our servers. In order to retrieve it you should go to the relevant virtual machine, and then click on Info-> Last Alerts:

Cables SKUs

C130011- Regular Marshall cable - VPOST/Onyx

C150001- Onyx cable (with ETH)

C140001- RJ11 male to RJ45 female cable (ETH adaptor for VPOST)

NX-CB0135- VPOS Media 4S

NX-CB0156- RJ11 male to RJ45 female cable (ETH adaptor for VPOS Media 4S)

NX-CB0138- VPOS Media 5

Firmware version update process

VPOST/ Onyx:

The firmware update is made out of 2 parts- the MAIN update and POS update. For the MAIN update you'd see "gloader" on the top of the screen and a percentage next to it. Once completed the device would reset itself and start downloading and updating the POS- please do not touch it until the device resets itself, as the device's screen would also seem black once the POS is erased and being updated. After completion the VPOST would power itself up and would be in idle mode. This whole process usually takes 30-60 minutes (may take longer if using ETH), so keep that in mind.

VPOSM- WIP!

Timeout for getting approval of the transaction from the acquirer

The "Authorizing, Please wait" would show until either a response is received from the acquirer, or a timeout has reached. Usually, if the VPOST is able to communicate with our servers (our servers do not have issues getting response from acquirer) the whole process of sending the authorization request and getting a response back is a few seconds long, usually up to 5 seconds, but should there be any (GSM/VPN/MQTT/ETH) communication issues between the VPOST and our servers the request would take some time to arrive to our servers, or take some time to get the response from our servers. I've asked the support about that timeout, and they told me it's configurable with the "MDB RX Timeout" parameter, and the default value is 60 seconds:

"Trick" of starting a transaction at one location and finishing it at another

For this explanation I'd use the example of cart rental:

1. Have a transaction started from Nayax's device at the 1st location (take a cart from there)
2. Have the consumer use the cart
3. Have the consumer return the cart to any rail he desired (not necessarily the 1st location. Let's say it's a 2nd location)- at this stage Nayax's device at the 2nd location would recognize the cart, will send it's ID to a main server which will make a match between the cart ID and the Nayax device in which the transaction started with- and close the transaction over there. But as you can understand, in such case there is a need for a server management on your side.

A couple of requirements:

1. A server to manage which sessions are opened at which location
2. A way to differentiate between different cards
3. Each rail can have up to 60 carts available for rent at each time (should there be more the consumer won't be able to rent those)

Dynamic QR channel URL appearing in the SDK (brand selection screen)

In order to have the brand selection screen to start with, the device must be configured to Always Idle (as regular Preselection has the animations after a product is selected and is unable to show brands). After I've selected a product, then the brand/channel and the QR appeared on the VPOST's screen- it also appeared in the SDK's log. The string appears in Hexa, so there's need to convert it to ASCII in order to get the URL. For example: https://www.rapidtables.com/convert/number/hex-to-ascii.html

CPU requirements

No special requirements for any of the SDKs. Java and C# SDKs:

The SDK is so thin in CPU and memory requirements, that if your machine can run JVM, then it can run the SDK. Our SDK developer estimates it's memory usage in around 50KB of RAM and almost zero CPU time. (it is based on a 100 code of lines which are executed every 5ms and upon serial data received, not much more than that on every packet)

C SDK: Our SDK developer estimates it's memory usage in around 1KB of RAM and every 5mv, timer tick of around 100 lines of code (actual machine code depends on compiler and platform). He ran it on Atmel AVR with 2KB of RAM, 8MHz controller, and plenty left for the actual application.