Settlement

This guide explains how authorizations are settled or completed after being authorized, including authorization backout. This guide assumes that you are familiar with the concepts in these guides:

• About Transactions — General explanation of how transactions are represented in the Galileo system
• About Card Transactions — High-level explanation of how card transactions work
• Authorization — Detailed explanation of authorization and its variants

📘

Note

To see detailed examples of transaction sequences as they appear in the Program API, Events API, Auth API, and RDFs, consult the Card Transaction Scenarios. Also consult Finding Transaction Data to see where transaction types are visible.

From the networks Galileo receives batch files that contain clearing messages from the merchants. Mastercard Banknet sends a batch file every two hours, and the interbank and ATM networks send their files once every morning.

Galileo processes these files by doing these two things:

• Matching a clearing message to a pending authorization in its system
  • Galileo backs out the hold
  • Changes the pending authorization to a settled transaction
  • Posts the amount to the cardholder account
  • Sends the Settlement Events SETL: setl message for that transaction
• Not matching a clearing message to a pending authorization
  • Galileo generates an authorization entry in the ledger and immediately backs it out
  • Posts the amount to the cardholder account
  • Sends the SETL: setl event message

🚧

Important

Galileo is obligated to post every transaction in a settlement file for every PAN that exists in the system, regardless of card or account status, and regardless of account balance.

The time elapsed between an authorization and its corresponding settlement can range from several hours to several days, depending on how frequently a merchant reconciles with its acquirer and how often an acquirer settles with the networks.

See the Settlement file table in the Transaction Types enumeration for settlement-related transaction codes.

Driving an account negative

Because Galileo is obligated to post all of the transactions that it receives in the settlement batch file, a cardholder account may be driven negative by settlements that don't have a matching authorization. Such settlements fall into these categories:

• Unmatched settlement — Reasons for an unmatched settlement might be:
  • The merchant did not request authorization prior to completing the transaction. Merchants that have a high volume of purchases for small amounts, such as fast-food restaurants, sometimes do not take the time to obtain authorizations. In these cases, merchants forfeit their chargeback rights if there is a dispute.
  • The authorization expired in the system before it received a clearing message. See Authorization expiry in the Authorization guide for more information, or Settlement of an expired authorization in Card Transaction Examples.
• Force posting — The merchant generates a message that indicates that the amount is to be force posted to the cardholder account, often in the case of a recurring transaction.
• Advice messages — These messages may come from the merchant or the card network, through the authorization stream, and Galileo is not permitted to refuse the transaction, regardless of available balance, account status, or other factors that would cause a decline.
• Settlement overcharge — The merchant authorized the card for a small amount, just to check that the card is active, and then the settlement amount is much higher than the authorization amount. At restaurants and similar establishments the merchant may have authorized the purchase amount before the tip was added. See Upcharges in the Authorization guide for one way to mitigate this risk.

The issuer or cardholder may later dispute any posted transaction. See Disputes in the Crediting Cardholder Accounts guide for more information.

Backout

When Galileo receives a clearing message for an existing authorization, or a completion for a preauthorization, the Galileo system automatically backs out the original authorization hold before it posts the settlement or completion. Backouts are initiated by Galileo, not by the networks, and they are triggered by the arrival of the completion (through the authorization stream) or the settlement (in the settlement batch file).

By backing out the hold before posting the settlement or completion, Galileo corrects for situations when the settlement amount is different from the authorization or preauthorization amount, such as when a tip is added at a restaurant, a gas pump authorizes a larger amount than the final sale, or a foreign transaction settles for a different amount than the authorization because of changes in currency conversion rates.

The backout appears as a separate transaction in the Galileo ledger, and it has the same timestamp as the corresponding settlement or completion. It also has the same source ID as the authorization that it backs out, and it has the opposite sign as the authorization. A backout is written to the ledger immediately before the settlement/completion, which results in a temporary increase in the available balance; however, the ledger is locked during the time that the backout and settlement/completion are posted, so the backed-out amount cannot be spent, and the cardholder cannot detect the backout.

Galileo does not send event webhooks for backouts, but they are visible in the CST and in the response to Get All Transaction History. If you are the system of record for your program, you must devise a way to perform your own backouts when settlement or completion messages arrive.

The table below shows backout activity type codes. The corresponding otype code will match the settlement otype for authorizations but is repeated for preauthorization backouts. For example, if the settlement for a Visa authorization is VSA, then the backout code is BVA. If a Maestro preauthorization is being backed out the code is PBPB.

Your program may have customized backout codes; consult the otypes document that Galileo gave you.

For examples of backouts see any example in Card Transactions Examples or the Card Transaction Scenarios.

Completion

After obtaining a preauthorization a merchant has the option of sending a completion before the settlement.

