Case Report Specification (ACM)

DocsCurrentLast updated: October 13th 2021, @ 11:38:40 am


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

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:

StepDescription
1. First ChargebackA claim is made against a previous PayPal transaction and that transaction is reversed until you can provide information to prove the validity of the original transaction.
2. RepresentmentYou provide information to prove the validity of the original transaction and the error of the claim. PayPal reverts the original transaction to its original state (reverses the reversal).
3. Second ChargebackThe information provided in the representment does not effectively prove the validity of the original transaction and the original transaction is again reversed.
4. Second RepresentmentYou provide further information to prove the validity of the original transaction and the error of the claim. PayPal reverts the original transaction to its original state (reverses the reversal).

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.

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($50)$1.45
Chargeback processedTDR, STLT1201($50)$1.45($48.55)($48.55)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT11XX($100)$3.20($96.80)($96.80)
Chargeback initiatedDDRS1$100($3.20)
Chargeback processedTDR, STLT1201$100($3.20)$96.80$96.80
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback represented$100
Chargeback representment receivedDDRS2$100($3.20)
Provisional credit processedTDR, STLT1202$100($3.20)$96.80
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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($50)$1.45
Chargeback processedTDR, STLT1201($50)$1.45($48.55)($48.55)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback represented$50
Chargeback representment receivedDDRS2$50($1.45)
Provisional credit processedTDR, STLT1202$50($1.45)$48.55
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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback represented$50
Chargeback representment receivedDDRS2$50($1.45)
Provisional credit processedTDR, STLT1202$50($1.45)$48.55
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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback represented$100
Chargeback representment receivedDDRS2$100($3.20)
Provisional credit processedTDR, STLT1202$100($3.20)$96.80
Representment rejectedDDRS3($100)$3.20
Rejection processedTDR, STLT1207($100)$2($96.80)($96.80)

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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($2)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback represented$100
Chargeback representment receivedDDRS2$100($3.20)
Provisional credit processedTDR, STLT1202$100($3.20)$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)

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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Consumer cancels chargebackN/A
Chargeback refundDDRS4$100($3.20)
Credit processedTDR, STLT1208$100($3.20)$96.80$96.80

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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback represented$100
Chargeback representment receivedDDRS2$100($3.20)
Provisional creditTDR, STLT1202$100($3.20)$96.80
Consumer cancels chargebackN/A
Chargeback refund not processedN/A
Provisional credit not processedN/A

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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback represented$100
Chargeback represented out of timeN/A
Chargeback representment resolvedDDRS2$100($3.20)
Provisional credit processedTDR, STLT1202($100)$3.20$96.80$96.80
Representment rejectedDDRS3($100)$3.20
Rejection processedTDR, STLT1207($100)$3.20($96.80)($96.80)

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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback represented$100
Chargeback represented receivedDDRS2$100($3.20)
Provisional credit processedTDR, STLT1202($100)$3.20$96.80$96.80
Representment rejectedDDRS3($100)$3.20
Rejection processedTDR, STLT1207($100)$3.20($96.80)($96.80)
Chargeback represented (2nd representment)$100
Chargeback represented receivedDDRS2$100($3.20)
Provisional credit processedTDR, STLT1202$100($3.20)$96.80

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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback adjustment neededN/A$100
Chargeback creditDDRS5$100($3.20)
Credit processedTDR, STLT1208$100($3.20)$96.80$96.80
Chargeback handling fee processedTDR, STLT0106$10$0$10$10
Chargeback reissuedDDRS1(10)$0.59
Chargeback processedTDR, STLT1202($10)$0.59($9.41)
Chargeback handling fee processedTDR, STLT0106$10$0$10$10

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:

ActivityReportsCodeGross txn amtFee amtMerchant cash activityPartner case activity
Original salesTDR, STLT00XX$100($3.20)$96.80$96.80
Chargeback initiatedDDRS1($100)$3.20
Chargeback processedTDR, STLT1201($100)$3.20($96.80)($96.80)
Chargeback handling fee processedTDR, STLT0106($10)$0($10)($10)
Chargeback representedN/A$100
Chargeback representment receivedDDRS2$100($3.20)
Provisional credit processedTDR, STLT1202$10($0.59)$9.41
Chargeback adjustment neededN/A
Chargeback debitDDRS5($10)$0.59
Debit processedTDR, STLT1208($10)$0.59($9.41)($9.41)
Chargeback representment receivedDDRS2$100($3.20)
Provisional credit processedTDR, STLT1202$100($3.20)$96.80

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:

Naming conventionDescription
DDRAn abbreviation for "Downloadable Dispute Report"
yyyymmddThe date on the data in the report. This date stamp represents the latest, or ending date, of the data.
totalFilesThe total number of files of the report for this date. The number of files is always two digits and zero-padded. For example, for 2 total files, totalFiles is 02.
versionThe version of the report. Three characters, right-justified and zero-filled.
formatA .csv (comma-separated value file) or a .tab (a tab-delimited-field file)

Multiple account report

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

Naming conventionDescription
DDRAn abbreviation for "Downloadable Dispute Report"
yyyymmddThe date on the data in the report. This date stamp represents the latest, or ending date, of the data.
reportingWindowThe window of time when the report was generated, as follows:
A: America/New York to America/Los Angeles
H: America/Los Angeles to Asia/Hong Kong
R: Asia/Hong Kong to Europe/London
X: Europe/London to America/New York
sequenceNumberThe sequence number of this file. Two characters, right-justified and zero- filled. The sequence number begins with 01 and continues until all parts are recorded in files. The sequence number is always present in the report file name even if there is only one file.
totalFilesThe total number of files of the report for this date. The number of files is always two digits and zero-padded. For example, for 2 total files, totalFiles is 02.
versionThe version of the report. Three characters, right-justified and zero-filled.
formatA .csv (comma-separated value file) or a .tab (a tab-delimited-field file)

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:

File 1File 2
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)
Section Header (SH)
Column Header (CH)
Row Data (SB)
...
File Footer (FF)
File Header (FH)
Row Data (SB)
...
Row Data (SB)
Section Footer (SF)
Section Record Count (SC)
Report Footer (RF)
Report Record Count (RC)
File Footer (FF)

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.

CodeDescriptionSection
RHReport headerReport header data
RFReport footerReport footer data
RCReport record countReport record count data
FHFile headerFile header data
FFFile footerFile footer data
SHSection headerSection header data
SBRow dataSection body data
CHColumn headerSection body data
SFSection footerSection footer data
SCSection record countSection record count data

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.

PositionColumn nameData typeData description
1Column typeType: LiteralRH
2Report generation dateType: date/timeThe date and time when the report file was generated, in the following format:
MM/DD/YYYY HH:MM:SS offset where
  • YYYY is the four-digit year
  • MM is the two-digit day of the month
  • DD is the two-digit day of the month
  • HH is the hour in 24-hour notation
  • MM is minutes
  • SS is seconds
  • offset is the five-character signed offset from GMT. For example, +800
3Reporting windowType: VarcharThe window of time when the report was generated, as follows:
  • X: GMT 00:00 to GMT -500
  • A: GMT -0500 to GMT -0800
  • H: GMT -0800 to GMT +0800
  • R: GMT +0800 to GMT 00:00
4Account IDType: VarcharAccount number receiving the report (Payer ID - encrypted hash of PayPal account)
5Report versionType: VarcharThe version of the report

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.

PositionColumn nameData typeData description
1Column typeType: literalRF
2Row countType: numberThe number of body data rows in the report (used for reconciliation). Note that the report may span multiple files.

Report record count data

PositionColumn nameData typeData description
1Column typeType: literalRC
2Row countType: numberThe number of body data rows in the report (used for reconciliation). Note that the report may span multiple files.

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.

