Payments

Operators can now accept payments by Nayax Prepaid cards, with transactions processed even when connectivity is limited or unstable, for example on trains, light rails or buses going through areas with limited cellular connectivity.

Currently, the offline prepaid authorization is enabled ONLY for MIFARE cards with a pre-defined prefix, enabling local authorization until settlement is completed once full connectivity returns.

| Prerequisites

A specific valid prefix needs to be consistently applied to all prepaid cards by their manufacturer, In accordance with the following parameters:

1. MIFARE prefix needs to be under sector ‘1’
2. Alphanumeric string format (excluding “=”) for tap and insert
   (for swipe, please use numeric string format only)
3. Length – 16 characters.
4. The prefix needs to be in ASCII to HEXA format. E.g. DB1234 is 44 42 31 32 33 34
5. Each machine can have a maximum of 5 prefixes

This feature can be activated by submitting a request to Nayax Support, and will be enabled after signing an addendum to the Nayax agreement.

Version support
VPOS Touch: 4.0.24.12
Onyx: 4.0.24.12

Learn more about how to configure the Offline Payments for Prepaid Cards, on Nayax U.

Operators can now accept payments even in cases of limited or unstable connectivity (e.g. on trains and buses) and offer customers faster checkout in high-traffic environments (e.g. parking and public restrooms) – with the Offline Payments feature.

Offline Payments has two modes: “As Backup” and “Always On”.

| Offline Payments – As Backup  (formerly Deferred As Backup)

In Offline Payments as Backup mode, operators can accept payments in areas where connectivity is unstable, e.g. on trains or buses going through areas with limited cellular connectivity, thereby ensuring continuous payment acceptance.

When Offline Payments – As Backup is activated, in the event that an online authorization cannot be submitted for approval due to limited connectivity, the cardholder receives immediate approval (unless the card is expired, or its number is not compliant), but the transaction is deferred and will only be sent to the relevant server once the device reconnects.

The operator can define how long the device is to remain in Offline Payment mode in Nayax Core, either according to a maximum number of transactions or a specific amount of time (in minutes). To manage the risk of declines, these criteria can be adjusted to the level that is most suited to the payment environment.

Learn more about how to configure the Offline Payments As Backup mode, on Nayax U.

| Offline Payments – Always On (formerly Always Deferred)

Nayax enables operators to offer faster checkout and avoid long queues, by allowing up to in heavy traffic environments, such as parking exits or public restrooms. A device that is set to Offline Payments in Always On mode will send transactions for approval either after it has been in idle mode for 10 minutes, or after a given number of transactions – pre-defined by the operator in Nayax Core – whichever happens first. For example, where an operator sets the transaction count for a machine to 50 transactions, cardholders paying at the device will receive immediate approval (unless the card is expired, or its number is not compliant), but transactions will only be sent for authorization and settlement after the 50^th transaction. This way, 50 transactions can go through at once, reducing the waiting time.

The risk of declines can be managed by adjusting the maximum transaction count to the level that is most suited to the operator’s payment environment.

Learn more about how to configure the Offline Payments Always On mode, on Nayax U.

| Prerequisites

Offline Payments can be configured for single-vend MDB, Pulse and Marshall machines, in pre-selection mode. It applies to EMV Contactless/NFC Card transactions only. Extra charges or discounts may not be processed while the machine is in Offline Payment mode.

Version support:
VPOS Touch: 4.0.23.6
Onyx: 4.0.23.6 

| Activation

The feature can be activated upon request to Nayax Support. The feature will be enabled after the signing of an addendum to the Nayax agreement.

We are introducing two updates on Refunds: an extended refund period, and a change in the appearance of refunds in reports. These changes will be implemented globally by the end of August 2024.

Extended Refund Period

Nayax has extended the purchase refund period to 180 days, meaning that payments can be refunded to the cardholder account for up to 180 days from the date of the original transaction. This is notwithstanding any local regulations or billing-provider policies that may provide otherwise.

Refund Appearance in Reports

When a refund is created and approved, a second line will appear in the report with a negative transaction amount representing the actual refund. The original transaction, which has been refunded, then becomes green (see image below).

Should the Original Transaction ID column not appear automatically on the Dynamic Transaction Monitor (DTM), it can be added via the action button: click “Action” and “Edit Preset”, then click “Transaction Details”, search for “Original Transaction ID” and add it to the report.

Incremental Authorization is used when the Total Amount of an EMV transaction is higher than the initial authorization (i.e. the initial authorization is insufficient), and enables operators to use a Default Credit, lower than the highest price of a given machine. Therefore, Incremental Authorization makes payments easier for consumers and customer complaints due to high default credits.

Payment Flow

