This guide shows which validation checks Galileo performs on all incoming authorization requests and describes which corresponding fields Galileo sends in the Auth API webhook. If you are not using the Auth API, this guide provides insight into how Galileo decides which response code to return.

With this guide you may also want to consider these resources:

• <a href="doc:authorization-controller-api" target="_blank">**Authorization Controller API**</a> — General information about how the Auth API works.

• <a href="ref:api-reference-events-authorization-response-codes" target="_blank">**Authorization Response Codes**</a> — Codes that Galileo supports. You may also arrange with Galileo to send custom response codes, depending on your use case and business requirements.

• <a href="doc:authorization" target="_blank">**Authorization**</a> — General explanation of the authorization process at Galileo.

The actual order of the checks may vary from what is shown here.

### PAN validation

The PAN must exist in the Galileo system. If the PAN does not exist, Galileo returns `14` (invalid card number) to the network and performs no further checks. When Galileo returns a `14`, you do not receive a webhook.

### Card validation

The card-validation checks help ensure that the card used at the point of sale is an authentic card and that an authorized cardholder is presenting it. The summary of card-validation results is in the `validation_results` object.

#### AVS check

See <a href="doc:authorization#avs-only-checks" target="_blank">AVS-only checks</a> in the _Authorization_ guide for an explanation of these checks.

Galileo returns the result of an <<glossary:AVS>> check in the `avs_result` field. In the `avs_data` object, Galileo provides the information that it used to perform the check. If you have reason to believe that Galileo is not using the correct address for the account, you can perform AVS yourself and override Galileo's result. See <a href="doc:authorization-controller-api#avs-override" target="_blank">AVS override</a> in the _Authorization Controller API_ guide for more information.

Galileo does not use AVS results to calculate a response code: Merchants decide how to handle each result. It is therefore possible for Galileo to return `avs_result: N` with `response_code: 00`, which means that there was no AVS match but the transaction is otherwise approved, because the account supports it.

If you do not want AVS checks for your product, such as for gift cards, set the NOAVS product parameter to return a "gift" value for `avs_result`. Merchants can decide whether to accept the result as success or failure and then proceed according to their business policies.

#### PIN

When a PIN is not provided, the transaction usually arrives at Galileo over credit rails and `pin: N`.

When a PIN is provided, the transaction usually arrives at Galileo over debit rails. These are the steps for validating the PIN. The actual order of the steps may vary from what is shown here:

1. Galileo checks whether a PIN has been set for the card. If it has not been set, Galileo returns `55` (incorrect PIN) and `pin: M`.

2. If a PIN has been set, Galileo checks whether PBLOK permits this type of PIN transaction. If it does not, Galileo returns `57` (transaction not permitted to cardholder) and `pin: B` (blocked).

3. If this type of PIN transaction is permitted, Galileo checks whether the PIN has been locked after exceeding the number of failed PIN attempts. If it has, Galileo returns `75` (allowable number of PIN tries exceeded) and `pin: L` (locked). (The failed PIN count will reset to zero after the time specified in PBTIM.)

4. If the PIN has not been locked, Galileo compares the provided PIN to the hashed PIN that Galileo has on record. If the PINs do not match, Galileo returns `55` (incorrect PIN) and `pin: F`.

5. If all checks are passed, the `pin` field contains `Y` (verified).

##### Offline PIN

Some implementations of EMV chips permit card readers to validate PINs without contacting the issuer. With offline PIN validation, the chip contains a PIN block (encrypted PIN) that the card reader compares to the PIN provided on the keypad. The card reader includes the result in the authorization request message.

Galileo passes the summary of the result in the `offline_pin` field. This table shows which other fields will be populated according to the result.

The `terminal_verification_results` (TMV) object inside the `emv` object contains the results of the PIN verification. The `raw` field contains a value provided by the network, and the meaning of the value is different for each network. Galileo provides the interpretation of the `raw` field in the rest of the fields inside the TMV object.

In most cases, the card reader can verify the PIN using the chip, but if the PIN has been recently changed, the reader needs to contact the issuer for verification. When the card reader is requesting online PIN verification from Galileo, then `online_pin_entered: true`.

See <a href="doc:pin-set-procedures#offline-pins" target="_blank">Offline PINs</a> in the _PIN-Set Procedures_ guide for more information on changing offline PINs.

#### CVV

