Case Report Specification (ACM)

The Case Report (formerly known as Downloadable Dispute Report or DDR) provides you with a regular operational report of all chargebacks made against your PayPal account. The DDR is intended to provide you with an operational view of what chargebacks have been made against you and to understand the context of money movement actions reported in the Settlement Report (STL) and the Transaction Detail Report (TDR).

On this page

• Know before you begin
• Chargeback use cases
• Distribution and access
• Report structure
• Sample report
• Representment rejection reason field values
• Representment evidence field values
• SNAD filing reason codes
• See also

Know before you begin

Chargebacks follow a specific process within the PayPal system, and the DDR is meant to provide you with an actionable and operational view into that process. In general terms, all PayPal chargebacks follow the following steps:

During this process, the DDR provides you with reasoning and transaction details that helps you to understand why actions are being taken (for example, why a transaction is being reversed based on an item not received chargeback) and what responses are possible (such as providing shipping information).

PayPal and other dispute processing

The DDR is designed to provide you with a regular view into the changes within your dispute and claim activity that might effect your daily support operations, your financial accounting, and your transactional history.

The DDR provides you with enough basic information about a PayPal chargeback so that you can take the appropriate business actions to resolve the customer concern.

PayPal assumes that you have some experience with processing customer claims and the PayPal DDR provides data to be used within an existing complaint/dispute/claim processing flow. However, the PayPal flow may differ from your existing flow and for this reason, you should review the following process flow diagrams to account for any adjustments you may need to make to your system.

Chargeback status

The DDR report lists all chargeback activities and their status. All dispute types are treated as chargebacks and have one of the following status values:

• S1 - Chargeback Notice
• S2 - Representment Received
• S3 - Representment Rejected
• S4 - Chargeback Cancelled (Reversal)
• S5 - Adjustment notice (Correction)
• S6 - Seller Won

Partial chargebacks and representments do not have a unique status code, but can be determined by comparing the gross transaction amount with the dispute amount. Any dispute amount less than the transaction amount constitutes a partial.

Chargeback reporting flow overview

The DDR, together with the STL and TDR, provides a comprehensive view of chargeback processing.

In the standard process, the claim made against the merchant initiates the chargeback process. After the claim, the following will occur:

1. PayPal will process the claim and either debit or credit the merchant account for the net amount of the claim (the original transaction amount minus the fee for the original transaction amount).
2. PayPal will report the claim to the merchant.
3. No further action is required by either party, but the merchant has 10 days to reply to the claim via the representment interface agreed to by PayPal and the merchant.
4. PayPal will process the representment and either debit or credit the merchant for the reversed amount of the claim action. For example, if the claim was processed as a debit, PayPal will provisionally credit the account for the net amount of the claim.
5. PayPal will report the representment to the merchant.
6. PayPal will evaluate the representment.
7. If PayPal accepts the representment, no further action is required by either party.
8. If PayPal rejects the representment, PayPal will process a representment rejection and either debit or credit the merchant account for the net amount of the claim.
9. PayPal will report the representment rejection.
10. No further action is required by either the merchant or PayPal but the merchant has 10 days to reply to the representment rejection via the representment interface agreed to by PayPal and the merchant.
11. Steps 4 - 9 will be followed for the second representment. No further representment will be allowed after this point.

Chargeback use cases

This section presents the following chargeback use cases and associated reporting flows:

• Use case 1 - chargeback
• Use case 2 - chargeback representment
• Use case 3 - chargeback represented and rejected
• Use case 4 - second chargeback received against same transaction (different reason)
• Use case 5 - chargeback cancellation
• Use case 6 - other chargeback scenarios
• Use case 7 - chargeback adjustment (correction)

Use case 1 - chargeback

The standard chargeback use case has the following three sub-cases:

• Use case 1.0 - standard chargeback
• Use case 1.1 - partial chargeback
• Use case 1.2 - credit chargeback

Use case 1.0 - standard chargeback

The following example illustrates the reporting for this use case:

NOTE: Merchant Cash Activity represents the cash activity to the merchant. This is activity from the partner to the merchant. Partner Cash Activity represents the cash activity to the partner. This is the activity from PayPal to the partner.

