# Support
source: https://developer.mastercard.com/identity-insights-solutions/documentation/support/index.md

## FAQ {#faq}

### General {#general}

While both products provide identity-based risk evaluation, they differ in scope.

Identity Insights Risk Score:

* Focuses on delivering a single predictive Identity Insights Risk Score across identity, device, and payment
* Lightweight and easy to integrate   

Identity Insights for Transactions:

* Provides comprehensive scores and insights across identity, device, and payment
* Supports advanced risk modeling and optimizes use cases Both offer a holistic view of transaction risk but differ in the extent of the insights returned. If you are looking for risk insights to feed a machine learning (ML) model or build intricate rules to improve precision and recall, Identity Insights for Transactions is better suited to support advanced decisioning.


Both products are available to integrate in any of these three regional domains:

* North America
* Europe
* Asia/Pacific

<br />

Identity Insights for Transactions is available to customers globally, where Identity Insights Risk Score is only available to Mastercard merchants and acquirers in eligible territories tied to a Digital Fee. Contact your Mastercard representative to determine if you meet the eligibility requirements. Mastercard Identity Insights for Transactions is a transaction risk intelligence service that provides insights about the person, payment, or device information associated with a transaction. It helps organizations make more informed risk decisions while supporting a balance between fraud prevention and customer experience. Identity Insights for Transactions helps organizations better understand whether the identity information associated with a transaction appears consistent, trustworthy, or potentially risky. This can support use cases such as fraud reduction, false decline reduction, authentication optimization, and improved manual review prioritization.

<br />

No, Identity Insights for Transactions provides insights that support fraud and risk decisioning, but it does not decide for the customer. Customers decide how to use Identity Insights for Transactions outputs within their own fraud rules, risk models, authentication strategies, and operational processes. No, Identity Insights for Transactions does not approve, decline, authenticate, or authorize transactions. It provides enriched insights for an identity, enabling customers to make informed risk decisions regarding how to treat a transaction.