PositionColumn nameData typeData description
1Column typeType: literalFH
2File countType: numberThe sequence number of the file in the report (used for reconciliation).

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.

PositionColumn nameData typeData description
1Column typeType: literalFF
2Row countType: numberThe number of body data rows in the file (used for reconciliation).

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.

PositionColumn nameData typeData description
1Column typeType: LiteralSH
2Reporting period start dateType: date/timeThe date/time when the report began. The data is in the following format:
MM/DD/YYYY HH:MM:SS offset where
  • YYYY is the four-digit year
  • MM is the two-digit day of the month
  • DD is the two-digit day of the month
  • HH is the hour in 24-hour notation
  • MM is minutes
  • SS is seconds
  • offset is the five-character signed offset from GMT. For example, +800
3Reporting period end dateThe date/time when the report ended.The data is in for following format:
MM/DD/YYYY HH:MM:SS offset where
  • YYYY is the four-digit year
  • MM is the two-digit day of the month
  • DD is the two-digit day of the month
  • HH is the hour in 24-hour notation
  • MM is minutes
  • SS is seconds
  • offset is the five-character signed offset from GMT. For example, +800
4Account IDType: VarcharAccount number generated by PayPal
5Partner account IDType: Varchar
  • Type: Varchar
  • Blanks: Yes
  • Max length: 127 characters
The partner’s account ID for the merchant. This is the value passed by the partner in the \u003CPartnerMerchantExternalID\u003E tag of the multiple account management batch input file.

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"
PositionColumn nameData typeData description
1Column typeType: LiteralSB
2Dispute type
  • Type: Text string
  • Unique: No
  • Blanks: No
  • Max length: 12 characters
The type of dispute made against the transaction is always a chargeback.
3Claimant name
  • Type: Text string
  • Unique: Yes
  • Blanks: No
  • Max length: 128 characters
Name of the claimant as it appears in the original PayPal payment being disputed. The value is acquired from the original transaction. If the claimant is a business, this field contains the business name and not the First Name/Last Name combination used for individuals.

For transactions with disputes associated with them, claimant information is displayed only in the Case Report. It is not included in the STL or the TDR.
4Claimant email address
  • Type: Varchar
  • Unique: Yes
  • Blanks: Yes
  • Max length: 127 characters
The PayPal e-mail address of the consumer as it appeared in the disputed transaction. The e-mail address is also the account contact point between buyers and sellers within the PayPal system. If the dispute type is PayPal Fraud Investigation, the claimant e-mail address is e-mail address from the original transaction even though the claim was most likely initiated by PayPal.
5Original transaction ID
  • Type: Varchar
  • Unique: Yes
  • Blanks: Yes
  • Max length: 24 characters
The transaction ID generated at the time of the money moving event. This unique, 17 character ID is generated by PayPal and cannot be altered.
6Original gross debit or credit
  • Type: Text string
  • Unique: No
  • Blanks: No
  • Max length: 2 characters
Direction of money movement of the original transaction amount. Valid values are: CR and DR.
7Original gross amount
  • Type: Currency/money
  • Unique: No
  • Blanks: No
  • Max length: 26 characters
The gross amount of the original transaction. The amount cannot contain decimal places, signage (+/-), or commas.
8Original gross currency
  • Type: Text string
  • Unique: No
  • Blanks: No
  • Max length: 3 characters
Currency of transaction.
9Original fee debit or credit
  • Type: Char
  • Unique: No
  • Blanks: Yes
  • Max length: 2 characters
Direction of money movement of the original transaction amount. Valid values are: CR and DR.
10Original fee amount
  • Type: Number
  • Unique: No
  • Blanks: Yes
  • Max length: 26 characters
The fee amount of the original transaction. The amount cannot contain decimal places, signage (+/-), or commas.
11Original fee currency
  • Type: Char
  • Unique: No
  • Blanks: Yes
  • Max length: 3 characters