Operational actions

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. If no representment response is received, no further activity is reported in the STL or DDR.

Use case 1.1 Partial Chargeback

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds for the partial amount are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106. Partial chargebacks result in a partial fee reversal.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
     • Chargeback amount in DDR is the partial amount.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. If no representment response is received, no further activity is reported in the STL or DDR.

Use case 1.2 Credit Chargeback

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are returned to the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
     • The chargeback event is logged as credit money movement.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. If no representment response is received, no further activity is reported in the STL or DDR.

Use case 2 - chargeback representment

The standard chargeback use case has the following three sub-cases:

• Use case 2.0 - chargeback representment
• Use case 2.1 - partial Chargeback representment
• Use case 2.2 - partial representment of chargeback

Use case 2.0 chargeback representment

The following example illustrates the reporting for this use case:

Operational actions

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The partner’s merchant replies through the partner, who passes the response to PayPal within 12 calendar days.

4. A PayPal agent reviews the case to determine if the representment is accepted or not. If the support provided in the representment is sufficient, no further activity is reported in the STL or DDR.

Use case 2.1 - partial chargeback representment

The following example illustrates the reporting for this use case:

Operational actions

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds for the partial amount are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106. Partial chargebacks result in a partial fee reversal.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The partner’s merchant replies through the partner, who passes the response to PayPal within 12 calendar days.

4. A PayPal agent reviews the case to determine if the representment is accepted or not. If the support provided in the representment is sufficient, no further activity is reported in the STL or DDR.

Use case 2.2 partial representment of chargeback

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds for the partial amount are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106. Partial chargebacks result in a partial fee reversal.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The partner’s merchant replies through the partner, who passes the response to PayPal within 12 calendar days.

4. A PayPal agent reviews the case to determine if the representment is accepted or not. If the support provided in the representment is sufficient, no further activity is reported in the STL or DDR.

Use case 3 - chargeback represented and rejected

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The partner’s merchant replies through the partner, who passes the response to PayPal within 12 calendar days.

4. A PayPal agent reviews the case to determine if the representment is accepted or not. If the support provided in the representment is sufficient, no further activity is reported in the STL or DDR.

5. If the support is insufficient, the representment is rejected.

   • The PayPal agent rejects the representment in the case:
     • The status in the DDR is set to S3.
     • Representment Reject debit is added to STL as T1207. No chargeback handling fee accompanies representment rejects.

Use case 4 - Second chargeback received against same transaction (different reason)

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The partner’s merchant replies through the partner, who passes the response to PayPal within 12 calendar days.

4. A PayPal agent reviews the case to determine if the representment is accepted or not. If the support provided in the representment is sufficient, no further activity is reported in the STL or DDR.

5. If a second chargeback is received for a different reason, a new case is created to reflect the new chargeback event.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201. Second chargebacks are not charged another chargeback handling fee.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR. The PayPal Case ID may or may not change in the DDR for second chargebacks.

Use case 5 - chargeback cancellation

• Use case 5.1 - chargeback cancellation prior to representment
• Use case 5.2 - chargeback cancellation after representment

Use case 5.1 - chargeback cancellation prior to representment

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The consumer cancels the chargeback while the case is awaiting a representment response from the partner.

   • The buyer logs into their PayPal account and cancels the case, or a PayPal agent cancels the case.
   • The PayPal case is closed and the status of the case in the DDR is set to S4.
   • A chargeback reversal credit is included in the STL as T1208. This credit is equal in value to the chargeback debit.

Use case 5.2 - chargeback cancellation after to representment

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The partner’s merchant replies through the partner, who passes the response to PayPal within 12 calendar days.

4. The consumer cancels the chargeback after the representment request is received from the partner.

   • The buyer logs into their PayPal account and cancels the case, or a PayPal agent cancels the case.
   • The credit has already been processed due to the representment received.

Use case 6 - other chargeback scenarios

• Use case 6.1 - chargeback is represented out of timeframe (good faith)
• Use case 6.2 - chargeback is represented and then rejected and 2nd representment received

Use case 6.1 - chargeback is represented out of timeframe (good faith)

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The partner’s merchant replies through the partner, who passes the response to PayPal after 12 calendar days.