Galileo checks whether the CVV matches the hashed CVV in the Galileo system. There are three possible CVV values to match, depending on how the card information was acquired:

• **CVV1** — Embedded in tracks 1 and 2 of a magnetic stripe, it verifies that merchants have the physical card in their possession for card-present transactions. When this CVV does not match, Galileo returns `05` (do not honor).

• **CVV2** — Printed on a card, this three-digit number is used for card-not-present transactions. When this CVV does not match, Galileo returns `N7` (CVV2 error) for Visa or `63` (security violation) for Mastercard.

• **CVV3** — This code is cryptographically generated by a contactless transaction and verified by the issuer. When this CVV does not match, Galileo returns `05` (do not honor) and `arqc: F`.

#### 3-D Secure

Some e-commerce sites add another layer of cardholder verification using the 3-D Secure protocol (3DS), which is a two-step authentication process that cardholders must pass at the time they attempt to make a purchase on a 3DS-enabled web site. The standard in general is facilitated by EMVco, and each card network has a branded implementation of 3DS:

• **Visa** — Visa Secure

• **Mastercard** — SecureCode

• **Discover** — ProtectBuy

Galileo recommends that you obtain documentation from the networks to better understand how they implement 3DS.

This table shows country-by-country requirements for 3DS as of October 2021.

For 3DS to be successful, three entities must be participating in 3DS:

• The merchant

• The issuer

• The cardholder

When a cardholder attempts to make a purchase on a 3DS-enabled site, the results of the authentication are passed in the authorization request, and Galileo includes them in the `aav` field and the `ecommerce` object. When the e-commerce site does not implement 3DS, `is_ecommerce: false` and the remaining fields in the `ecommerce` object are not sent.

Galileo does not currently perform 3DS validation. You may integrate with a third-party 3DS provider, called an access control server (ACS), if you want to support 3DS, or you may use the networks' on-behalf services. The 3DS-related fields that Galileo relays in the Auth API webhook show the results of 3DS validation after it has been performed by the ACS or network. Galileo approves or denies transactions based on the validation results, and so these fields are provided for your information, not for decisioning.

As you parse the `ecommerce` object, remember that some combinations of values result in a liability shift from the merchant to the issuer. Consult the documentation from each network to see which results trigger a liability shift.

The AAVPV product parameter controls whether Galileo uses the validation results that it receives from the ACS or network when deciding whether to approve a transaction. Set this value to `Y` for Galileo to use the validation results. When this parameter is not set, Galileo does not use 3DS validation results for decisioning.

See the reference material for the <a href="ref:webhook_authorization_post_2" target="_blank">Auth API v2</a> or <a href="ref:webhook_authorization_post_3" target="_blank">Auth API v3</a> for details on what each e-commerce field means.

### Transaction type validation

Galileo checks product and account settings to determine whether the transaction type is permitted to the cardholder. When any of the following items is true, Galileo returns `57`:

• ATM withdrawals are blocked by account feature 9 or PBLOK.

• Point-of-sale (POS) transactions are blocked by PBLOK.

• Recurring transactions are blocked by BLKRI.

• Non-mobile-wallet transactions are blocked by account feature 20.

• Card-present transactions (except mobile wallet) are blocked by account feature 21.

• Mobile wallet transactions are blocked by account feature 22.

• Card-not-present transactions are blocked by account feature 6.

• Cash transactions are blocked by product settings.

• Cashback transactions are blocked by CASHB.

• Cash advances are blocked by account feature 10.

• Cash and POS transactions are blocked in this country.

• International transactions are blocked by account feature 8.

• _All but Mastercard._ Transactions with this MCC are blocked.

• Card loads are not allowed by product settings.

• Suspected fraud (all but Visa, Mastercard and STAR).

• _Mastercard only_. Card is in status `X` (waiting for emboss), `Y` (ready to activate), `B` (blocked) or `O` (operations hold).

Where there is an account feature blocking the transaction, you can call <a href="ref:post_setaccountfeature" target="_blank">Set Account Feature</a> to unblock the transaction type for that account. Where a product parameter or product settings block the transaction, you can ask Galileo to change the setting for the product.

### Account validation

Galileo verifies that the account can support the transaction.

#### Card and account status

Galileo verifies that the card and account statuses are both `N` (normal, active).

For Visa, if the card or account is in any status except `N`, Galileo returns `46` (closed account).