Currency of transaction.
12Original transaction date
  • Type: Date/time
  • Unique: No
  • Blanks: Yes
  • Max length: 25 characters
Date and time the transaction was completed, in the following format:
YYYYMMDD HH:MM:SS offset where
  • YYYY is the four-digit year
  • MM is the two-digit day of the month
  • DD is the two-digit day of the month
  • HH is the hour in 24-hour notation
  • MM is minutes
  • SS is seconds
  • offset is the five-character signed offset from GMT. For example, +800
13Dispute transaction fee
  • Type: Text string
  • Unique: Yes
  • Blanks: Yes
  • Max length: 19 characters
The transaction ID generated at the time of the money moving event for the chargeback event. This unique, 19-character ID is generated by PayPal and cannot be altered.

For Advanced Chargeback Management, the No Temporary Hold on Disputed Funds flag indicates that money movement should occur only when an incident is resolved. If it set to On, then this field will be blank in the intermediate states.
14Disputed gross debit or credit
  • Type: Text string
  • Unique: No
  • Blanks: Yes
  • Max length: 2 characters
Direction of money movement of the original transaction amount. Valid values are: CR and DR.

For Advanced Chargeback Management, the No Temporary Hold on Disputed Funds flag indicates that money movement should occur only when an incident is resolved. If it set to On, then this field will be blank in the intermediate states.
15Disputed gross amount
  • Type: Currency/money
  • Unique: No
  • Blanks: Yes
  • Max length: 26 characters
The amount of the chargeback reversal created in response to the chargeback request. The amount cannot contain decimal places, signage (+/-), or commas.

For Advanced Chargeback Management, the No Temporary Hold on Disputed Funds flag indicates that money movement should occur only when an incident is resolved. If it set to On, then this field will be blank in the intermediate states.
16Disputed gross currency
  • Type: Text string
  • Unique: No
  • Blanks: Yes
  • Max length: 3 characters
Currency of transaction.

For Advanced Chargeback Management, the No Temporary Hold on Disputed Funds flag indicates that money movement should occur only when an incident is resolved. If it set to On, then this field will be blank in the intermediate states.
17Disputed fee debit or credit
  • Type: Text string
  • Unique: No
  • Blanks: Yes
  • Max length: 2 characters
Direction of money movement of the original transaction amount. Valid values are: CR and DR.

For Advanced Chargeback Management, the No Temporary Hold on Disputed Funds flag indicates that money movement should occur only when an incident is resolved. If it set to On, then this field will be blank in the intermediate states.
18Disputed fee amount
  • Type: Currency/money
  • Unique: No
  • Blanks: Yes
  • Max length: 26 characters
The amount of the chargeback reversal created in response to the chargeback request. This is the inverse of the direction of the chargeback amount in most cases. The amount cannot contain decimal places, signage (+/), or commas.

For Advanced Chargeback Management, the No Temporary Hold on Disputed Funds flag indicates that money movement should occur only when an incident is resolved. If it set to On, then this field will be blank in the intermediate states.
19Disputed fee currency
  • Type: Text string
  • Unique: No
  • Blanks: Yes
  • Max length: 3 characters
Currency of transaction.

For Advanced Chargeback Management, the No Temporary Hold on Disputed Funds flag indicates that money movement should occur only when an incident is resolved. If it set to On, then this field will be blank in the intermediate states.
20Dispute reason
  • Type: Text string
  • Unique: No
  • Blanks: No
  • Max length: 2 characters
The codified reason for the dispute as provided by the claimant at the time of filing. The field will always contain one value from the following complete list of valid values:
  • R1 - Non-receipt of merchandise
  • R2 - Not as described merchandise
  • R3 - Unauthorized transaction
  • R4 - Duplicate transaction posted
  • R5 - Processing error
  • R6 - Merchant issues
  • R7 - Fulfillment issues