4. A PayPal agent reviews the case to determine if the representment is accepted or not. If the support provided in the representment is sufficient, no further activity is reported in the STL or DDR.

5. If the support is insufficient, the representment is rejected.

   • The PayPal agent rejects the representment in the case:
     • The status in the DDR is set to S3.
     • Representment Reject debit is added to STL as T1207.

Use case 6.2 - chargeback is represented and then rejected and 2nd representment received

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The partner’s merchant replies through the partner, who passes the response to PayPal after 12 calendar days.

4. A PayPal agent reviews the case to determine if the representment is accepted or not. If the support provided in the representment is sufficient, no further activity is reported in the STL or DDR.

5. If the support is insufficient, the representment is rejected.

   • The PayPal agent rejects the representment in the case:
     • The status in the DDR is set to S3.
     • Representment Reject debit is added to STL as T1207.

6. Partner provides a 2nd representment with additional evidence.

   • PayPal agent confirms receipt of the fax within 24 hours and triggers the system to provide the representment received notice.
     • The status of the claim in set to S2 in the DDR.
     • Provisional credit for the representment is indicated in the STL as T1202. This credit is equal in value to the chargeback debit.

7. If the support is insufficient or PayPal is unable to resolve the dispute with the buyer or issuing back, the representment is rejected.

   • The PayPal agent rejects the representment in the case:
     • The status in the DDR is set to S3.
     • Representment Reject debit is added to STL as T1207.

Use case 7 - chargeback adjustment (correction)

• Use case 7.1 - incorrect debit amount sent (S1)
• Use case 7.2 - incorrect representment amount sent (S2)

Use case 7.1 - incorrect debit amount sent (S1)

This use case includes chargeback adjustments such as incorrect debit or credit amount sent and incorrect reason code provided. The following use case is for incorrect debit (S1) amount sent.

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. PayPal determines that there was an error in the chargeback processed during the time while the case is waiting a representment response from the partner’s merchant.

   • The PayPal agent updates the case and a chargeback adjustment notice is sent in the DDR with status code S5.
   • A chargeback adjustment credit is sent in the STL report with TCode T1208. This credit is equal in value to the chargeback debit.
   • A chargeback handling fee credit is sent in the STL report with TCode T0106.

4. The PayPal agent reissues the chargeback with corrected data.

   • Funds are recovered from the merchant’s PayPal account. The chargeback debit appears in the STL as T1201.
   • A chargeback handling fee debit is sent in the STL report with TCode T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
     • The chargeback event is logged as credit money movement
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

Use case 7.2 - incorrect representment amount sent (S2)

This use case includes chargeback adjustments such as incorrect debit or credit amount sent and incorrect reason code provided. The following use case is for incorrect representment amount sent (S2).

The following example illustrates the reporting for this use case:

Operational actions

The following are the operational steps for this use case:

1. Buyer disputes the transaction either through their issuing bank or directly with PayPal.

2. A case is created in the PayPal system.

   • Funds are recovered from the merchant’s PayPal account.
     • The chargeback debit appears in the STL as T1201.
     • The chargeback fee debit appears in the STL as T0106.
   • A new chargeback notice is created.
     • The status of the claim is set to S1 in the DDR.
   • The 12 calendar day response time period begins from the dispute filing date in the DDR.

3. The partner’s merchant replies through the partner, who passes the response to PayPal within 12 calendar days.

4. A PayPal agent reviews the case to determine if the representment is accepted or not. If the support provided in the representment is sufficient, no further activity is reported in the STL or DDR.

5. PayPal determines that there was an error in the representment amount processed after the representment response is received from the partner’s merchant.

   • The PayPal agent updates the case and a chargeback adjustment notice is sent in the DDR with status code S5.
   • A chargeback adjustment debit is sent in the STL report with TCode T1208. This debit is equal in value to the chargeback credit.

6. The PayPal agent reissues the representment with corrected data.

   • Funds are credited to the merchant’s PayPal account. The chargeback representment appears in the STL as T1202.

Distribution and access

The DDR is available via the Secure FTP PayPal Reporting Server (disputes.paypal.com), which requires a separate user account for access to the DDR. A user account that is enabled for the DDR is also enabled to create user accounts for the Secure Drop-Box. To ensure data security, DDR users must generate their own user accounts for the Secure Drop-Box.

