Offline Payments

Offline payments are a sensitive payment topic. They can be important for merchants who want to assume responsibility for failed payments while aiming for 100% payment uptime during connectivity or authorisation outages, but they also require the merchant to understand and accept the risk.

Forced Acceptance in particular is a general EP2 Own Risk feature. It can help a merchant keep accepting payments when online authorisation is not available, but the merchant may remain responsible if the transaction cannot be completed successfully later.

Offline transactions may also take slightly longer than normal online transactions. Depending on the terminal and setup, the terminal may need to apply offline rules, store the transaction locally, record additional transaction evidence, and later submit or transmit the transaction once connectivity is available again.

In the Nexi Switzerland terminal environment, the two relevant concepts are:

• EMV offline
• Forced Acceptance / Own Risk

They are related operationally, but they are not the same.

EMV Offline

EMV offline transactions are rule-based. A terminal may approve a transaction without online authorisation only when the card, EMV rules, terminal configuration, and acquiring setup allow it.

This is not something an integrator enables with an API flag. EMV offline limits and rules are configured on the acquiring side, per merchant setup and EP2 MID. Nexi and other acquirers manage this through the relevant acquiring configuration.

By default, offline limits are usually set to zero. This means that standard EMV offline approval is disabled unless it has been explicitly configured for the merchant.

Even when a transaction is processed offline, EMV still applies built-in risk controls. These can include:

• offline data authentication
• cardholder verification
• processing restrictions
• terminal risk management
• floor limits
• transaction counters
• random online selection
• card application expiry checks
• card usage restrictions

The terminal, card, EMV kernel, issuer parameters, and acquiring configuration decide whether standard EMV offline approval is allowed. The POS or ECR should simply handle the transaction result correctly and make the merchant-facing state clear.

Forced Acceptance / Own Risk

Forced Acceptance is different from standard EMV offline processing.

With Forced Acceptance, a transaction may be accepted even when normal online authorisation is not possible and the usual EMV decision logic cannot be fully applied.

Forced Acceptance involves merchant risk.

Transactions performed using Forced Acceptance are accepted at the merchant's own risk and may fail once they are submitted or transmitted later.

Typical reasons for later failure include:

• insufficient funds
• blocked cards
• stolen cards
• expired cards
• issuer declines
• fraud-related declines

Forced Acceptance therefore requires explicit activation and a specific Own Risk agreement. It should only be enabled for merchants who understand the operational and financial implications.

The underlying terminal and infrastructure layer handles the approved fallback behaviour for the merchant setup. Merchants and integrators do not need to model vendor-specific fallback mechanisms separately.

Forced Acceptance should only be used while normal online authorisation cannot be reached. Once online authorisation is available again, the merchant or their integrator must stop using Forced Acceptance and return to normal online processing. Forced Acceptance applies to payments only. It is not available for refunds.

The merchant or integrator is responsible to enable and disable Forced Acceptance!

The merchant or integrator is responsible for controlling how long Forced Acceptance remains enabled. You can limit the number of Forced Acceptance transactions and then retry an online transaction, or use the preferred approach is to switch back automatically when the terminal indicates that online authorisation is available again.

If an outage is related to acquiring or payment systems operated by Nexi, Nexi will inform affected merchants. If payments cannot be performed because of merchant-side internet connectivity, local network, or other merchant infrastructure issues, the merchant is responsible for identifying and resolving those causes.

Connectivity Recovery

Once connectivity is restored, stored transactions must be submitted or transmitted to the relevant host or acquiring system.

Depending on the terminal, vendor, and setup, this may be referred to as:

• submission
• transmission
• submit
• transmit

During this recovery phase, the terminal may block new normal online transactions until the pending offline or Forced Acceptance transactions have been submitted successfully.

In practice, this means:

1. Connectivity is restored.
2. The terminal submits or transmits stored transactions.
3. The terminal waits for the process to complete.
4. Normal online payment acceptance becomes available again.

This behaviour helps avoid inconsistent transaction states and ensures that stored transactions are cleared before the terminal continues with normal online processing.

Availability

Offline payment capabilities are not enabled automatically.

Availability depends on:

• terminal model
• terminal vendor
• EP2 configuration
• acquirer setup
• merchant agreement
• risk approval
• integration model

Forced Acceptance is a restricted capability and requires explicit activation. For setup questions, merchants and integrators should contact Nexi before assuming that offline processing or Forced Acceptance is available.