---
title: "Dispute components"
description: "Use Platform Experience components to build interactive dashboards for your users."
url: "https://docs.adyen.com/platforms/components-overview/after-payment/disputes-component"
source_url: "https://docs.adyen.com/platforms/components-overview/after-payment/disputes-component.md"
canonical: "https://docs.adyen.com/platforms/components-overview/after-payment/disputes-component"
last_modified: "2026-09-15T14:06:03+02:00"
language: "en"
---
# Dispute components
Use Platform Experience components to build interactive dashboards for your users.
##### Learn more
 [View our repository on GitHub](https://github.com/Adyen/adyen-platform-experience-web)
 [Try it out with a live demo](https://demotool.adyen.com/se/pie/platform-tx)
 [Explore the latest updates](/release-notes/platforms-and-financial-products)
The dispute components enable you to offer dispute management in your portal's user interface (UI) with minimal engineering effort. These components integrate all the features required to monitor and resolve chargebacks without making multiple API requests. This means you do not need to implement complex API calls to retrieve dispute reason codes, track respond-by dates, or manage the document upload process for defense. The components handle all of this automatically.
Additionally, the components provide greater flexibility for data customization. You can enrich the dispute view with your own custom fields, icons, links, and buttons, allowing the UI to align with your specific business needs.\
This page provides guidance on:
* The available dispute components, which include the **Dispute Overview** component and the **Dispute Management** component.
* A standard user flow that these components cover.
* Functionalities and information required to understand dispute components, such as filtering by balance account, defending or accepting disputes, uploading supporting documentation, and reason codes.
The guidance and features available may differ based on the library version in use. We recommend using the latest library version to take advantage of the newest features and improvements.
Ensure you select a version in the next section before starting your integration.
## Dispute components
Use Platform Experience components to build interactive dashboards for your users.
## Requirements
Before you begin, take into account the following requirements, limitations, and preparations.
| Requirement | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Integration type** | You must have the Adyen for Platforms integration. |
| **API credentials** | You must have a [Balance Platform API key](/marketplaces/manage-access/api-credentials-web-service?tab=create-ws_1) (for example, **ws\[\_123456]@BalancePlatform.\[YourBalancePlatform]**) to access the [Session authentication API](https://docs.adyen.com/api-explorer/sessionauthentication/latest/overview). Ensure that you have asked your Adyen contact to assign the following role to your API credential:- **Disputes Component: Manage** |
| **Limitations** | **Dispute visibility and access** Account holders can view disputes created in this component on or after May 22, 2025. An account holder can perform an action or view submitted defense documents if and only if both of the following conditions are met:- They are the sole non-liable account holder referenced via splits in the original payment.
- They receive at least one split of type `BalanceAccount` in the corresponding payment or capture. **Document upload limits**- Documents must be no larger than 2 MB and in `.pdf`, `.jpg`, .`jpeg`, or `.tiff` format.
- Images files must be no larger than 10 MB and in `.jpg`, `.jpeg`, or `.tiff` format.**Refunds not supported**- Currently this component does not support refunds. |
| **Setup steps** | Before you begin:- Verify that the component is available in the [languages](#supported-languages) that apply to your situation.
- Check our [Component libraries](/marketplaces/components-overview) page for additional information on the supported countries/regions and browser versions. |
### Component Description
## Disputes Overview component
The **Disputes Overview** component shows a list of disputes, including chargebacks, Requests for Information (RFIs), and fraud alerts for a specific balance account within a specified time period. Users can quickly view the status of open or closed disputes, helping them monitor and take action when needed.
This component organizes disputes into three tabs:
* **Chargebacks**: shows undefended or unresponded chargebacks and RFIs that require user action. Each dispute record includes details such as the respond by date, payment method, dispute reason, and disputed amount. Users can select a record to open the [**Dispute Management** ](#dispute-management-component)component, where they can accept or defend the dispute.
* **Fraud alerts**: shows fraud alerts to help users identify suspicious activity. Each record includes the payment method, fraud reason, total payment amount, and date of the alert. Fraud alerts correspond to the term "Notification of Fraud" in the Customer Area and [dispute documentation](/risk-management/understanding-disputes/dispute-process-and-flow).
* **Ongoing & closed**: shows ongoing chargebacks, RFIs, and resolved disputes to help users track and match disputes against payment activity. Each dispute record includes details such as the payment method, dispute reason, and disputed amount. This tab also shows the status of a dispute, see dispute [statuses](#statuses-of-a-dispute) for more details.
Note that the marketplace configuration dictates split chargeback handling. The **Disputes Overview** component does not alter existing split logic. See [Split chargebacks](/marketplaces/split-transactions/split-chargebacks) for more details.
The following illustrate each tab of the **Disputes Overview** component.
### Tab: Chargebacks
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/component-description/disputes-chargebacks-desktop.png)
### Tab: Fraud alerts
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/component-description/disputes-fraud-alerts-desktop.png)
### Tab: Ongoing & closed
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/component-description/disputes-ongoing-closed-desktop.png)
The **Disputes Overview** component enables users to:
* View a list of chargebacks, fraud alerts, and ongoing and closed disputes for all or a specific balance account.
* Filter disputes by balance account, date opened, payment method, and dispute reason. See [available filters](#available-filters) for more details.
By default, the **Disputes Overview** component includes the [**Dispute Management** ](#dispute-management-component)component, which provides more details about a specific dispute and allows users to accept or defend a chargeback.
### Available filters
The following sections shows the available filters and their values for the **Disputes Overview** component.
**
#### Balance account
Users with multiple balance accounts can switch between them using the **Balance Account** filter.
**
#### Time period
The **Time period** filter specifies the date and time range for displaying dispute results. The specified time is determined by the time zone of the selected balance account.
| Filter value | Description |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Last 7 days** | Includes disputes from the previous six days and from today until the current time. For example, if today is a Tuesday and the time is 8:00 PM, disputes from the previous Wednesday midnight until this Tuesday 8:00 PM are included. |
| **This week** | Includes disputes for the current week, starting from Monday midnight until the present moment. |
| **Last week** | Includes disputes from Monday midnight to Sunday 11:59:59 PM of the previous week. |
| **Last 30 days** | The default setting. Includes disputes from the previous 29 days and from today until the current time. |
| **This month** | Includes disputes for the current month, starting from the first day of the month until today's date. |
| **Last month** | Includes disputes from the previous month, starting from the first day of the month until the end of the month at 11:59:59 PM. |
| **Year to date** | Includes disputes from the first day of the current year up until today's date. |
| **Custom** | Allows setting a custom time period. |
**
#### Payment method
The **Payment method** filter enables users to filter disputes by specifying the payment method used; this corresponds with card schemes.
**
#### Dispute reason
The **Dispute Reason** filter lets users sort disputes by specifying the reason, such as fraud, consumer dispute, or processing error. Note, instead of dispute reasons, the fraud alerts tab shows Notifications of Fraud (NOF).
## Dispute Management component
The **Dispute Management** component shows specific information about a dispute, including the [dispute status](#dispute-statuses), dispute reason, reason code, dispute, payment, and merchant references. The component also includes important dates such as when the dispute was opened and when a response is due. For chargebacks, users can accept or defend the dispute. When defending a chargeback, the component prompts users to complete required steps, such as selecting a defense reason and uploading supporting evidence. The component also allows for custom data integration, such as your own fields, icons, links, and buttons.
By default, the **Dispute Management** component is embedded in the **Disputes Overview** component and is shown as a modal window on the overview page. You can also choose to show the **Dispute Management** component on a separate page during the [initialization of the components](#initialize-components).
The following tabs illustrate how the component appears on various screen sizes.
### Tab: Mobile
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/component-description/dispute-details-mobile.png)
### Tab: Desktop
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/component-description/dispute-details-desktop.png)
The **Dispute Management** component enables user to:
* View detailed information about a selected dispute, including dispute reason, reason code, status, and related reference information.
* Accept a chargeback. Accepting a chargeback confirms the disputed amount will not be returned to the balance account.
* Defend a chargeback and submit a defense reason with supporting evidence, which is sent directly to the card schemes for review.
### Defend Disputes
## How disputes are defended through components
Users can defend disputes directly through the dispute components. When the user submits a defense, the components automatically call Adyen's API to process the dispute. This means no additional actions are needed on your part as a platform.
The user flow for defending a chargeback dispute through the components is as follows:
1. From the Chargebacks tab the user selects a dispute record. In the Dispute Management, the user selects the **Defend chargeback** button.
2. In the **Defend chargeback** modal window, the user specifies a reason for defending the chargeback.
3. In the **Defend chargeback** modal window the user is prompted to provide evidence. The user uploads the required documents to support the chargeback defense.
4. (Optional) The user has the option to upload additional documents to support the defense.
5. The user submits the defense for review.
6. After the dispute request is processed, users can view the [dispute status](#dispute-statuses) message in the Dispute Management.
### Tab: Dispute management
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/defend-disputes/dispute-details.png)
### Tab: Defense reason
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/defend-disputes/defend-reason.png)
### Tab: Provide evidence
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/defend-disputes/provide-evidence.png)
### Tab: Additional evidence
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/defend-disputes/additional-evidence.png)
### Tab: Submit defense
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/defend-disputes/submit-defense.png)
### Tab: Dispute status
[](/user/pages/filters/pe-components-dashboards/disputes/1-6-0/defend-disputes/dispute-status.png)
### Dispute Statuses
## Statuses of a dispute
When a transaction is disputed, it can begin as an RFI (Request for Information) or a chargeback.
* An RFI is an initial inquiry from the issuer seeking more details about a transaction, and importantly, no funds are withdrawn from the balance account at this stage. An RFI doesn't always escalate to a chargeback.
* A chargeback means that the disputed funds have been, or will soon be, withdrawn from the balance account. To potentially recover these funds, the user will need to submit a formal defense. For more information, see [Dispute reason codes and defense requirements](/risk-management/understanding-disputes/dispute-reason-codes/?tab=chargeback_0_1#defense_requirements)
The dispute components show the status of a chargeback or RFIs, which represents the different stages the dispute goes through. The components automatically manage status updates, so no further action is needed on your part. Disputes move between tabs based on their current status. Each status reflects where the dispute is in the resolution process, and determines which tab it appears under.
For example, a chargeback may first appear under the **Chargebacks** tab when the status is **Undefended**. After the user submits a defense, the status changes to **Pending**, and the dispute automatically moves to the **Ongoing & Closed** disputes tab.
The following diagram illustrates how chargeback statuses evolve over time.
[](/user/pages/filters/pe-components-dashboards/disputes/1-9-0/dispute-statuses/chargeback-statuses.png)
Some disputes are not defendable due to the rules of the payment method, not because of a limitation in the component. These disputes begin and end in the "Lost" status, as no defense action is possible.
You can find a detailed explanation for each status in the following table.
| Status | Description |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Undefended** | The chargeback is open, but no defense has been submitted yet. Action is required from the user if they want to defend the dispute. |
| **Accepted** | The user has accepted the chargeback. |
| **Pending** | The user has defended the chargeback. The issuer is reviewing the dispute and will determine an outcome. |
| **Won** | The user submitted a defense and the chargeback was won. |
| **Lost** | The user submitted a defense and the chargeback was lost, either because the issuer has not accepted the defense or the user did not take action. |
The following diagram illustrates how RFI dispute statuses evolve over time.
[](/user/pages/filters/pe-components-dashboards/disputes/1-9-0/dispute-statuses/rfi-statuses.png)
You can find a detailed explanation for each status in the following table.
| Status | Description |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Unresponded** | The RFI is open, but no information has been submitted yet. The user must provide information by a certain time or the status will change to expired. |
| **Responded** | The user has submitted the requested information. The issuer is reviewing the response and will determine an outcome. |
| **Expired** | The RFI has expired because the user did not take action. |
For more information, see the [Dispute flow and process](/risk-management/understanding-disputes/dispute-process-and-flow/) section.
## How it works
The integration of components involves both server-side and client-side processes. You can find more details on the [component libraries](#see-also) page.
### Integration steps
Follow these steps to integrate the component(s):
1. [Create an authentication session from your server](#create-token)
2. [Install component library in your front end](#install-library)
3. [Initialize components](#initialize-components)
4. [Optional: Localize components](#localize-components)
5. [Optional: Customize component appearance](#customize-appearance)
6. [Optional: Customize component data](#customize-data)
### Create A Session
## 1. Create an authentication session from your server
To ensure secure communication between components and Adyen server, you must configure your server for authentication and create a session token. To create the token:
1. From your server, make a POST [/sessions](https://docs.adyen.com/api-explorer/sessionauthentication/latest/post/sessions) request specifying the following parameters:
To make this API request, your API key must have the **Disputes Component: Manage** role in your Customer Area. For more information, refer to the [Requirements](#requirements) section.
| Parameter | Required | Description |
| ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [allowOrigin](https://docs.adyen.com/api-explorer/sessionauthentication/latest/post/sessions#request-allowOrigin) |  | The URL where the component will appear. Must follow the format of `https://www.your-company.example.com` or `https://*.your-company.example.com`, where `your-company.example.com` is the actual web address of your marketplace. On live, only the HTTPS protocol is supported. |
| [policy](https://docs.adyen.com/api-explorer/sessionauthentication/latest/post/sessions#request-policy) |  | An object that contains:- [resources](https://docs.adyen.com/api-explorer/sessionauthentication/latest/post/sessions#request-policy-resources): An object that contains:
* `accountHolderId`: The unique identifier of the account holder that is linked to the balance account shown in the component.
* [type](https://docs.adyen.com/api-explorer/sessionauthentication/latest/post/sessions#request-policy-resources-type): The type of resource. Set this to **accountHolder**.
- [roles](https://docs.adyen.com/api-explorer/sessionauthentication/latest/post/sessions#request-policy-roles): The role required to use the component. From library **v1.6.0**, set this to **Disputes Component: Manage** role in your request to enable users to process disputes through the components. |
| [product](https://docs.adyen.com/api-explorer/sessionauthentication/latest/post/sessions#request-product) |  | The type of product the component belongs to. Set this to **platform**. |
Here is an example request for creating a session token.
**Create a session token**
```bash
curl https://test.adyen.com/authe/api/v1/sessions \
-H 'content-type: application/json' \
-H 'x-api-key: ADYEN_BALANCE_PLATFORM_API_KEY' \
-d '{
"allowOrigin":"YOUR_DOMAIN",
"product":"platform",
"policy": {
"resources": [
{
"accountHolderId": "AH00000000000000000000001",
"type": "accountHolder"
}
],
"roles": [
"Disputes Component: Manage"
]
}
}'
```
2. Note the API response. Later, when [initializing the components](#initialize-components), you need to create and call a function that passes the entire session object from the response to your front end.
**Session token created**
```json
{
"id": "YOUR_SESSION_TOKEN_ID",
"token": "YOUR_SESSION_TOKEN"
}
```
### Install Component Library
## 2. Install component library in your front end
Use the Adyen Web npm package, or embed the Adyen Platform Experience script and stylesheet into your HTML file:
### Tab: npm (recommended)
Install the **Adyen Platform Experience** library in your front-end application as follows:
1. Install the npm package.
```bash
npm install @adyen/adyen-platform-experience-web
```
2. Import the library, the components, and the style sheet.
```bash
import { AdyenPlatformExperience, component_name } from '@adyen/adyen-platform-experience-web';
import "@adyen/adyen-platform-experience-web/adyen-platform-experience-web.css";
```
### Tab: Embed script and stylesheet
Use the `integrity` attribute so browsers can verify that the script and stylesheet have not been changed unexpectedly.
The value of the `integrity` attribute is the [Subresource Integrity (SRI) hash](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) which Adyen provides for each version of the Adyen Web JavaScript and CSS files.
Get the SRI hashes from the [release notes](/release-notes/platforms-and-financial-products) for the Platform Experience components, under **Updating to this version**.
**embed-script-stylesheet.html**
```html
```
### Initialize Components
## 3. Initialize components
To initialize the components:
1. Gather the following information to be passed when initializing the library and its components.
1. Gather these parameters to initialize the library.
| Parameter | Required | Description |
| --------------------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `availableTranslations`Deprecated | | **Deprecated.** This field is no longer needed because locales are now dynamically loaded on demand via CDN. Setting this field will trigger a deprecation warning. An array containing the names of the imported locale files used for localizing the components. For example, `[es_ES, nl_NL, fr_FR]`. |
| `environment` | | Specifies the environment for the component integration. The default value is **test**. Set the parameter to **live** when you are ready to go live. |
| `locale` | | Specifies the locale code, which determines the desired language of the components. This code must correspond to a [supported language](#supported-languages). For example, use **es-ES** for Spanish. |
| `onSessionCreate` |  | The callback function that retrieves an authentication session token and refreshes the current session. |
2. Gather these parameters to initialize each component.
Select the tab for the component you want to use:
### Tab: Disputes Overview component
| Parameter | Required | Description |
| --------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `allowLimitSelection` | | Determines whether the user can change the number of disputes shown per page. Default value: **true**. |
| `dataCustomization` | | An object that contains the `list` and `details` object, which include [customization specifications](#customize-data) for dashboard fields, allowing for additional data integration from your database. |
| `core` |  | The instance of the library. |
| `onRecordSelection` | | If defined, the event allows obtaining the dispute PSP reference when the user selects a specific dispute from any tab of the overview. You can use the obtained value to show the **Dispute Management** component in a different location within your portal's UI, outside the **Disputes Overview** component. |
| `preferredLimit` | | The number of disputes shown per page. Default value: **10**. |
### Tab: Dispute Management component
| Parameter | Required | Description |
| ------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `core` |  | The instance of the library. |
| `dataCustomization` | | An object that contains the `details` object, which include [customization specifications](#customize-data) for dashboard fields, allowing for additional data integration from your database. |
| `id` |  | The unique identifier of the dispute (PSP reference). |
| `onDismiss` | | The callback function triggers when a user selects the Go back button on the dispute management screen. Define this function if you need to handle the dismissal of the flow. |
| `onDisputeAccept` | | The callback function triggered after the user accepts the dispute and the dispute acceptance request has been successful. Define this function to exit the default flow after a successful dispute acceptance request. The function accepts an object as an argument that includes the `id` for the dispute. |
| `onDisputeDefend` | | The callback function triggered after the user defends the dispute, and the defense acceptance request has been successful. Define this function to exit the default flow after a successful dispute defense request. The function accepts an object as an argument that includes the `id` for the dispute. |
2. Create a DOM element on your portal's UI page where you want the component to be rendered.
Assign the element a unique and descriptive ID. This unique ID is important to avoid any misconfigurations when integrating multiple components into your portal's UI.
By default, the **Disputes Management** component is shown as a modal window within the **Disputes Overview** component. In this scenario, you only need to create a DOM element for the **Disputes Overview** component. If you want to use the **Dispute Management** component on its own, you need to create a separate DOM element for it.
If you are using JavaScript frameworks such as Vue or React, make sure that you use references instead of selectors and that you do not re-render the DOM element.
Select the tab for the component you want to use:
### Tab: Disputes Overview component
**Create DOM element**
```html
```
### Tab: Dispute Management component
**Create DOM element**
```html
```
3. Add a function that [calls your API](#create-token) to retrieve and refresh an authentication session token.
The following code is the same for both dispute components.
**Add function to retrieve and refresh an authentication session token**
```bash
async function handleSessionCreate() {
const response = await fetch('YOUR_IMPLEMENTATION_OF_CREATE_SESSION_ENDPOINT');
return response.json();
}
```
4. Initialize the component and mount it to the container you created.
Be sure to include the function for retrieving and refreshing the session token that you added in the previous step.
To implement the **Dispute Management** component as a modal window within the **Disputes Overview** component, use the following code examples. In this implementation, when a user selects a specific dispute from the overview page, the dispute ID is automatically passed to the **Dispute Management** component, and the modal window opens.
Select the tab for the component you want to use:
### Tab: Disputes Overview component
**Initialize library and create component**
```javascript
import { AdyenPlatformExperience, DisputesOverview } from '@adyen/adyen-platform-experience-web';
import "@adyen/adyen-platform-experience-web/adyen-platform-experience-web.css";
const core = await AdyenPlatformExperience({
onSessionCreate: handleSessionCreate,
});
const disputesOverview = new DisputesOverview({ core });
disputesOverview.mount('#disputes-overview-container');
```
### Tab: Dispute Management component
**Initialize library and create component**
```javascript
import { AdyenPlatformExperience, DisputeManagement } from '@adyen/adyen-platform-experience-web';
import "@adyen/adyen-platform-experience-web/adyen-platform-experience-web.css";
const core = await AdyenPlatformExperience({
onSessionCreate: handleSessionCreate,
});
const disputeManagement = new DisputeManagement({
core,
id: 'PPKFQ89R6QRXGN82'
});
disputeManagement.mount('#dispute-management-container');
```
5. (Optional) To use the **Dispute Management** component outside of the **Disputes Overview** component:
1. Define the `onRecordSelection` callback.
**Define onRecordSelection callback**
```javascript
const disputesOverview = new DisputesOverview({
core,
onRecordSelection: ({ id }) => {
// Use selected dispute id.
}
});
```
2. Initialize the **Dispute Management** component using the `id` from the object argument as shown below.
**Link to the selected record**
```javascript
const disputeManagement = new DisputeManagement({
core,
id: ''
});
```
### Localize Components
## 4. Optional: Localize components
During the [component initialization](#initialize-components), you can also configure the components to use one of the [supported languages](#supported-languages).
Update your code for initializing components to include the localization settings. If no localization settings are provided, the components will default to English.
**Localize components**
```javascript
import { AdyenPlatformExperience } from '@adyen/adyen-platform-experience-web';
const core = await AdyenPlatformExperience({
locale: 'es-ES', // See supported languages for possible values
/* ... */
});
```
### Customize Appearance
## 5. Optional: Customize component appearance
The dispute components have a default appearance with pre-defined styles, such as colors, fonts, and borders. You can customize the appearance of your components by overriding the default values of CSS variables and the class settings:
1. Inspect the components using your browser's developer tools.
2. Modify the styles in your style sheet file.
The following tabs show examples of how to style the components. The first example shows how to override predefined CSS variables to use different colors and values. The second example demonstrates how to update the CSS class setting to change the layout of the modal window from a pop-up window to a side panel view.
### Tab: Example 1: Override CSS variables
**style.css**
```bash
:root {
--adyen-sdk-border-radius-s: 10px;
--adyen-sdk-border-radius-m: 20px;
--adyen-sdk-border-radius-l: 30px;
--adyen-sdk-color-background-disabled: #9ecdb1;
--adyen-sdk-color-background-inverse-primary: #0abf53;
--adyen-sdk-color-background-inverse-primary-hover: #57d389;
--adyen-sdk-color-decorative-blue: #0abf53;
--adyen-sdk-color-outline-primary-active: #0abf53;
}
```
### Tab: Example 2: Update CSS class settings
**style.css**
```bash
.adyen-pe-modal {
border-left: 3px solid #0abf53;
border-radius: 0;
height: 100%;
max-height: unset;
right: 0;
}
```
### Customize Data
## 6. Optional: Customize component data
The dispute components allow you to include a diverse range of data types and sources to showcase within your user dashboard. You can:
* Integrate custom data, such as your own fields, icons, links, and buttons.
* Define the settings for each dashboard field, including their names and visibility.
When initializing your component:
1. Specify the `dataCustomization` parameter, including:
### Tab: Disputes Overview component
| Parameter | Required | Description |
| --------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `list` | | An object that includes customization settings for dashboard fields in the disputes overview. Example: `dataCustomization: { list: { } }` |
| `details` | | An object that includes customization settings for dashboard fields in the dispute management view. Example: `dataCustomization: { list: { }, details: { } }` |
### Tab: Dispute Management component
| Parameter | Required | Description |
| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| `details` | | An object that includes customization settings for dashboard fields in the dispute management view. Example: `dataCustomization: { details: { } }` |
2. Within the `list` and `details` objects, define the customization settings, such as field names or visibility.\
You can customize the default fields and add custom fields. In the dashboard, custom fields will be positioned immediately after the default fields.
### Tab: Disputes Overview component
| Parameter | Required | Description |
| ---------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `fields` |  | Defines the settings of dashboard fields in the disputes overview. Default fields: **'createdAt'**, **'status'**, **'respondBy'**, **'paymentMethod'**, **'disputeReason'**, **'reason'**, **'currency'**, **'disputedAmount'**, **'totalPaymentAmount'**. Example: `dataCustomization: { list: { fields: [] }, details: { fields: [] } }` |
| `onDataRetrieve` | | The callback function that retrieves a `Promise` object resolved with an array of the transaction records extended with custom data. Example: `dataCustomization: { list: { fields: [], onDataRetrieve: () => { } }, details: { fields: [], onDataRetrieve: () => { } } }` |
### Tab: Dispute Management component
| Parameter | Required | Description |
| ---------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `fields` | | Defines the settings of dashboard fields in the reports overview. Default fields: **'disputeReason'**, **'reasonCode'**, **'openedOn'**,**'respondBy'**, **'disputeId'**, **'account'**, **'paymentPspReference'**,**'paymentMerchantReference'**, **'defenseReason'**, **'defendedOn'**, **'disputeEvidence'**, **'acceptedOn'**,**'expiredOn'**. |
| `onDataRetrieve` | | The callback function that retrieves a `Promise` object resolved on the extended dispute record that contains custom data. |
1. Define the settings for each dashboard field using the following parameters.
| Parameter | Type | Required | Description |
| ------------ | ------ | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `key` | String |  | Specifies the name of a field. Example: `fields: [ { key: '_store' } ]` To prevent conflicts with the default field names, always start the names of your custom fields with an underscore (\_) character. |
| `visibility` | String | | Determines whether a field should be shown or not. Possible values: **visible**, **hidden**. If not specified, it defaults to **visible**. Example: `{ key: 'account', visibility: 'hidden' }` |
2. If adding a custom field, include the `onDataRetrieve` parameter.
Make sure to include the received data object in the return object by using the [spread syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax). The component can then use this as matching keys to map your custom data with the existing one.
**\`onDataRetrieve\` parameter**
```javascript
{
details: {
fields: [
{ key: '_store' },
],
onDataRetrieve: (data) => {
const { store } = await getAdditionalData(id);
return {
...data,
_store: store,
};
},
},
}
```
3. Specify the type of your custom data.
| Parameter | Type | Required | Description |
| --------- | ------ | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `type` | String |  | Determines how the custom data value should look and behave. Possible values: **text**, **icon**, **link**, **button**. If not specified, it defaults to **text**. |
### Tab: Text
**\`text\` data type**
```javascript
{
details: {
fields: [
{ key: '_store' },
],
onDataRetrieve: (data) => {
return {
...data,
_store: {
type: 'text',
value: 'New York',
config: {
className: 'my-class my-class--variant',
},
},
};
},
},
}
```
### Tab: Icon
**\`icon\` data type**
```javascript
{
details: {
fields: [
{ key: '_store' },
],
onDataRetrieve: (data) => {
return {
...data,
_store: {
type: 'icon',
value: 'New York',
config: {
src: '',
alt: '',
className: 'my-class my-class--variant',
},
},
};
},
},
}
```
### Tab: Link
The target should accept both `_self` and `_blank`. The default option is `_blank`.
**\`link\` data type**
```javascript
{
details: {
fields: [
{ key: '_store' },
],
onDataRetrieve: (data) => {
return {
...data,
_store: {
type: 'link',
value: 'New York',
config: {
href: '',
target: '_self',
className: 'my-class my-class--variant',
},
},
};
},
},
}
```
### Tab: Button
**\`button\` data type**
```javascript
{
details: {
fields: [
{ key: '_store' },
],
onDataRetrieve: (data) => {
return {
...data,
_store: {
type: 'button',
value: 'New York',
config: {
action: () => {},
className: 'my-class my-class--variant',
},
},
};
},
},
}
```
Here is an example `dataCustomization` object:
### Tab: Disputes Overview component
**Example \`dataCustomization\` object**
```javascript
{
list: {
fields: [{
key: 'disputeReason',
visibility: 'hidden'
},
{
key: 'reason',
visibility: 'hidden'
},
{
key: '_summary'
},
{
key: '_sendEmail'
},
{
key: 'disputedAmount',
align: 'left'
},
],
onDataRetrieve: async data =>
data.map(dispute => ({
...dispute,
_summary: {
type: 'link',
value: 'Summary',
config: {
href: 'https://www.adyen.com/'
},
},
_sendEmail: {
type: 'button',
value: 'Send email',
config: {
action: () => {
/* client action */ }
},
},
})),
},
details: {
fields: [{
key: 'id',
visibility: 'hidden'
},
{
key: '_store'
},
{
key: '_product'
},
{
key: '_summary'
},
{
key: '_sendEmail'
},
],
onDataRetrieve: async data => ({
...data,
_store: 'Sydney',
_product: 'Coffee',
_summary: {
type: 'link',
value: 'Summary',
config: {
href: 'https://www.adyen.com/'
},
},
_sendEmail: {
type: 'button',
value: 'Send email',
config: {
action: () => {
/* client action */ }
},
},
}),
},
};
```
### Tab: Dispute Management component
**Example \`dataCustomization\` object**
```javascript
{
dataCustomization: {
details: {
fields: [{ key: 'account', visibility: 'hidden' }, { key: '_store' }],
onDataRetrieve: async (dispute) => {
const { store } = await getAdditionalData(id);
return {
...data,
_store: store
};
}
}
}
}
```
3) Make sure to include translations for your custom fields in the library initializer:
* If you are not localizing components, add the custom field translations for `en_US`.
* If you are localizing components, also include the appropriate custom field translations for all supported locales.
**\`translations\` object**
```javascript
const core = await AdyenPlatformExperience({
translations: {
en_US: {
_store: 'Store'
},
es_ES: {
_store: 'Tienda'
},
}
});
```
## Supported languages
You can set one of the following languages to localize any of the Platform Experience components.
| Language | Locale code | Locale file |
| --------------- | ----------- | ----------- |
| Danish | **da-DK** | **da\_DK** |
| Dutch | **nl-NL** | **nl\_NL** |
| English | **en-US** | **en\_US** |
| Finnish | **fi-FI** | **fi\_FI** |
| French | **fr-FR** | **fr\_FR** |
| German | **de-DE** | **de\_DE** |
| Italian | **it-IT** | **it\_IT** |
| Norwegian | **no-NO** | **no\_NO** |
| Portuguese (BR) | **pt-BR** | **pt\_BR** |
| Spanish | **es-ES** | **es\_ES** |
| Swedish | **sv-SE** | **sv\_SE** |
## See also
* [Component libraries](/platforms/components-overview)