Payment Operations
Payment operations describe the actions a merchant can perform during and after a transaction. These are standard across payment environments and are consistently supported across our terminal devices.
Understanding these operations is essential for day-to-day usage, reconciliation, and managing exceptional cases such as refunds or disputes.
Overview
A payment transaction consists of two main phases:
- Authorization: The real-time approval or decline of a transaction by the issuing bank
- Settlement: The financial closing and funding step that follows authorization, usually performed in batch processes
In some implementations, an intermediate step is required where transactions are submitted or transmitted from the terminal to the acquirer before they are included in Settlement.
From a merchant perspective, most interactions happen around initiating payments, correcting mistakes, or managing completed transactions.
Sale (Payment)
A sale is the standard operation used to charge a customer.
The merchant either enters the amount manually or receives it from a connected POS system. The customer then completes the payment using a card or wallet.
Once authorized:
- The transaction is approved or declined in real time
- The amount is reserved on the customer’s account
- The transaction is stored for settlement
This is the primary operation used in daily business.
Reversal
A reversal cancels a transaction shortly after it has been processed, typically before settlement.
This operation is used when:
- A wrong amount was entered
- A transaction needs to be canceled immediately after purchase
A reversal prevents the transaction from being settled and avoids the need for a refund. Reversals are usually only possible within a limited time window and require reference to the original transaction. Currently, only the most recent (last) transaction can be reversed.
Refund (Credit)
A refund is used to return funds to a customer after a transaction has already been completed.
Typical use cases include:
- Returned goods
- Canceled services
- Corrections after settlement
Key characteristics:
- The refund is processed as a new transaction
- The amount is credited back through the selected payment method and is not limited to the card used for the original transaction
- Settlement follows the standard settlement cycle
Refunds are initiated by the merchant. On Integrated terminals, refund availability also depends on the connected ECR or POS integration.
Chargebacks
A chargeback is initiated by the customer through their issuing bank and not by the merchant.
This occurs when a customer disputes a transaction, for example:
- The transaction is not recognized
- Goods or services were not delivered
- Fraud is suspected
In this process:
- The issuing bank raises a dispute
- Nexi informs the merchant
- The merchant may need to provide supporting evidence
Chargebacks are governed by scheme rules and can result in the transaction amount being debited from the merchant if the dispute is not successfully resolved.
Reservation
A reservation blocks an amount on the cardholder's card for a limited period without completing the final charge immediately. This is commonly used in hospitality, where the final amount may only be known later.
At Nexi, the standard reservation validity is 30 days. A shorter period may apply in specific cases. When the validity period expires, the reservation is cancelled automatically. The issuer has the final say on how long the reserved amount remains blocked on the cardholder's card.
Reservation-based payments must be activated on the acquiring side and enabled in the terminal configuration. They can also be used through OPI integrations. For technical request flows, see Typical Flows.
If no charge is needed, the reservation can be cancelled so that the blocked funds are released.
Adjusting the Reservation Amount
An existing reservation can be increased with an adjustment. The additional amount is added to the current reserved amount. A reservation can be adjusted more than once.
Normal adjustments are used for top-ups. They do not reduce the reserved amount and do not complete the final charge.
Finalizing with a Sale Reservation
To complete the transaction, perform a sale reservation. The final amount may be lower than or equal to the currently reserved amount. It cannot be higher as part of this final step; increase the reservation first if a higher final amount is needed.
The cardholder and card are required again for the final sale reservation.
If DCC applies, it is shown again during the final sale reservation. DCC is not shown again during a normal reservation adjustment.
Submission & Settlement
After transactions are authorized, they must be submitted for Settlement.
Depending on the terminal configuration:
- Submission may happen automatically
- Or be triggered manually by the merchant
During submission:
- Stored transactions are sent to the acquiring system
- Transactions are finalized for Settlement
- Funds are prepared for payout to the merchant
Once submitted, transactions can no longer be modified.
Offline Payments
Offline payments cover situations where a card transaction can continue without normal online authorisation. In the terminal environment, two concepts are important:
- Standard EMV offline: The terminal may approve a transaction offline only when EMV rules, the card, terminal configuration, and acquirer-configured offline limits allow it.
- Forced Acceptance / Own Risk: The merchant may accept a transaction without normal online authorisation, but takes responsibility if the transaction later fails during submission or settlement.
Offline payment capabilities require explicit setup and depend on terminal, acquirer, merchant agreement, and configuration. For the full overview, see Offline Payments.
Error Handling and Support
We all hate it, when payment don't behave as they should.
Issues? Too many refunds? Weird glitches?
For any issues related to transactions, refunds, or terminal behavior, please contact Nexi support. Our teams can help analyze transactions, resolve errors, and guide you through the correct handling procedures.
Errors during payment operations can occur for several reasons, including:
- Card declines (>99% of the errors)
- Network connectivity issues
- Configuration problems
- Hardware limitations
Terminals typically provide clear error messages and allow the merchant to retry or select an alternative payment method.