The following steps describe how to set up and access the DDR using the Secure FTP PayPal Reporting Server:

1. Contact your PayPal Account Manager to obtain access to the Secure FTP PayPal Reporting Server. Once granted, you will receive an email indicating that Secure FTP PayPal Reporting Server access has been granted.

2. Create a Secure FTP PayPal Reporting Server user account. Log in to PayPal (www.paypal.com) and create a Secure PayPal Reporting FTP Server username and password. Passwords for accessing the Secure FTP PayPal Reporting Server cannot be reset by PayPal. To obtain a new password, you must create a new Secure FTP PayPal Reporting Server user account.

3. Grant access to third-party users. You must explicitly grant access to third-parties by contacting their PayPal Account Manager to supply the third-parties’ PayPal login username and the type of permission: reporting access (read). The third-party is then notified by email that access to the business partner’s Secure FTP PayPal Reporting Server has been granted.

4. Access the Secure FTP PayPal Reporting Server programmatically using an FTP client. The hostname of the Secure FTP PayPal Reporting Server is reports.paypal.com. A user account on the Secure FTP PayPal Reporting Server has this directory structure: /disputes/outgoing

Schedule

The DDR is generated and delivered by PayPal on a regular (24 hour) basis. With the initial release of the DDR, the DDR is generated and distributed by 12 PM (noon) daily in the leading timezone of the reporting window.

Data format

You can receive the DDR in either comma separated value (csv) or tab delimited values format. Contact your PayPal Account Manager to set the data format for this report.

Character encoding: UTF-8

The report’s character encoding is UTF-8 (8-bit UCS/Unicode Transformation Format).

Report filename

The file naming convention depends on whether or not you're using Multiple Account Management.

Single account report

The filename of the DDR for a single account follows this naming convention: DDR-yyyymmdd.totalFiles.version.format:

Multiple account report

When using Multiple Account Management, the filename of the report follows this naming convention: DDR-yyyymmdd.reportingWindow.sequenceNumber.totalFiles.version.format

Data retention

The DDR is available via the Secure FTP PayPal Reporting Server for 45 days after the date of its delivery.

New or revised versions

In the future, PayPal will support multiple versions of the DDR. PayPal will notify you regarding the creation of any new version as well as any deprecation of older versions of the report.

If you wish to take advantage of a new version, you can receive two versions of the same report concurrently in order to test and integrate the new version. You can also receive non-consecutive versions of the same report concurrently in order to test and integrate the new version. Contact your PayPal Account Manager to enable different versions and request any changes in report distribution.

Notifications

PayPal operationally monitors the generation and delivery of the DDR on a 24/7 365 basis. PayPal maintains two different user contact points for report notifications:

• A business contact point for all notifications related to data integrity, data delivery, and new reporting features
• A technical contact for all notifications related to data integrity, data delivery, system outages, system updates, and new features. PayPal will notify you of the following events related to reporting.
• Delays in report delivery
• Errors in report generation
• New version availability
• System outage
• System update/maintenance(pre-announcement)
• New reporting feature releases

Contact your PayPal Account Manager to provide PayPal with the appropriate notification email alias. PayPal strongly recommends that you create a distribution list or email alias that allows multiple parties to receive communication about the DDR.

Report structure

The report can be delivered as either a comma-separated values or tab-delimited file. This section describes the structure of the data file.

A report file can contain a maximum of 100,000 records. If the report contains more than 100,000 records, the report is split across multiple files. The report is also organized by section, where each section represents a single PayPal account. If you are not using PayPal Multiple Account Management, the report contains only a single section.

Report files

A report file with less than 100,000 records (a single file) with only one section is organized as follows:

Report Header (RH)
File Header (FH)
Section Header (SH)
Column Header (CH)
Row Data (SB)
...
Row Data (SB)
Section Footer (SF)
Section Record Count (SC)
Report Footer (RF)
Report Record Count (RC)
File Footer (FF)

For report files that are split over multiple files, only the first file has a report header record and only the last file has a report footer and a report record count record. A report with two sections split over two files might be organized as follows:

If the report is split over multiple files, only the last file contains the report footer and report record count records.