Identity Insights for Transactions can provide insights across person, payment, device, and combined identity relationships. For field-level detail, customers should refer to the [API Reference](https://developer.mastercard.com/identity-insights-solutions/documentation/api-reference/index.md) page. Identity Insights for Transactions is best suited for organizations that need to evaluate risk in digital, card-not-present, or e-commerce transactions. This includes merchants, acquirers, payment service providers, fraud platforms, marketplaces, and organizations that route or score transactions on behalf of downstream customers.
Typical good-fit organizations include organizations that want to:

* Improve fraud detection
* Reduce unnecessary customer friction
* Reduce false declines
* Improve confidence in transaction approval decisions
* Support manual review prioritization
* Optimize authentication or PSD2 Transaction Risk Analysis strategies

<br />

Identity Insights for Transactions can be relevant to many digital commerce businesses, especially businesses with high transaction volumes, customer identity data, fraud exposure, or manual review processes. Examples include:

* Retail
* Travel
* Digital goods
* Marketplaces
* Financial services
* Gaming
* Subscription services
* Other card-not-present environments
Although Identity Insights for Transactions is a Mastercard product, it can provide identity intelligence across all transactions regardless of the payment technology or card scheme associated with the transactions. Identity Insights for Transactions is designed for use across regions, but availability, data coverage, endpoints, and onboarding requirements may vary by geography. Customers must confirm regional applicability with their Mastercard representative during onboarding. Identity Insights for Transactions can be deployed at different points in the transaction journey depending on the customer's objective. A simple way to think about deployment is:

* Pre-authentication: Use Identity Insights for Transactions before deciding whether to request a frictionless authentication experience or a challenge.
* Preauthorization: Use Identity Insights for Transactions before sending the transaction for authorization, to inform risk routing or acceptance decisions.
* Post-authorization: Use Identity Insights for Transactions after authorization to support fulfillment, review, shipment, reversal, or other operational decisions.
Pre-authentication deployment is useful when a customer wants to use identity intelligence before deciding how to route a transaction through authentication. In this context, Identity Insights for Transactions insights are used before determining whether to request a frictionless experience, request a challenge, or decline processing. Post-authorization deployment is useful when a customer wants to perform additional risk analysis after a transaction has already been authorized. In this context, using Identity Insights for Transactions post-authorization can help a customer to determine whether a transaction moved to settlement or shipment, sent to manual review, or reversed. In the event of a chargeback request, it can also be an added value in determining whether a dispute is pursued or not. Transaction risk analysis is the process of assessing data associated with a transaction to determine the likelihood of fraud or abuse. Identity Insights for Transactions supports transaction risk analysis by providing identity, payment, and device signals that can enrich a customer's existing fraud and risk decisioning process. Identity Insights for Transactions insights are typically used as an additional input within a broader risk strategy. Customers can combine Identity Insights for Transactions with:

* Internal fraud models
* Business rules
* Authentication policies
* Manual review workflows
* Order fulfillment controls
* Historical customer data
Depending on the customer's risk strategy, Identity Insights for Transactions insights can help inform whether to:

* Continue processing the transaction
* Request authentication
* Request additional verification
* Route the transaction to manual review
* Delay fulfillment
* Reverse or cancel a post-authorization transaction
* Decline the transaction
Yes, Identity Insights for Transactions can help reduce false declines by giving customers a more complete view of the identity context across a transaction. The actual impact depends on how the customer incorporates Identity Insights for Transactions insights into their fraud rules, models, and review processes. Yes, Identity Insights for Transactions can help customers apply additional checks selectively by improving their understanding of transaction risk. This supports better authentication routing, manual review prioritization, and confident approval decisions. Identity Insights for Transactions can provide signals that indicate unusual relationships between identity, payment, and device elements. These signals can support investigation of potential account takeover, synthetic identity, identity misuse, or other suspicious transaction patterns. Person Insights help customers determine the trustworthiness of the individuals involved in the transaction, based on the person-based identity attributes present in the requests. These attributes can be:

* Name
* Email
* Phone
* Address
Payment Insights help customers determine the trustworthiness of the payment credential being used in the transaction based on the history of the credential and the meta-data alongside other identifying attributes in the transaction. Combination Insights help customers understand relationships, or lack of relationships, between different elements of the submitted identity, payment, and device data, highlighting anomalies that could indicate an increased likelihood of the transaction being fraudulent. An anomaly is a characteristic or relationship that seems unusual in the context or the transaction. An anomaly is a risk signal, not a conclusion that fraud has occurred. No, genuine customers can also appear anomalous. For example, a customer may:

* Change address
* Change phone number
* Travel
* Use a new payment method
* Transact in a way that differs from previous patterns   
  Therefore, Identity Insights Solutions' insights must be considered alongside other fraud, authentication, and business context.
Identity Insights Solutions is a PCI-compliant solution. As such, whether Funding Primary Account Numbers (PANs) can be included in requests to Identity Insights Solutions is dependent on the PCI status of the requesting service within the customer's own environment. Customers should consult their internal compliance teams or qualified PCI advisors to determine whether Funding PANs can be included in Identity Insights Solutions requests.


Identity Insights Solutions uses secure transport and payload encryption controls to help protect sensitive data in transit. Data transmitted between client applications and Mastercard is protected using TLS/SSL. Identity Insights Solutions also uses JWE to provide end-to-end payload encryption for sensitive data, such as PII. Internally Identity Insights Solutions subjects all sensitive data to one-way hashing prior to storing any data, which ensures it cannot be reconstituted in the event it is accidentally disclosed. No, customers need only provide the information available to them and relevant to their use case. In general, richer, and more complete, inputs can enable richer insights. For field-level requirements, refer to the [API Reference](https://developer.mastercard.com/identity-insights-solutions/documentation/api-reference/index.md) page.

<br />


When available, the inclusion of Card Details to include the Funding PAN will enable richer insights to be returned, which improves the accuracy of the customer's decisioning. If the Funding PAN is not available, for example if an upstream service is not PCI-compliant, the inclusion of the associated token can be used as a substitute, along with the non-PCI card details. PSD2 is a European payments regulation intended to improve payment security, consumer protection, and innovation in payment services. The European Banking Authority describes the PSD2 Regulatory Technical Standards on strong customer authentication and secure communication as supporting consumer protection, innovation, and payment security across the [European Union](https://www.eba.europa.eu/legacy/regulation-and-policy/regulatory-activities/payment-services-and-electronic-money-0).

<br />

Strong Customer Authentication (SCA) is a regulatory requirement under PSD2 that generally requires authentication using two or more independent factors. These factors are commonly grouped as something the customer knows, something the customer has, and something the customer is. The European Banking Authority's PSD2 materials described SCA and secure communication requirements under [PSD2](https://www.eba.europa.eu/legacy/regulation-and-policy/regulatory-activities/payment-services-and-electronic-money-0). An SCA exemption is a regulatory mechanism that allows a transaction to proceed without applying SCA, where specific conditions are met, to include an assessment of the riskiness of a transaction by considering the person, device, and identity attributes present in the transaction, a key capability of Identity Insights for Transactions. In practice, exemptions can help reduce unnecessary customer friction, but their use depends on applicable regulations, issuer and acquirer policies, transaction risk, and scheme or market rules. The [EBA's PSD2 Regulatory Technical Standards](https://www.eba.europa.eu/legacy/regulation-and-policy/regulatory-activities/payment-services-and-electronic-money-0) include requirements related to SCA and secure communication. No, Identity Insights for Transactions does not perform SCA and does not replace authentication obligations. Identity Insights for Transactions can provide identity and risk insights that customers can use to support authentication routing, risk assessment, or exemption strategies. Identity Insights for Transactions complements EMV 3-D Secure by providing additional identity intelligence that can help customers decide when to:

* Request authentication
* Request a challenge
* Pursue a lower-friction path where appropriate
The Identity Insights Risk Score response includes:

* Identity Risk Score: A normalized score ranging from 0-500 indicating the likelihood of risk associated with the identity
* Reason code: Explainability elements that help interpret key contributors to the score
Identity Insights for Transactions response includes:

* Identity Risk Score: A score ranging from 0-500 indicating the likelihood of risk associated with the identity.

<!-- -->

* Reason code: Explainability elements that help interpret key contributors to the score
* Single Attributes Scores: Scores that illustrate the risk that individual identity attributes contribute to the transaction
* Single Element Signals: Meta-data and historical behavior patterns related to individual identity attribute
* Combination Signals: Signals derived from meta-data and historical behavior of combinations of identity attributes
All of the risk solutions are designed to operate effectively with flexible and minimal input requirements. As our product examines the relationship between identity attributes to ensure the best possible performance, it is recommended to send all the identity attributes that are available to you. For the Identity Risk Score to be returned, a minimum of three of the following core identity groupings are required. Additional inputs can improve model accuracy, but the system is built to generate meaningful scores even when partial data is available. Yes, once at least three of the major core identity groupings are present, the Identity Risk Score is generated. The model is designed to handle partial or incomplete inputs. While the accuracy of the score improves with more data, the model is built to generate a meaningful result when the minimum inputs are available. Missing inputs do not automatically bias the result towards higher risk. These are the classifications of the core identity groupings:

* Name (Primary/Secondary)
* Email Address (Primary/Secondary)
* Phone Number (Primary/Secondary)
* Full Postal Address (Primary/Secondary)
* IP Address
* All Device Characteristics

<!-- -->

* User-Agent
* Screen Width/Height
* Time zone
* Language

<!-- -->

* Payment Details (PAN/Token)
* All Card Details (BIN, Last 4, Card Expiry)
* All transaction details

<!-- -->

* Merchant Name
* Acceptor Business Code (MCC)
* Merchant Country Code
* Amount
* Currency Code
* Currency Code Exponent
* Transaction Date

Note: At least three of these classifications are required to generate the Identity Risk Score. Either Identity Insights Risk Score or Identity Insights for Transactions can be used across a variety of identity-driven decision points, including:

* Transaction risk screening (pre-checkout or preauthorization)
* Account registration and onboarding validation
* Fraud prevention and abuse detection
* Step-up authentication decisioning
* Risk scoring for high-volume or low-friction environments   
  Because of its low latency and simple integration, Identity Insights Risk Score is especially effective in workflows where speed and scale are critical.
Our risk solutions are most effective when used as part of a layered fraud strategy.
Customers typically:

* Use as an initial risk signal for fast screening
* Combine it with internal rules or modules
* Optionally augment it with internal or external data   
  This approach allows businesses to balance speed, cost, and accuracy across different transaction types and risk thresholds.

### Onboarding {#onboarding}

* Sandbox access begins by creating a project on Mastercard Developers, generating credentials, and following the [Quick Start Guide](https://developer.mastercard.com/identity-insights-solutions/documentation/quick-start-guide/index.md) for the first API call.
* Sandbox is typically available as a self-service environment. For additional non-sandbox environments or production onboarding, follow the steps documented for your service and contact the appropriate support team when required.
* Sandbox credentials are for development and validation. Production credentials are used only after Production access is granted for your project.


* Key validity depends on the service configuration. For instructions on generating a new set of keys, see [API Basics --- Client Authentication](https://developer.mastercard.com/identity-insights-solutions/documentation/api-basics/index.md#client-authentication).
Identity Insights Solutions is delivered through an API. [Mastercard Developer Zone](https://developer.mastercard.com/identity-insights-solutions/documentation/api-basics/index.md) states that customers can integrate by generating a Mastercard API client or by using a REST/HTTP client of choice, while leveraging Mastercard authentication and encryption libraries where appropriate.

<br />

There are two main environments:

* Sandbox: A pre-production environment intended for integration testing before moving to production.
* Production: The live production environment used after approval and production readiness steps are complete. Refer to the [API Basics](https://developer.mastercard.com/identity-insights-solutions/documentation/api-basics/index.md) page for an overview on how to integrate to these environments.
Customers must create a Sandbox project, configure the necessary credentials and encryption keys, and use the provided testing resources to validate their integration. The [Tutorials and Guides](https://developer.mastercard.com/identity-insights-solutions/documentation/tutorials-and-guides/index.md) page includes dedicated guides for creating a Sandbox project and performing integration testing. Identity Insights Solutions uses Mutual Layer Security, or MTLS, for client authentication. The [API Basics](https://developer.mastercard.com/identity-insights-solutions/documentation/api-basics/index.md) page provides details on the authentication requirements to connect to Identity Insights Solutions. Transport between the customer application and Mastercard is secured using TLS/SSL. Identity Insights Solutions also uses JSON Web Encryption (JWE) for end-to-end payload encryption to help protect sensitive data such as Personally Identifiable Information. Refer to [API Basics](https://developer.mastercard.com/identity-insights-solutions/documentation/api-basics/index.md) page for more details.


No, Sandbox and Production environments use separate certificates and credentials. Sandbox and Production are separate environments with separate keys and approval processes. Refer to [API Basics](https://developer.mastercard.com/identity-insights-solutions/documentation/api-basics/index.md) page for more details. This depends on how the customer's Mastercard project and Identity Insights Services are configured. Customers must confirm with their Mastercard implementation or support contact before reusing certificates across services. Certificate and key validity periods can depend on the credential type and the Mastercard tooling used to generate them. Customers monitor expiration dates in the Mastercard Developer Dashboard. Refer to [API Basics](https://developer.mastercard.com/identity-insights-solutions/documentation/api-basics/index.md) page for more details. Customers use the endpoint assigned during onboarding and project configuration. Regional endpoints can vary and customers must confirm the correct endpoint with Mastercard before production launch. There are regional endpoints available within Europe, Singapore, and the United States regions. However, the appropriate endpoint must be validated against the customer's approved project configuration before publication or implementation. Refer to the [Code and Formats](https://developer.mastercard.com/identity-insights-solutions/documentation/code-and-formats/index.md) page for more details and the [API Reference](https://developer.mastercard.com/identity-insights-solutions/documentation/api-reference/index.md) page for error response details.

<br />


A company ID and ICA are Mastercard identifiers used to support customer onboarding, billing, reporting, and operational setup. Customers can work with their Mastercard representative to determine the required identifiers for their contracting and production onboarding path. Customers can contact their Mastercard representative or use the contact options provided through the Developer Zone.
Onboarding typically includes:

* Commercial engagement
* Project setup
* Sandbox access
* Credential configuration
* Integration testing
* Production approval

<br />

There are a number of mechanisms available to customers to conduct Proof Of Value Testing with Identity Insights for Transactions. To understand which is the best fit for a particular customer, customers can discuss their:

* Fraud challenges
* Transaction flows
* Available data
* Fraud tooling
* Authentication strategy
* Target outcomes with Mastercard
Customers can contact their Mastercard account representative, business development contact, or the support channels provided through the Identity Insights for Transactions Developer Zone. Identity Insights for Transactions is made available through Mastercard commercial engagement processes. Interested organizations can contact Mastercard to discuss:

* Eligibility
* Contracting
* Implementation
* Pricing
* Regional availability

### Policy {#policy}

Yes, our API is fully PCI-DSS compliant. While there is no throttling policy, Mastercard reserves the right to limit user requests to preserve the reliability of the system.

### Performance {#performance}

To perform a load test in production, contact your Mastercard technical contact with your planned load details. This is to ensure that our systems can support the load without adversely affecting other customers and services. Our APIs are tested up to 150tps.

### Support {#support}

In the event that your team experiences technical issues related to the Mastercard Developers portal---including account or project setup, API keys, API documentation, and general developer or integration inquiries---use the **Get Help** option to contact API Support. For general support, use the same **Get Help** option to be routed to the appropriate Identity team for your inquiry. Include as much information as possible, including the API name, issue summary, and supporting evidence, such as request IDs or screenshots. Your Mastercard representative can vary depending on the Identity Insights solution you are using. If you already have an established Mastercard account or Identity contact, reach out to that contact directly. If you do not know who your Mastercard representative is, submit a request through [Contact Sales](https://www.mastercard.com/us/en/contact-sales.html) if you are inquiring about Identity Insights for Transactions and a member of the Mastercard Identity team will contact you within five business days. For general support or about the other products, use the same Get Help option for routing to the appropriate Identity team.
* [The API Status Page](https://developer.mastercard.com/api-status) informs Mastercard Developers users of the status of each API.
Customers can refer to the Identity Insights Solutions Developer Zone provided during onboarding for:

* Documentation
* Tutorials and Guides
* API Reference
* Support Channels
Customers can review:

* [Overview](https://developer.mastercard.com/identity-insights-solutions/documentation/index.md)
* [API Basics](https://developer.mastercard.com/identity-insights-solutions/documentation/api-basics/index.md)
* [Tutorials and Guides](https://developer.mastercard.com/identity-insights-solutions/documentation/tutorials-and-guides/index.md)
* [Reference Application](https://developer.mastercard.com/identity-insights-solutions/documentation/developer-tools/reference-app/index.md)
* [API Reference](https://developer.mastercard.com/identity-insights-solutions/documentation/api-reference/index.md)
* [Code and Formats](https://developer.mastercard.com/identity-insights-solutions/documentation/code-and-formats/index.md)

<br />

Additionally, your Mastercard representative can provide additional details and support needed.

## Get Help {#get-help}

### Contact us for technical support {#contact-us-for-technical-support}