# Support source: https://developer.mastercard.com/open-finance-us/documentation/support/index.md Here we provide details of how you can get support, along with Frequently Asked Questions and other material. We provide two levels of support: * For specific product help with Mastercard Open Finance, we provide a full Support Case Management (SCM) tool via the Mastercard Connect website. * For general enquiries and help with the Mastercard Developers website and API access, use the ["Get Help" button on this page](https://developer.mastercard.com/open-finance-us/documentation/support/index.md#get-help-with-mastercard-developers). ## Get Help with Mastercard Open Finance {#get-help-with-mastercard-open-finance} Mastercard Connect is the secure global platform where Mastercard business customers come to onboard, enroll, service, and grow their business with Mastercard. The Support Case Management (SCM) tool within Mastercard Connect is used to create and track support cases created in SCM with the Mastercard Open Finance support team. Note: Access to the SCM tool on Mastercard Connect is only available once a contract between you and Mastercard has been executed. Please work with your Sales Representative or Client Success Manager, or contact [OFin.contactsales@mastercard.com](mailto:OFin.contactsales@mastercard.com) for more information. ### Create a Support Case in SCM {#create-a-support-case-in-scm} To create a new Support Case: 1. Sign into 2. Select **Support Case Management** from the menu. 3. Go to **Support Cases** and click on the **Go to support cases** button (alternatively, you can access support cases through the Help Center by clicking on the **Help** icon). 4. On the **Support Cases** page you can create a new case, or track the progress of an existing case. To create a new case, click on the **Create new case** button. * Enter a suitable summary (a brief description of the issue) in the first text box. * Select Open Banking (US and Australia) as the category so your query goes to the correct team (select **Other** and **Open Banking** , then **US and Australia** ). ![](https://static.developer.mastercard.com/content/open-finance-us/uploads/OFin-SCM-create-case.png) * Add details of the issue in the Description field. * Under the **US and Australia information** heading, select the **Issue Type** (for example, **Request a new feature** or **New support case** ). ![](https://static.developer.mastercard.com/content/open-finance-us/uploads/OFin-SCM-create-case-us-aus-info.png) * When you've entered all the information required, click on the **Create Case** button. ## Get Help with Mastercard Developers {#get-help-with-mastercard-developers} You can contact us for technical support for issues relating to the Mastercard Developers Platform by clicking on the "Get Help" button:
Once logged in to Mastercard Developers you can get help with issues such as API access keys, information on other API products on the Mastercard Developers platform, and other related matters. Note that this service will not be able to provide in-depth product support for Mastercard Open Finance. Tip: You can also talk to other developers on the [Mastercard Developers Forums](https://forum.developer.mastercard.com/s/). ## Frequently Asked Questions {#frequently-asked-questions} Before contacting us, check our list of FAQs. We've grouped these in different themes. ### General {#general} Mastercard Open Finance has two levels of test access: * The Sandbox version allows access to all endpoints using testing customers and mock Financial Institution data. * Production (Non-Billable) is also a testing environment but uses active customers and real Financial Institution data. A testing customer is used for testing purposes and can only be used with Mastercard Open Finance test profiles and test bank (Finbank). An active customer mimics the workflow of the production environment, however no charges are incurred. When the account is moved to Production any active customer existing in the schema will then become a billable customer. In the Mastercard Open Finance system, there are two different types of customers: "testing" and "active". Testing customers can interact with our testing institution, Finbank, but cannot interact with live institutions. Testing customers are to be used for development and ongoing regression testing and will not be used in production. Conversely, active customers (also referred to as billable customers) represent end users on your platform. They can interact with live institutions but will throw an error if you try to add data from a testing institution. Each customer type has its own endpoint for creation. Note that if you are not on a Production (non-billable) or one of the Production-level plans, you will not have the ability to create active customers. Sandbox is the free tier used for testing and you will not have access to live FI data. Sandbox allows partners to test and use our APIs using Finbank or Finbank Profiles located on our documentation under Test the APIs. Production is a paid tier and allows partners to access live FI data, i.e. Chase and Wells Fargo, using an "active customer" (also referred to as billable customers) which represents end users on a partner platform. 500 testing customers. If this limit is hit, it is suggested to delete testing customers from the environment. After the customer's initial report is generated and during the credit-decisioning process, you can refresh the reports using the APIs rather than re-engaging the customer. Financial Institution data reports have unlimited free refreshes within 60 days. There is a one-to-one relationship between a customer record and a consumer record. While the customer record can be deleted after use, a consumer record cannot. As Mastercard Open Finance is a Credit Reporting Agency, we are required to retain report records associated with a consumer ID for six years, in order to support potential disputes of inaccurate information. ### Auth \& Configuration {#auth--configuration} A Mastercard Open Finance Auth Token is valid for up to two hours (120 minutes) and is required to access all of the Mastercard Open Finance endpoints. Best practice is to use a single token for all endpoint requests and assign a timestamp for each token. Check the current timestamp before making any requests and if the token is older than 90 minutes, generate a new token. This typically implies the app key is wrong. It will say too many requests because the app key controls the rate limit, and the rate limit of any invalid key is 0. If the Partner ID or Partner Secret is wrong, an "Invalid Credentials" error will be thrown instead. A Mastercard Open Finance token is required to access any of the APIs and is passed as a header. See [Partner Authentication](https://developer.mastercard.com/open-finance-us/documentation/api-basics/index.md#partner-authentication). After 5 attempts to call **Create Access Token** with an incorrect Secret, API access for the Partner ID used will be locked. You will receive a 24302 error for all subsequent API calls. Please contact [Open Finance support](https://developer.mastercard.com/open-finance-us/documentation/support/index.md#create-a-support-case-in-scm) to get assistance unlocking your account. ### Mastercard Data Connect {#mastercard-data-connect} Yes, Mastercard provides SDKs for both web and mobile (iOS and Android). See [Integrating with Mastercard Data Connect](https://developer.mastercard.com/open-finance-us/documentation/connect/integrating/index.md). Yes. During your onboarding to Production the product delivery team will work with you to configure the financial institutions you want to display. See [Configure the Data Connect Experience](https://developer.mastercard.com/open-finance-us/documentation/connect/configure-connect-experience/index.md) and [Institutions Settings](https://developer.mastercard.com/open-finance-us/documentation/connect/connect-institutions-settings/index.md). Yes, this will be configured with the product delivery team during your onboarding to Production. You can also temporarily change these settings when you generate a Data Connect URL. See [Configure the Data Connect Experience](https://developer.mastercard.com/open-finance-us/documentation/connect/configure-connect-experience/index.md) and [Institutions Settings](https://developer.mastercard.com/open-finance-us/documentation/connect/connect-institutions-settings/index.md). Mastercard's Open Finance Solutions generic branding will be used, and a standard transaction aggregation will be performed. No. The Experience parameter can be omitted. The absence of this parameter will cause Data Connect to default to using Mastercard's generic branding and performing a standard transaction aggregation. Yes, the old account would still be shown to the user after being closed. However, Mastercard Open Finance would not be able to aggregate data from the old account as it has been closed at the Financial Institution. Yes. It is possible to customize the Data Connect experiences to support multiple Mastercard Open Finance solutions. Reach out to your Account Manager for assistance customizing your Data Connect experience. See [Configure the Data Connect Experience](https://developer.mastercard.com/open-finance-us/documentation/connect/configure-connect-experience/index.md). ### Financial Institutions {#financial-institutions} Mastercard Open Finance provides FI Certification status information via the [Get Certified Institutions](https://developer.mastercard.com/open-finance-us/documentation/financial-institution/index.md#certified-institutions) API. You can also check the status manually on the [Supported Institutions](https://developer.mastercard.com/open-finance-us/documentation/financial-institution/supported-institutions/index.md) page. ### Products {#products} The GET Account Owner endpoint returns the following values: **Account Owner(s) names as listed by the Financial Institution** Mastercard Open Finance will pass a Name string that reflects the name(s) on the account In some cases, slight differences can appear between data returned by Mastercard Open Finance Account Owner service and data provided by a legitimate user. A user might omit their middle name in an application, or provide a shortened version of their legal name. There are several techniques a client can implement to reduce the chance of these mismatches, including substring matching, string cleaning to remove data such as initials and suffixes, or applying a fuzzy matching algorithm, for which many open-source implementations are available. **Address on file for the given account** The easiest form of address matching is the matching of city names, regions, and postal codes, after ensuring that you have transformed these into the same format that you have obtained from your user (for example, making sure that any zip code is in a 5-digit format rather than a 9-digit format). Street addresses can be compared using the same techniques as described in the "Name" section to avoid any mismatches caused by slight inconsistencies. Mastercard Open Finance outputs reports in the following formats: JSON, XML, PDF. The Accept header is used to indicate the type of media or resource used in the response. A "shadow" transaction occurs when a transaction is originally found during an account aggregation, but in a subsequent aggregation, the transaction is not found. Therefore, it is unknown whether the transaction is still legitimate because it is possible that the financial institution (FI) may have determined that the transaction was invalid and removed it from the FI's data source. Alternatively, the FI may have altered the transaction to be substantially different from the original transaction. These modifications or deletions can cause transactions to duplicate in the Mastercard Open Finance data or persist after being removed from the institution's data source. Mastercard identifies these transactions by designating them with a "shadow" status. Developers may choose how to handle the shadow status, but we generally recommend treating them as having been deleted from the data source. **Note:** In some cases that result in a shadow status, there may be a new active transaction representing the new transaction state. There is no need to link these transactions together as the current transactions at the FI represent the latest transaction state. No, account details can be used for recurring payments on a given account. Only if an account materially changes might it be necessary to re-verify. Mastercard Open Finance would recommend the use of our Account Balance Check product to have higher confidence in the availability of funds prior to processing a payment. No. A client only needs to validate an account on the first interaction. If the client already has an account number for a given Account ID, they may only need to retrieve the balance for the account prior to processing any payment to see if funds are available. ### Metrics Dashboard {#metrics-dashboard} The API metrics dashboard provides a unified, real-time view of your integration's health, performance, and usage. It acts as a comprehensive monitoring and business intelligence tool. The dashboard visualizes key metrics such as API call volume, latency, and error rates, and offers detailed logs for every request, response, and webhook event. 'My API Success Rate' is calculated using just the API traffic for a particular partner ID (or group of partner IDs if you select a project). It shows you how just the API calls you are making are performing. The Dashboard shows this alongside the 'Platform API Success Rate' which is based on traffic from all partners for the same API endpoints. This allows you to see how the requests you are making compared to all other partners on the platform who are making the same API calls. Active accounts represent bank accounts that the platform is connected to and retrieving data from. This is not the same as active end users (account holders) as an end user can have multiple accounts. Every API call you make will return a response and included in every response is a "response code" that indicates if the call was successful or not. The platform collects these success codes for every API request made and calculates a percentage of the successful calls against the total number of calls being made. It does this across different intervals depending on how you are filtering the data: * For a Dashboard showing the last hour of data, it will calculate the API success rate every 5 minutes. * For the last 24 hours of data, it will calculate the API success rate every 60 minutes. * For the last 7 days of data, it will calculate the API success rate every 6 hours. * For the last 30 days of data, it will calculate the API success rate for each day (24 hours). When you add a new partner ID to a project it can take up to 10 minutes for that new partner ID to be picked up by the Dashboard metric calculations. If you refresh the Dashboard within 10 minutes of adding the partner ID, the calculations may not have completed yet and there won't be any data to be rendered. Wait for 10 minutes and when you refresh the Dashboard it will be visible. Some of the API products you call are actually made up of collection of API calls e.g. the Verification of Income Report will call the Get Transactions API behind the scenes in order to generate the report. The Dashboard tracks every API call that is made either directly by the partner, or indirectly to fulfil the requirements of another product API. Sometimes when you call an endpoint like "Get Transactions" it will pull the data from our database cache. This is much faster than making a direct call to the Financial Institution every time. When data is returned from the cache it means there was no direct call to the Financial Institution and so that endpoint won't be listed under it in the dashboard. There are two possible reasons why your API success rate may be different to the value displayed in the dashboard: 1. The dashboard does not yet include API calls that encountered an error at the API Gateway i.e. before the API call made it to the Open Banking product service. If you filter out API calls that were rejected by the API Gateway your API success rate should align with the dashboard. 2. The dashboard does not include a small number of API calls. If you filter out the following short list of APIs your API success rate should align with the dashboard: * /connect * /connect-components * /connect/v2/experiences * /connect/experiences * /connect/v1/certifiedInstitutions * /institution/v1 * /institution/v2 * /applications * /applications/({application_id}/institutions * /customers/institution-logins/{institution_login_id})/authorization-details * /curator/v2/experiences * /connection-status * /payroll-connector * /dcr * /analytics/balance * /analytics/cashflow * /analytics/payment-history * /analytics/business * /analytics/data * /payments/paymentIndicator * /transfer/webhooks * /transfer * /business-services The Dashboard tracks every error code returned and groups them into one of four categories: * **Financial Institution**: errors returned by the Financial Institution when the platform tried to request data. These could be related to expired tokens, end users revoking access to their account, maintenance windows, etc. * **Platform**: errors returned by the US Open Banking API services. These could be related to a timeout when making a call to one of the API endpoints, an expired access token, etc. * **Customer**: errors related to issues that the calling client can correct. These could be related to malformed request payloads, expired tokens, calling an API in the wrong order, etc. * **Other**: errors that don't belong to the previous three categories. We endeavor to identify any errors in the Other category and move them to the correct category. The Billable report in the Client Hub only includes billable API calls. The Mastercard Developers dashboard includes billable and non-billable API calls. The "Direct" category represents connections to Financial Institutions that use OAuth. The "Legacy" category represents connections to Financial Institutions that don't use OAuth and these are typically slower. The "Blended" category groups all the Financial Institutions together and calculates median and P90 response times for all of them.