Report row types

Each row of the report consists of a two letter row type, followed by the details specific to that row type. The following table lists the valid row types, along with the sections that describe the data for that row type.

Report header data

Report header data exists in one row with each element being separated by the file delimiter. All report fields are non-blank unless otherwise noted.

Report footer data

Report footer data exists in one row with each element being separated by the file delimiter. All report fields are non-blank unless otherwise noted.

Report record count data

File header data

Note: Each file in the report has a file header and a file footer, even if the number of files in the report is one.

File header data exists in one row with each element being separated by the file delimiter. All report fields are non-blank unless otherwise noted.

File footer data

File footer data exists in one row with each element being separated by the file delimiter. All report fields are non-blank unless otherwise noted.

Section header data

Note: If you are not using Multiple Account Management, the report contains only one section.

All section header data exists in one row with each element being separated by the file delimiter. All report fields are non-blank unless otherwise noted.

Section body data

Body data exists in one row with each element being separated by the file delimiter. All report fields are non-blank unless otherwise noted.

Before any rows of body data in the report, a column header row lists the name of each of the fields in each body data row. The column header column starts with CH, followed by the Column Name for each body data field (except for the "column type" field). For example:

"Column Type","Dispute Type","Claimant Name","Claimant Email
Address","Original Transaction ID","Original Transaction Gross Amount
CR/DR","Original Gross Transaction Amount","Original Transaction Gross
Amount Currency","Original Fee Amount CR/DR","Original Fee
Amount","Original Fee Amount Currency","Original Transaction Date","Dispute
Transaction ID","Disputed Gross Amount CR/DR","Disputed Gross
Amount","Disputed Gross Amount Currency","Disputed Fee Amount
CR/DR","Disputed Fee Amount","Disputed Fee Amount Currency","Dispute
Reason","Dispute Filing Date","Dispute Status","Dispute Case
ID","Representment Rejection Reason","Original Transaction Invoice
ID","Representment Evidence","Buyer Dispute Amount","Buyer Dispute Amount
Currency","Buyer Comments For Transactions","Sequence Number","Item
ID","Item Description","Item Dispute Reason","Item Buyer Dispute
Amount","Item Buyer Dispute Amount Currency","Filing Reasons","Filing
Notes""Store ID","Credit Card Chargeback Reason Code"

Section footer data

Section footer data exists in one row with each element being separated by the file delimiter. All report fields are non-blank unless otherwise noted.

Section record count data

Section record count data exists in one row with each element being separated by the file delimiter. All report fields are non-blank unless otherwise noted.

Sample report

The following is a sample of a DDR Report:

"RH",,"","T5ZEY39GC47WW",006,
"FH",01
"SH",,,"T5ZEY39GC47WW",""
"CH","Dispute Type","Claimant Name","Claimant Email Address","Original
Transaction ID","Original Gross Debit or Credit","Original Gross
Amount","Original Gross Currency","Original Fee Debit or Credit","Original
Fee Amount","Original Fee Currency","Original Transaction Date","Dispute
Transaction ID","Disputed Gross Debit or Credit","Disputed Gross
Amount","Disputed Gross Currency","Disputed Fee Debit or Credit","Disputed
Fee Amount","Disputed Fee Currency","Dispute Reason","Dispute Filing
Date","Dispute Status","Dispute CaseID","Representment Rejection
Reason","Original Transaction Invoice ID","Representment Evidence","Buyer
Dispute Amount","Buyer Dispute Amount Currency","Buyer Comments For
Transactions","Sequence Number","Item ID","Item Description","Item Dispute
Reason","Item Buyer Dispute Amount","Item Buyer Dispute Amount
Currency","Filing Reasons","Filing Notes","Store ID","Credit Card
Chargeback Reason Code"
"SC",0
"SF",0
"RC",0
"RF",0
"FF",0

Representment rejection reason field values

The folling are all the allowable values for the Representment rejection reason field of the DDR section body:

Representment evidence field values

The folling lists all allowable values for the Representment evidence field of the DDR section body:

SNAD filing reason codes

The following lists all SNAD codes for the Filing reasons field of the DDR section body:

See Also

• PayPal supported currencies
• T-codes