For Mastercard, Galileo returns `78`, `57` or `51`, depending on the card status:

For lost or stolen cards, these are the response codes:

For all other networks, for any other account statuses besides `N`, `S`, or `L`, Galileo returns `05` (do not honor).

#### Card frozen

The "frozen" attribute of a card is independent of its status. An authorization request for a frozen card is always denied. Galileo returns `78` (card frozen) for Visa, `62` (card frozen) for Mastercard and STAR, or `57` (transaction not permitted) for all other networks.

#### Expiry date

For card-not-present transactions, the expiry date that the cardholder entered is in `merchant_supplied_expiration_date`. For card-present transactions the expiry data in the magnetic stripe is in `track_expiration_date`.

Galileo checks the expiry date against the expiry date in the Galileo system to ensure that the values match. Galileo provides the date that it has on file in `expiration_date`. If the dates do not match, Galileo returns `54` (card expiration date mismatch). If the expiration date has passed, Galileo also returns `54`.

#### Sufficient funds

If Galileo holds the account balance, Galileo checks the available funds in the cardholder account against the amount in `trans_amount`. The available funds do not include any holds, such as from previous unsettled authorizations. Galileo populates the available funds in the `available_funds` field in the `amounts` object. This value represents the account balance before the transaction is applied.

If you hold the account balance, you must determine whether the account can support the amount in `trans_amount`, based on your records.

If the account does not contain sufficient funds, the standard response code is `51` (insufficient funds). However, there are several ways to address insufficient funds without returning `51`:

• <a href="doc:authorization-controller-api#partial-authorization" target="_blank">**Partial authorization**</a> — If the merchant accepts partial authorizations (`partial_supported: true`), you or Galileo can return the amount of the authorization in `partial_amount` with response code `10`.

• <a href="doc:about-overdraft-accounts" target="_blank">**Overdraft**</a> — If you have set up overdraft, your account settings determine whether an ATM withdrawal can use overdraft (ODATM) and also whether the overdraft funds are moved at the time of authorization or settlement (ODTOR).

• <a href="doc:authorization-controller-api#real-time-transfers" target="_blank">**Real-time transfers**</a> — You move funds from a dedicated account into the cardholder account to cover the authorization amounts.

#### Velocity limits

Galileo checks whether the transaction violates velocity limits—whether the amount or number of transactions exceeds a threshold, for example. These velocity limits are determined at the time you set up your products. You can also arrange with Galileo to create account-level velocity controls (ALCs). (See <a href="doc:about-account-level-auth-controls" target="_blank">About Account-Level Authorization Controls</a> for more information.)

If `trans_amount` violates an amount limit, Galileo returns `61` (exceeds withdrawal amount limit) or if a transaction-count limit is reached Galileo returns `65` (exceeds withdrawal frequency limit).

Also see <a href="doc:authorization-controller-api#overriding-limits" target="_blank">Overriding limits</a> in the _Authorization Controller API_ guide.

### Other checks

These other checks validate characteristics of the transaction not included in the previous categories.

#### Merchant validity

According to your product settings you can prohibit transactions with certain merchant types (per MCC) or by merchant ID. For ATM withdrawals in specified countries you can prohibit transactions at certain times of day. You can also arrange with Galileo to create account-level merchant controls (ALCs). (See <a href="doc:about-account-level-auth-controls" target="_blank">About Account-Level Authorization Controls</a> for more information.)

If the MCC or merchant ID is prohibited, Galileo returns `03` for Mastercard or `57` (transaction not permitted to cardholder) for all other networks.

#### Country

Galileo verifies that the transaction is taking place in a country that has not been blocked in your product settings. If the country has been blocked, Galileo returns `62` (card not valid in this region) for Visa or `05` (do not honor) for all other networks.

#### Fraud risk

Galileo compares the value that the network provides in `risk_score` with the value set in product parameters (BRSGE, BRSMC or BRSPU). If the risk score exceeds the threshold, Galileo returns `59` (suspected fraud) for Visa and STAR networks, `63` for Mastercard, or `57` for the other networks. Risk scores are not returned when the transaction is an advice, because the transaction has already been acted on by the network.

If you are using Galileo's dynamic fraud rules engine, any rule violations are reported in the `rules_denied` and `rules_warned` fields, provided you have the RULAP product parameter set. When the rule violations are sufficient to deny a transaction, Galileo returns `59`.