Offline Settlements

Version 1.1
Last edited December 2022

Overview

Scope of the document

The following document outlines the Offline Settlement process, as part of the Mastercard and VISA scheme rules, the interactions between Nium and the client, and the communication and escalation procedures that should be followed in such cases.

What's new in this version?

The following information has been added to the current version of this guide.

DATEVERSIONDESCRIPTION
9th Jan 20201.0Initial version
13th Feb 20201.1An updated and revised version
13th Jul 20221.1Product and documentation rebranding
1st Dec 20221.1Product documentation web view

Offline Settlement - Explanation

According to scheme rules, there is a standard process for processing settlements. If the settlement process falls outside of the below, it is seen as an incorrect standard of processing:

  1. Merchants Acquirer sends an authorisation request to the card.

  2. The issuer accepts or declines that request based on the rules set in place, such as sufficient funds on the card, accepted merchant, etc...

  3. Response provided back to Acquirer.

  4. If the authorisation is accepted, the settlement has 7 days to be received; if settlement arrives after that time, the client has chargeback rights.

  5. If an authorisation is declined, no settlement is expected.

There are situations, however, where the parties involved do not follow the standard process and use loopholes to process settlements in their way. This case is one of them.

Airline A attempts to use the standard approved process; however, if they attempt to authorise a payment and it is declined, they choose to push the settlement anyway as "Offline" instead of not continuing with the process.

This causes several issues across the entire payment flow; since the settlement was processed (even though it was done incorrectly), the fund flow has been initiated! The implication is that now the acquirer owes the merchant, but that also means that the scheme will bill the issuer to pay the acquirer, which starts a vicious cycle of pushing around liability.

It is important to note that there is no way of stopping these types of settlements from coming through because it is simply the way the entire payments system works, acceptance or declines only apply at the authorisation level, and there is nothing available at settlement to stop this from happening. Since this is seen as "breaking the rules" from a scheme perspective, the charged client is covered by chargeback rights. Specific rules are set for settlements that arrive without authorization and are considered automatic wins. However, the scheme only allows a 90-day time frame to process these claims.

When it comes to airlines, the client must be careful about how to proceed with charging back these cases as if the client added a charge (let's say, extra baggage charge) onto an existing flight, the chargeback on the offline settlement may also have implications on the legitimate settlement.

Since the merchant is the one who is initiating this whole process, it is they who are responsible, and so it should be them to stop sending settlements in a way that is unacceptable from a payments standard. From a card integrity perspective, we have monitors to track these and uncover such instances.

  1. The client loaded the card for the amount needed to make a purchase

  2. Authorisation comes in, and all the acceptance checks are run at this time, and the authorisation amount is blocked on the card

  3. Authorisation was accepted, and a few days later, the settlement that matched that authorisation was received. Authorisation is closed at that point, the settlement is processed, the blocked amount is removed, and the card balance is updated.

  4. Since the card is Single-Spend, the system processes a card deletion on the day of the settlement and empties the card.

  5. The merchant attempted to authorize the card a second time; since the card is Single-spend, it has already been deleted, so the authorization was declined.

So far, this is all legitimate processing and shows that the system is working as it should. Diagram $1.0$ below shows the process

Diagram 1.0

Diagram 1.0

Steps 5 and 6 are done as one from a processing point of view since, for a settlement to take place, one must technically first have a matching authorization. The processor creates a fake auth (offline auth) to match with the offline settlement. Since there are no acceptance checks at the settlement level, this amount is automatically pushed onto the card forcing it into negative.

As part of our service with the system, finance offers daily monitoring of these negative cards, and we manually fix every card that ends up in this state. We also tag the cards as "negative card balances" or "Loss Recovery" to help the client to identify these extra charges to their card.

Offline Settlement - Issue Identification and Escalation

  1. The Nium team will monitor daily for any offline transactions and negative card balance;

  2. In case of offline transactions or negative card balances are identified, the Nium team will continue to monitor the situation. If the negative balance wouldn't resolved within 7 days (5 working days), Nium will advise the client to fund the account for repayment of negative balances within 20 days.

  3. Once funds are loaded in the client's funding account, funds are debited to restore the account balance to neutral, and the case is closed.

  4. If payment is not received within 28 days from Nium's first notification, Nium will send a communication to a client advising that if payment is not effected within 48 hours (Final Notification), the Chargeback process for the amounts in negative will be initiated.

  5. If the payment is not received within 48 hours of the Final Notification, Nium will initiate the chargeback process advising the client that the fund recovery procedure has been undertaken.