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 transfer of funds to the merchant, 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.
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 to the original payment method
- Settlement follows the standard settlement cycle
Refunds are initiated by the merchant and may or may not require the original card, depending on configuration.
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.
Pre-Authorization and Capture
Pre-authorization allows a merchant to reserve an amount on a customer’s card and capture it later. This flow is typically used in industries such as hospitality or mobility.
In the current Nexi Switzerland setup:
- Pre-authorization and capture are generally not supported as a standard flow
- Transactions are processed as immediate sales
Any specific requirements for reservation-based flows need to be evaluated separately.
Submission and 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.
Forced Acceptance
Forced acceptance allows a transaction to be completed even when no online authorization is possible. This may occur in situations such as temporary network or authorization outages.
Important considerations:
- The transaction is not verified by the issuing bank
- The merchant assumes the full risk of non-payment
- The feature is typically restricted or disabled by default
Forced acceptance should only be used in controlled scenarios.
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.