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:

• <a href="doc:about-transactions" target="_blank">**About Transactions**</a> — General explanation of how transactions are represented in the Galileo system

• <a href="doc:about-card-transactions" target="_blank">**About Card Transactions**</a> — High-level explanation of how card transactions work

• <a href="doc:authorization" target="_blank">**Authorization**</a> — 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 <<glossary:RDF>>s, consult the <a href="page:card-transaction-scenarios-index" target="_blank">Card Transaction Scenarios</a>. Also consult <a href="page:finding-transaction-data" target="_blank">Finding Transaction Data</a> 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 matching a clearing message to a pending authorization in its system. When Galileo finds a match, Galileo backs out the hold, changes the pending authorization to a settled transaction, sends the Settlement Events <a href="ref:api-reference-events-api-setl" target="_blank">`SETL: setl`</a> message for that transaction, and posts the amount to the cardholder account. 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 <a href="ref:api-reference-transaction-types#settlement-file" target="_blank">Settlement file</a> table in the _Transaction Types_ enumeration for settlement-related transaction codes.

## Driving an account negative

Galileo is obligated to post all of the transactions that it receives in the settlement batch file, regardless of whether there is a matching authorization. In some cases, a cardholder account is 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 <a href="doc:authorization#authorization-expiry" target="_blank">Authorization expiry</a> in the _Authorization_ guide for more information, or <a href="doc:card-transaction-examples#settlement-of-an-expired-authorization" target="_blank">Settlement of an expired authorization</a> 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 <a href="doc:authorization#upcharges" target="_blank">Upcharges</a> in the _Authorization_ guide for one way to mitigate this risk.

The issuer or cardholder may later dispute any posted transaction. See <a href="doc:crediting-cardholder-accounts#disputes" target="_blank">Disputes</a> 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 <<glossary:CST>> and in the response to <a href="ref:post_getalltranshistory" target="_blank">Get All Transaction History</a>. 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 transaction type code will match the settlement transaction code 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 Funds Flow document that Galileo gave you.

For examples of backouts see any example in <a href="doc:card-transaction-examples" target="_blank">Card Transactions Examples</a> or the <a href="page:card-transaction-scenarios-index" target="_blank">Card Transaction Scenarios</a>.

## 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 held 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:

• <a href="doc:card-transaction-examples#five-step-sequence" target="_blank">Five-step sequence</a> in _Card Transaction Examples_

• <a href="page:scenario-2-preauthorization-with-completion" target="_blank">Scenario 2: Preauthorization with Completion</a>

• <a href="page:scenario-23-account-funding-transaction" target="_blank">Scenario 23: Account Funding Transaction</a>

## 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 <<glossary: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 and then sends a $45 clearing, the $50 hold is backed out and only $45 is debited from the account, effectively returning the remaining $5 to the cardholder account when the authorization expires.

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, $75, and $175. The online merchant obtains preauthorization for $400, and Galileo creates a conventional entry in the authorizations table for $400. A few days later, the first vendor ships its portion of the order and the online merchant sends a clearing for $150. 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.

When the second vendor ships its portion, and the online vendor sends a clearing message for $75, Galileo matches the clearing to the bookkeeping authorization record and creates a second bookkeeping authorization record for the remaining $175. 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 <a href="doc:card-transaction-examples#incremental-clearing" target="_blank">Incremental clearing</a> in _Card Transaction Examples_.

## International settlements

When an international settlement arrives, the settlement amount is usually different from the authorization amount, because it reflects fluctuations in the currency conversion rate between the authorization time and the clearing time. There is therefore a risk of the account being driven negative, if the conversion 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 then is not returned by any endpoint that returns unsettled authorizations. To get settled transactions, use these endpoints:

• <a href="ref:post_getaccountoverview" target="_blank">**Get Account Overview**</a> — Returns settled transactions in the `transactions` object of the response.

• <a href="ref:post_gettranshistory" target="_blank">**Get Transaction History**</a> — Returns only settled transactions.

• <a href="ref:post_getalltranshistory" target="_blank">**Get All Transaction History**</a> — 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 webhook, <a href="ref:api-reference-events-api-setl" target="_blank">`SETL: setl`</a>, 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 <a href="doc:events-api-scenarios#authorization-events" target="_blank">Authorization events</a> in the _Events API Scenarios_ guide.