21Dispute filing date
  • Type: Date/time
  • Unique: No
  • Blanks: Yes
  • Max length: 25 characters
Date and time the claim was filed by the claimant, in the following format:
YYYYMMDD HH:MM:SS offset where
  • YYYY is the four-digit year
  • MM is the two-digit day of the month
  • DD is the two-digit day of the month
  • HH is the hour in 24-hour notation
  • MM is minutes
  • SS is seconds
  • offset is the five-character signed offset from GMT. For example, +800
22Dispute status
  • Type: Date/time
  • Unique: No
  • Blanks: Yes
  • Max length: 4 characters
The codified current status of the dispute. This field will always contain one value from the following list of values:
  • S1 - Waiting for merchant’s representment
  • S2 - Received representment
  • S3 - Rejected representment
  • S4 - Buyer cancelled dispute
  • S5 - Adjustment notice (correction)
  • S6 - Seller won


If there are multiple actions taken against a case in a single day, only the last action of the day will be reported. Multiple actions will not be reported.
23Dispute case ID
  • Type: Test string
  • Unique: Yes
  • Blanks: Yes
  • Max length: 32 characters
The unique case ID generated by PayPal. The case ID can be used to refer to a dispute when discussing your cases with PayPal service representatives. For example, CB-000-123-456-789.
24Representment rejection reason
  • Type: Test string
  • Unique: No
  • Blanks: No
  • Max length: 3 characters
The codified reason for a rejection of the representment. See the Representment rejection reason field values section for valid values.
25Original Transaction Invoice ID
  • Type: Test string
  • Unique: No
  • Blanks: Yes
  • Max length: 127 characters
Invoice ID set by the merchant with the original transaction. Uniqueness can be enforced by PayPal when the transaction is created. If an invoice ID was sent with the capture request, this value is reported here. However, if no invoice ID was sent with the capture request, the value of the invoice ID (if any) from the authorizing transaction is reported here.
26Representment evidence
  • Type: Test string
  • Unique: No
  • Blanks: Yes
  • Max length: 4000 characters
