Log into Pro Sandbox

This guide contains details about some of the Auth API webhook fields.

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.

## Tokenization requests

Networks send tokenization requests when the card is first provisioned to a mobile wallet, either with manual provisioning or push-provisioning. (See <a href="doc:setup-for-mobile-wallets" target="_blank">Setup for Mobile Wallets</a> for the Galileo provisioning procedures.) A tokenization request for an initial provisioning has the name of the wallet provider for `token_type`.

Merchants also send tokenization requests to perform <a href="doc:authorization#avs-only-checks" target="_blank">AVS checks</a> on tokenized cards before accepting the cards as payment in an app or on a website. In this case, `token_type: Merchant`.

The network relays provisioning requests that it receives from wallet providers and merchants. The requests are MTI 0100 and contain the PAN and cardholder identifiers.

  • If the card was push-provisioned through your app or web site, the cardholder's identity and card information have already been verified. Galileo responds with `00`.

  • If the card was manually provisioned, the wallet provider is requesting additional verification checks such as AVS, CVV2, and the last four digits of the cardholder's phone number. Galileo responds with the AVS result plus `05`, `85`, or `00`, depending on which checks were passed. For initial provisioning requests, see the <a href="doc:setup-for-mobile-wallets#manual-provisioning-workflow" target="_blank">Manual provisioning workflow</a> in the _Setup for Mobile Wallets_ guide for details.

  • For merchant AVS requests, Galileo responds to a successful check with code `85` (AVS requested to verify account) or with `05` (do not honor) to an unsuccessful check.

  • Additional tokenization data may be present in the `tar_object`, which contains details about the tokenization authorization request (TAR) such as risk scores, device location, device ID and a recommendation from the wallet provider that indicates whether the tokenization request should be approved.

When the network notifies Galileo whether the provisioning request was successful, Galileo sends you an Account Event API webhook that corresponds to the result, such as <a href="ref:api-reference-events-api-mobile-activation-tcn" target="_blank">`ATCN: mobile_activation TCN`</a> for a successful provisioning to an Apple Pay wallet. See <a href="doc:setup-for-mobile-wallets#events-api-messages" target="_blank">Events API messages</a> in the _Setup for Mobile Wallets_ guide for a list of tokenization-related event messages.

## IIAS fields

Clients who issue Visa FSA (flexible spending account), HRA (health reimbursement arrangement) or HSA (health savings account) cards can receive data in the `iias_data` object that indicates whether the item or service being purchased is an eligible medical expense. An inventory information approval system (IIAS) at the point of sale provides this verification. Where merchants sell both qualified and non-qualified goods and services, the `qualified_healthcare_products_total` field indicates how much of a purchase is a qualified medical purchase.

Note

Some medical merchants do not use IIAS because their card readers are programmed with a healthcare-related MCC such as 8099 (Medical Services and Health Practitioners). FHA/HRA/HSA cards can be used at these locations without IIAS verification.

## Advanced Auth API fields

The `advanced_auth_api_fields` object is provided only to those clients who request that additional data elements (DEs) be parsed and returned in the Auth API webhook. The ADVAF parameter must be set for these fields to be returned, and the network must be Mastercard.

### Point of sale data

DE061 contains information about the conditions that exist at the point of sale (POS) at the time of the transaction. Consult the <a href="ref:api-reference-de061-subfields" target="_blank">DE061 Subfields</a> enumeration for a list of included subfields and their values.

#### Example


### Subscription services
If you subscribe to Mastercard services such as Fraud Rule Management (FRM) or Safety Net, these services may make decisions on transactions before they are forwarded to Galileo. If one of the services declines a transaction, it sends an advice (MTI 0120) to Galileo to notify of the decline. 
Galileo can pass data elements in the Auth API webhook that provide information on the decline. Sample values are shown below—consult the documentation from Mastercard to interpret the values you receive. Values for all of these fields may or may not be returned depending on which services you're subscribed to.
For example, if the transaction is declined by Safety Net, these are the values passed in the webhook:
  • **DE048** — Additional information
    • **Subfield 71** — On-behalf service (OBS)
      • **Subelement 1** — `18` (fraud scoring service)
      • **Subelement 2** — `C` (fraud scoring service successful)
    • **Subfield 75** — Fraud assessment prediction information
      • **Subelement 1** — `998` or `000`
      • **Subelement 2** — `NM` (network monitor)
      • **Subelements 3–5** — Rule-adjusted score and reason code
  • **DE060**
    • **Subfield 1** (Advice reason code) — `120` (transaction blocking)
  • **DE121** (Authorizing agent identification code) — `000003` (decline from on-behalf service)
#### Example