Log into Pro Sandbox

Auth API Field Detail

Suggest Edits

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

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

Tokenization requests

Networks send tokenization requests when the card is first provisioned to a mobile wallet, either with manual provisioning or push-provisioning. (See Setup for Mobile Wallets 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 AVS checks 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 Manual provisioning workflow 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 ATCN: mobile_activation TCN for a successful provisioning to an Apple Pay wallet. See Events API messages 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 DE061 Subfields enumeration for a list of included subfields and their values.

Example

"advanced_auth_api_fields": {
    "61": {
        "subfield 8": "0",
        "subfield 1": "1",
        "subfield 3": "2",
        "subfield 4": "5",
        "subfield 5": "1",
        "subfield 6": "0",
        "subfield 12": "00",
        "subfield 10": "6"
    }
}

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

"advanced_auth_api_fields": {
    "48": {
        "subfield 71": "18C",
        "subfield 75": "998NM500202110303850040211050200"
        },
    "60": {
        "subfield 1": "120"
    },
    "121": "000003"
}

Updated 14 days ago