When a merchant sends a completion, the message arrives at Galileo as an advice-type message in the authorization stream. Issuers are not permitted to reject an advice, so the response code will always be 00. Galileo backs out the preauthorization amount immediately upon receiving a completion, so the completion amount is now on hold instead of the preauthorization amount. Later, the network sends the clearing for the completion in the bulk settlement file, and Galileo performs a conventional backout and settlement. This method produces five entries in the Galileo ledger: preauthorization, preauthorization backout, completion, backout, and settlement.

The most common transaction that uses completion is a gas-pump transaction. The pump first obtains preauthorization for a high amount*, such as $75, because it does not have the final sale amount before the gas is dispensed. When the gas has finished pumping, the pump sends the final sale amount in a completion, which arrives at Galileo in the authorization stream. Galileo backs out the preauthorization hold and replaces it with the completion hold. When the bulk settlement file arrives, Galileo matches the settlement with the completion, backs out that hold, and posts the amount to the cardholder account.

For examples of preauthorization with completion, see:

• Five-step sequence in Card Transaction Examples
• Scenario 2: Preauthorization with Completion
• Scenario 23: Account Funding Transaction

^{* In many cases, the pump preauthorizes a small amount such as 1.00 to verify that the card is active, and so the completion amount is much higher than the preauthorization. To prevent driving the account negative, you can add an upcharge.}

Incremental clearing

In most cases, a merchant clears an authorization with a single clearing message. In other cases, however, the merchant obtains preauthorization for a group of items that are later shipped separately, and the merchant sends a separate clearing message for each portion of the order as it ships. For example, an online merchant that offers items from multiple third-party vendors might obtain authorization for the total amount of the items first, and then as each vendor ships its items, the merchant clears that part of the order.

📘

Note

Instead of obtaining preauthorization for the full sale amount and clearing it incrementally, an online merchant might perform an AVS-only check first, and then obtain separate authorizations for each portion of the order as it ships. Each authorization would be cleared separately, as a separate transaction, and there would be no identifier to link the parts of the transaction together.

Normally, when a clearing message arrives at Galileo that is less than the authorization amount, Galileo backs out the full authorization amount and posts the settlement amount, and any remaining funds are returned to the cardholder account when the authorization expires. For example, if a merchant obtains preauthorization for 50.00 and then sends a 45.00 clearing, the 50.00 hold is backed out and only 45.00 is debited from the account, effectively returning the remaining 5.00 to the cardholder account.

However, when a merchant sends a clearing for only part of the amount and intends to send more clearings for the same preauthorization, Galileo must keep the original preauthorization in a “pending” state until all clearings have arrived instead of returning the remainder to the cardholder account.

To keep the original preauthorization in a pending state after receiving a partial clearing, Galileo creates a new entry in its ledger for the remaining preauthorization amount, and when the next clearing arrives it is matched to the new entry. This new record is called a “bookkeeping” authorization record, because it is created by the Galileo system for its own purposes instead of arriving over network rails.

For example, a cardholder purchases three items from three different third-party vendors on the same online store. The items are for 150.00, 75.00, and 175.00. The online merchant obtains preauthorization for 400.00, and Galileo creates a conventional entry in the authorizations table for 400.00. A few days later, the first vendor ships its portion of the order and the online merchant sends a clearing for 150.00. The clearing message contains an indicator to show that it is a partial settlement. Galileo matches the clearing message to the authorization and then creates a bookkeeping authorization record for the remaining 250.00.

When the second vendor ships its portion, and the online vendor sends a clearing message for 75.00, Galileo matches the clearing to the bookkeeping authorization record and creates a second bookkeeping authorization record for the remaining 175.00. When the third vendor sends its portion, Galileo matches it to the second bookkeeping authorization record, and because an indicator in the clearing message says that there are no more clearings to come, Galileo marks the transaction as settled.

For an example see Incremental clearing in Card Transaction Examples.

International settlements

When an international settlement arrives, the settlement amount is usually different from the authorization amount, because the amounts are converted according to the exchange rate at the time of the authorization and then again at the clearing. There is therefore a risk of the account being driven negative if the exchange rate at clearing results in a higher amount than the authorization.

The amount in the merchant's local currency is communicated in the local_amt field in the Program API and local_currency_amount in the Auth API.

Settlements in the Program API

When Galileo settles a transaction, it changes the state of the authorization from pending to settled. The authorization is no longer returned by any endpoint that returns unsettled authorizations. To get settled transactions, use these endpoints:

• Get Account Overview — Returns settled transactions in the transactions object of the response.
• Get Transaction History — Returns only settled transactions.
• Get All Transaction History — Returns all transactions: settled, unsettled, unexpired, and backouts.

To see settlements in Program API responses and an explanation of the fields, open these Recipes:

Settlement Events API

There is only one settlement event webhook, SETL: setl, which is sent to your Settlement Events endpoint at the time that Galileo processes the batch settlement file.

To see examples of transaction sequences with Events API webhooks, see Authorization events in the Events API Scenarios guide.