# Support
source: https://developer.mastercard.com/agent-suite-for-merchants/documentation/support/index.md

👉 Replace these example FAQs, support channels, escalation paths, and policy answers with the questions and responses that are actually relevant for your service. Where you keep accordion sections, edit the question text inside each `expand` block so the headings match your real support topics. Keep the `get-help` call-to-action button only if the default support CTA is correct for your service; otherwise replace it with the right support route or remove the block.

## FAQ {#faq}

### General {#general}

* This template provides a governance-aligned reference for documenting a Mastercard API. Service owners should adapt it to their own service name, endpoints, and real business flows.
* This template supports authenticated API patterns and end-to-end encryption guidance, including OAuth-based signing and JWE where required.

### Onboarding {#onboarding}

* Sandbox access should begin by creating a project on Mastercard Developers, generating credentials, and following the [Quick Start Guide](https://developer.mastercard.com/agent-suite-for-merchants/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.
* Refer to the [API Basics --- Environment Descriptions](https://developer.mastercard.com/agent-suite-for-merchants/documentation/api-basics/index.md#environment-descriptions) section for the documented environments, base URLs, and environment-specific behavior.
* Sandbox credentials are used 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/agent-suite-for-merchants/documentation/api-basics/index.md#client-authentication).

### Integration {#integration}

Resource identifiers are typically returned automatically by the API when a new record is created.

**Common cause:** Attempting to use an identifier before the resource exists, or copying the returned value incorrectly.

**Steps to obtain a valid identifier:**

1. Send the relevant `POST` request from [Add New Records](https://developer.mastercard.com/agent-suite-for-merchants/documentation/use-cases/add-new-database-records/index.md).
2. The API returns a success response. Copy the generated identifier from the response body or `Location` header.
3. Use this identifier in subsequent retrieve, update, or delete requests.
Resource availability or processing state is typically indicated by a `status` field.

**Common cause:** Omitting the `status` filter returns all records, which can make operational state harder to interpret.

**Steps to find resources by status:**

1. Send a filtered `GET` request using the supported query parameters from [Query Information](https://developer.mastercard.com/agent-suite-for-merchants/documentation/use-cases/querying-database-information/index.md).
2. Review the returned items and pagination metadata.
3. If no results are returned, create new test data through the relevant create endpoint.
* You can retrieve information about a resource, transaction, or administrative record using the valid identifier returned from a previous create or search flow.
* You can update information about a resource as long as you have a valid identifier and any versioning headers required by the service.
* You can retrieve records by status, date range, category, or other supported query parameters depending on the endpoint.
* In Sandbox, the API usually returns mocked or test data intended for validation and integration testing.

### Policy {#policy}

* Throttling and rate limits should be documented by the owning service. If no custom policy is published, consumers should still design clients defensively and handle transient failures correctly.
* Compliance requirements should be documented by the service owner. Use this section to explain any applicable data protection, audit, or payment-security obligations.

### Performance {#performance}

* Response-time targets and observed performance should be documented by the service owner if they are part of the consumer contract.
* Throughput expectations should be documented by the service owner if they are part of the published SLA.

### Support {#support}

* In the event that your team experiences issues, contact the [API Consultancy \& Standards Support Team](mailto:API_Consultancy_and_Standards@mastercard.com) and include the API name, the issue summary, and supporting evidence such as request IDs or screenshots.
* [The API Status Page](https://developer.mastercard.com/api-status) informs Mastercard Developers users of the status of each API.

## Get Help {#get-help}

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