1. Prior to selecting the product, the consumer taps/ inserts the card and initiates authorization, based on the defined Default Credit.
2. Once products are selected, the total price is calculated.
3. If the total price of the selected products is higher than the Default Credit, an Incremental Authorization Request is automatically placed for the difference. In case the Incremental Amount is rejected for any reason, the cardholder is charged with the Initial Authorization amount.
4. After authorization of the initial authorization and the Incremental Authorization, the transaction is sent for settlement. Once the transaction is settled, the settlement amount will appear on the device screen.

Incremental Authorization is available for VPOS Touch and Onyx on MDB & Marshall Machines in pre-authorization mode and applies to EMV Credit Card transactions only. It is supported by Heartland, Chase[1], and Credorax[2]..

The feature can be activated upon request to Nayax Support and will be enabled after signing an addendum to the Nayax agreement.

Version support:

VPOS Touch: 4.8.0.22
Onyx: 4.8.0.22

 Configuration

1. Prerequisites

1. A legally binding agreement covering Incremental Authorization must be signed with Nayax before activation.
2. Relevant permissions must be granted by the Nayax support team, and configurations must be added at the operator level.
3. The primary billing provider must be set to Credorax in Europe, and either Heartland or Chase in the USA.

For detailed guidance, please visit Nayax U

[1] Visa, Mastercard in USA

[2]  Visa, Mastercard in UK, Spain, Italy, France, Netherlands, Germany, Austria, Switzerland, Sweden, Finland, Norway, Belgium, Czech Republic, Denmark, Canada, Poland, Bulgaria, Croatia, Cyprus, Estonia, Greece, Hungary, Ireland, Latvia, Liechtenstein, Luxembourg, Malta, Martinique, Monaco, Portugal, Romania, Slovakia, Slovenia, Aland Islands, Lithuania

We are constantly improving our Cortina API documentation to simplify integration processes with our partners. We recently updated the Developer Zone to make integration processes more accessible to acquirers and payment brands.

| Decline Reason Codes

Decline Reason Codes vary according to integration type. Permitted Decline Reason Codes are now described separately for each integration type in the information section, showing only the codes relevant to that specific integration type.

| Enabling Discounts for Cortina External Prepaid

The Discount feature enables integrators to change the settlement value of an External Prepaid transaction by sending a new settlement value in the sale/settlement response (after authorization of a higher amount). Descriptions and instructions for use of the new Discount features can be found in the Cortina API documentation.

| Cortina Static QR documentation

We have updated the Notify Request command name (formerly “Notify”, now “Start”) to improve consistency across the documentation. This also includes further clarification of the TerminalId and UniQR fields. This change does not affect any existing implementations.

Any feedback? Please use the new feedback form in the Developer Zone.

We are pleased to inform that we have enhanced the ability to view transaction status information regarding prepaid transactions on Nayax Core and MoMa.

As of the end of May 2024, operators will have direct visibility into declined prepaid transactions via all transaction reports, Last Sales and DTM. This includes prepaid transactions done via Nayax Prepaid Cards, key fobs, NFC stickers, QR Codes, and Monyx Prepaid.

The decline reason “Declined during Authorization” may appear for the following reasons:

• Card Exceeded Daily, Weekly, or Monthly Limits
• Card Exceeded Group Limit
• Card Exceeded Machine Location Limit
• Card has Insufficient Credit
• Prepaid Card Authorization Failed
• Card Blocked

The Decline reasons can be seen in the Last Alerts report by searching for the transaction ID.

Note: Prepaid transactions that are not completed as a result of not reaching Nayax Servers (e.g. due to connectivity), and transactions of cards, that have never processed any successful transaction, will not be displayed in reports.

| Introduction

When machines are configured with a high default credit, it can cause authorization amounts that are much higher than the actual price paid by the consumer. Depending on their policy, acquiring or issuing banks may hold authorization amounts for several days, which can result in customer complaints.

Effective June 2024, Nayax has introduced a new feature called partial reversal, to return eventual hold balances to consumers faster. Partial reversal is used in pre-authorization configurations. When this payment flow is used, a default credit is defined as either the highest price in a given machine, or any other amount defined by the operator. The new feature enables a faster return of the delta between the final amount actually payable and the authorization amount, held by the acquiring or issuing bank.

Partial reversal applies to credit and debit card transactions made on EV chargers, vending machines, smart fridges, dispensers, and equipment or storage rentals. At this stage, it is supported by Shift4 (Credorax). It is available for VPOS Touch and Onyx in pre-authorization mode, regardless of which version or machine protocol (i.e. MDB, Pulse, Marshall).

| Payment Flow

1. Prior to selecting the product, the consumer taps/ inserts their card and initiates authorization, based on the defined default credit.
2. Once the product/s is/are selected, the final amount payable is calculated.
3. If the final amount of the selected products is higher than the default credit, a partial reversal request is automatically placed for the difference, while the settlement is being processed.