As part of the representment process, the type of proof the seller can submit for each case. Each proof is represented with a corresponding code. See the Representment evidence field values section for valid values. The evidences the seller submits are presented in the following format, `1
27Buyer Dispute Amount
  • Type: Text number
  • Unique: No
  • Blanks: Yes
  • Max length: 64 characters
Amount disputed by the buyer for this transaction. Once set, this can change during the life of the dispute transaction. The change occurs during claim type switching only. This information is same for all items in the dispute transaction.
28Buyer dispute amount currency
  • Type: Varchar
  • Unique: No
  • Blanks: Yes
  • Max length: 3 characters
Currency of the amount disputed by the buyer for this transaction. Once set, this does change during the life of the dispute transaction. This information is same for all items in the dispute transaction.
29Buyer Comments For Transactions
  • Type: Text varchar
  • Unique: No
  • Blanks: Yes
  • Max length: 2000 characters
Comments entered by the buyer during the dispute transaction creation. The buyer comments are at the transaction level and not item level. This does not change once the dispute transaction is created.
30Sequence number
  • Type: Text Number
  • Unique: No
  • Blanks: Yes
  • Max length: 64 characters
Sequence number of the item within the dispute transaction.
0 - there are no items
n - it is the nth item within the dispute transaction.
This does not change once the dispute transaction is created.
31Item ID
  • Type: Number
  • Unique: No
  • Blanks: Yes
  • Max length: 64 characters
All items that are part of the dispute transaction are created when the dispute is created. Items that are not in dispute will not be added into the dispute transaction. Available if seller passed this information through checkout, and if chargeback is filed through PayPal. This does not change once the dispute transaction is created. This information can be different for each item in the dispute transaction.
32Item description
  • Type: Varchar
  • Unique: No
  • Blanks: Yes
  • Max length: 4000 characters
Available if seller passed this information during checkout, and if chargeback is filed through PayPal. This does not change once the dispute transaction is created. This information can be different for each item in the dispute transaction.
33Item despute reason
  • Type: Varchar
  • Unique: No
  • Blanks: Yes
  • Max length: 2 characters
Dispute reason can change for an item during the course of state changes for the dispute transaction. This information can be different for each item in the dispute transaction:
  • R1 - Non-receipt of merchandise
  • R2 - Not as described merchandise
  • R3 - Unauthorized transaction
  • R4 - Duplicate transaction posted
  • R5 - Processing error
  • R6 - Merchant issues
  • R7 - Fulfillment issues
34Item buyer dispute amount
  • Type: Varchar
  • Unique: No
  • Blanks: Yes
  • Max length: 64 characters
Amount the buyer disputed for the item. This information can be different for each item in the dispute transaction. This does not change once the disputed transaction is crated. This information can be different for each item in the dispute transaction.
35Item buyer dispute amount currency
  • Type: Varchar
  • Unique: No
  • Blanks: Yes
  • Max length: 3 characters
Currency of the amount the buyer disputed. This does not change once the dispute transaction is created. This information can be different for each item in the dispute transaction.
36Filing reasons
  • Type: Number
  • Unique: No
  • Blanks: Yes
  • Max length: 4000 characters
Reason for filing the dispute. This cannot change once the value is set. This information is at the transaction level and is available only for SNAD (R2) dispute transactions. This information is set when the case goes into R2 for the first item. This information is same for all items in the dispute transaction. See the SNAD filing reason codes section for valid values.
37Filing notes
  • Type: Varchar
  • Unique: No
  • Blanks: Yes
  • Max length: 4000 characters
This is free form text about the Filing Reasons. This cannot change once the value is set. This is available only for SNAD (R2) related MIPS items. This information can be different for each item in the dispute transaction.
38Store ID
  • Type: Varchar
  • Unique: No
  • Blanks: Yes
  • Max length: 50 characters
The merchant’s identifier of the store where the purchase occurred.
39Credit card chargeback reason code
  • Type: Varchar
  • Unique: No
  • Blanks: Yes
  • Max length: 64 characters
Unique identifier which distinguishes the nature/reason of credit card chargeback reported. Each card issuer follows their own standards for defining reason type, code and its format.

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.

PositionColumn nameData typeData description
1Column typeType: literalSF
2Row countType: numberThe number of body data rows in the section (used for reconciliation)

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.

PositionColumn nameData typeData description
1Column typeType: literalSC
2Row countType: numberThe number of body data rows in the section (used for reconciliation)

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:

Reason codeCode description
100PayPal did not receive tracking information.
105PayPal did not receive verifiable tracking information.
115PayPal did not receive signed proof of delivery.
120Invalid proof of shipment provided.
200The consumer provided proof of return to merchant.
205The consumer provided proof of attempted return to merchant.
210The consumer cancelled service prior to billing.
215The merchant did not abide by their return policy.
300Support was insufficient to show the consumer authorized the transaction.
305The consumer maintains transaction was unauthorized.
400The merchant accepted multiple payments for a single purchase.
600Invalid proof of refund provided.
605Services were not provided to the consumer.
610Per the merchant response, the merchant accepted the chargeback liability.
615The transaction was not marked as SPP eligible.
620The item violates the PayPal User Agreement.
625The merchant surcharged the consumer.
630The merchandise or services did not match item description.
635PayPal did not receive a reply to a PayPal request for information within the required time period.

Representment evidence field values

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

Evidence typeDescriptionCode
Not representableSeller does not need to provide representment for this case.0
Proof of shipmentDocumentation or online verification from the shipping company showing the shipment status, the shipping date, the address to which the package was sent, and official acceptance from the shipping company.1
Proof of refundDocumentation that proves reimbursement to the buyer.2
Return addressSeller’s return address for contested items.3
OtherOther evidence that does not fall into any category.4
Proof of deliveryProof that the item was delivered to the recipient. It is generally in the form of an online tracking number. It shows the city, state, and zip to which the package was shipped, the date the package was delivered, and the delivery status.5
Proof of delivery with signature confirmationProof that the item was delivered to the recipient. It is generally in the form of an online tracking number. It shows the city, state, and zip to which the package was shipped, the date the package was delivered, and the delivery status. It requires a signature confirming that the package was received.6
Proof of authenticityProof that validates the authenticity of an item. For example, expert’s second opinion if the buyer claims the item is fake.7

SNAD filing reason codes

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

SNAD codesDescription
WAT_COMPLAINT_ISSUE_DIFFERENT_CATEGORYBuyer received an item that is different from what they ordered.
WAT_COMPLAINT_ISSUE_MISSING_QUANTITYBuyer received item with missing quantity of items. For example: They ordered 12 units but received 6.
WAT_COMPLAINT_ISSUE_MISSING_PARTSBuyer received an item that was missing parts that prevent the item from being used. For example: Missing computer processor.
WAT_COMPLAINT_ISSUE_INTERNALLY_DAMAGEDBuyer received an item that was internally damaged. For example: Computer does not power on or function properly.
WAT_COMPLAINT_ISSUE_RUINED_FOOD_PLANTSBuyer received items that were either ruined food or plants.
WAT_COMPLAINT_ISSUE_DIFFERENT_MODELBuyer received a wrong model of item purchased.
WAT_COMPLAINT_ISSUE_TIME_SENSITIVE_LATEBuyer purchased a time-sensitive item that arrived late. For example: concert ticket.
WAT_COMPLAINT_ISSUE_COLOR_DIFFERENCE_1Buyer received an item with a slight color difference.
WAT_COMPLAINT_ISSUE_COLOR_DIFFERENCE_2Buyer received an item with a significant color difference.
WAT_COMPLAINT_ISSUE_COLOR_DIFFERENCE_3Buyer received an item with an extreme color difference.
WAT_COMPLAINT_ISSUE_EXTERNALLY_DAMAGEDBuyer received an externally damaged item. For example: scratched, cracked, chipped, ripped, dented, or stained.
WAT_COMPLAINT_ISSUE_SUBSTITUTEBuyer received a less valuable substitute of the described item.
WAT_COMPLAINT_ISSUE_USEDBuyer received that was used when described as new.
WAT_COMPLAINT_ISSUE_DIFFERENT_DESIGN_PATTERNBuyer received an item with a different design as described.
WAT_COMPLAINT_ISSUE_DIFFERENT_MATERIALBuyer received an item of a different material.
WAT_COMPLAINT_ISSUE_COPY_OF_ORIGINALBuyer received a copy of the original item. For example: bootleg or pirated copy.
WAT_COMPLAINT_ISSUE_IMITATIONBuyer received an imitation of the original item. For example: counterfeit handbag, clothing, or watch.
WAT_COMPLAINT_ISSUE_SHIPPING_COSTBuyer has complaint with regards to the shipping cost of the item.
WAT_COMPLAINT_ISSUE_SALES_TAXBuyer has complaint regarding sales tax charges on the item.
WAT_COMPLAINT_ISSUE_DG_CONTENT_NOT_AS_DESCRIBEDBuyer received a digital goods item and was not satisfied with the content.
WAT_COMPLAINT_ISSUE_DG_RECEIVED_WRONG_ITEMBuyer received a digital goods item that was completely different from the original.
WAT_COMPLAINT_ISSUE_DG_TECHNICAL_ISSUESBuyer had technical issues during purchase of a digital good.
WAT_COMPLAINT_ISSUE_DG_OTHERBuyer had other issues during the purchase of a digital good.
WAT_COMPLAINT_ISSUE_REASON_CATEGORYBuyer received an item of different version than described.

See Also