case report specification (acm)€¦ · case report, version 6.0 preface this specification details...

Case Report Specification (ACM)

Version 6.0 for Advanced Chargeback Management (ACM)

Last updated: August 2012

Case Report Specification

Version 6.0

© 2012 PayPal, Inc. All rights reserved. PayPal is a registered trademark of PayPal, Inc. The PayPal logo is a trademark of PayPal, Inc. Other trademarks and brands are the property of their respective owners.The information in this document belongs to PayPal, Inc. It may not be used, reproduced or disclosed without the written approval of PayPal, Inc.Copyright © PayPal. All rights reserved. PayPal (Europe) S.à r.l. et Cie., S.C.A., Société en Commandite par Actions. Registered office: 22-24 Boulevard Royal, L-2449, Luxembourg, R.C.S. Luxembourg B 118 349.Consumer advisory: The PayPal™ payment service is regarded as a stored value facility under Singapore law. As such, it does not require the approval of the Monetary Authority of Singapore. You are advised to read the terms and conditions carefully.

Notice of non-liability:PayPal, Inc. is providing the information in this document to you “AS-IS” with all faults. PayPal, Inc. makes no warranties of any kind (whether express, implied or statutory) with respect to the information contained herein. PayPal, Inc. assumes no liability for damages (whether direct or indirect), caused by errors or omissions, or resulting from the use of this document or the information contained in this document or resulting from the application or use of the product or service described herein. PayPal, Inc. reserves the right to make changes to any information herein without further notice.PayPal Inc. does not guarantee that the features described in this document will be announced or made available to anyone in the future.

Case Report Specification, Ve

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Report Version Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Purpose of Report Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Frequency of Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Version Impact/Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Report / Report Version Deactivation/Deprecation . . . . . . . . . . . . . . . . . . . 10

Version Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Concurrent Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Related PayPal Public Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Related PayPal Limited Release Documentation . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 1 Case Report Overview . . . . . . . . . . . . . . . . . . . . 13

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chargebacks and the Case Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

PayPal and Other Dispute Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chargeback Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chargeback Reporting Flow Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chargeback Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Use Case 1 - Chargeback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Use Case 2 - Chargeback Representment . . . . . . . . . . . . . . . . . . . . . . . 18

Use Case 3 - Chargeback Represented and Rejected . . . . . . . . . . . . . . . . . 22

Use Case 4 - Second Chargeback Received Against Same Transaction (Different Reason)23

Use Case 5 - Chargeback Cancellation . . . . . . . . . . . . . . . . . . . . . . . . . 25

Use Case 6 - Other Chargeback Scenarios . . . . . . . . . . . . . . . . . . . . . . . 27

Use Case 7 - Chargeback Adjustment (Correction) . . . . . . . . . . . . . . . . . . . 30

Chapter 2 Case Report Technical Description . . . . . . . . . . . . . 35

Distribution and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

rsion 6.0 August 2012 3

Contents

4

Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Character Encoding: UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Report Filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Data Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

New or Revised Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Report Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Report Header Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Report Footer Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Report Record Count Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

File Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

File Header Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

File Footer Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Section Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Section Header Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Section Body Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Section Footer Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Section Record Count Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Appendix A DDR Sample File . . . . . . . . . . . . . . . . . . . . . . . 55

Appendix B Representment Rejection Reason Field Values . . . . . . . 57

Appendix C Representment Evidence Field Values . . . . . . . . . . . 59

Appendix D SNAD Filing Reason Codes . . . . . . . . . . . . . . . . . 61

Appendix E PayPal-Supported Currencies . . . . . . . . . . . . . . . . 63

PayPal-Supported Currencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

August 2012 Case Report Specification, Version 6.0

Case Report, Version 6.0

Preface

This specification details version 6.0 of Case Report Specification.

Revision History

Revision history for Case Report Specification.

TABLE P.1 Revision History

Date Version Description

August 2012 6.0 Updated data descriptions for the following:

Claimant Email Address

Dispute Case ID

Dispute Status

Filing Reasons

Representment Evidence

Original Fee Amount

Original Fee Currency

Original Fee Debit or Credit

Original Transaction ID

PrefaceRevision History

6

October 2011 6.0 Change the report name from Downloadable Dispute Report to Case Report.

Updated the report version to 6.0.

Added new sample report.

Added the following fields:

– 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

Added the following new dispute reasons:

– R6 - Merchant issues

– R7 - Fulfillment issues

Added new appendix for SNAD filing reasons.

July 2011 4.0.3 Added new chargeback status - S6 (page 14)

Changed “Blanks” from “No” to “Yes” for the following columns, thereby indicating that there might be no money movement associated with a change in dispute status (page 47):

– 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

Added new column - Representment Evidence (page 50)

Updated sample report - version 4.0 (page 55)

Added new appendix for Representment Evidence type values (page 59)



August 2012 Case Report, Version 6.0

Case R


February 2010 4.0.2 Added note about the following fields being blank if “No Temporary Hold on Disputed Funds” is set to “On” for Advanced Chargeback Management (page 47):

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

January 2010 4.0.1 Changed the Secure FTP Server directory location to ppdisputes/outgoing (page 35).

Changed the Secure FTP Server location to disputes.paypal.com (page 35).

August 2009 4.0.0 Changed versioning convention in this document. Now the document version will reflect the version of the report.

March 2009 3.1.2 Changed maximum characters for Dispute Case ID to 18 (page 49).

October 2008 3.1.1 Updated information about report retention time on the Secure FTP Server (page 37).

Changed the Secure FTP Server directory location to ppreports/outgoing (page 35).



eport, Version 6.0


8

February 2008 3.1.0 Modified the amounts in the use case examples:

– Use Case 1.0

– Use Case 1.1

– Use Case 1.2

– Use Case 2.0

– Use Case 2.1

– Use Case 2.2

– Use Case 3

– Use Case 4

– Use Case 5.1

– Use Case 5.2

– Use Case 6.1

– Use Case 7.1

– Use Case 7.2

In Use Case 3, noted that no chargeback handling fee accompanies representment rejects (see page 23).

In Use Case 4, noted that second chargebacks are not charged another chargeback handling fee, and the PayPal Case ID may or may not change for second chargebacks (see page 24).

Added Use Case 6.2 (see page 29) and changed Use Case 6 to Use Case 6.1 (see page 27).

November 2007 3.0.4 Corrected errors with codes for dispute reason (R1 and R2) (see page 49)

Noted that claimant information is not available in the STL or TDR reports (see page 45)

October 2007 3.0.3 Corrected error with codes for dispute reason (R3 and R4) (see page 49)

October 2007 3.0.2 Correct errors in the sample report (see Appendix A) Added chargeback handling fee to use case 7.1 (see

page 30) Added use case 7.2 (see page 32)

September 2007 3.0.1 Added status S5 (page 14 and page 49) Added Use Case 7 (page 30) Updated reporting window to remove GMT (page 37

and page 41) Added Partner Merchant ID to the section header

(page 44)




Case R

PrefaceReport Version Numbering

Document Version Number Format

Document version number are of the following format:

<release>.<code change revision>.<doc clarification revision>

Report Version Numbering

Purpose of Report Versioning

PayPal will periodically generate new versions of reports. New versions of reports can be released based one of the following business situations:

Modifications to the file format of an existing report

August 2007 3.0.0 Updated Overview chapter to reflect new chargeback process (page 13)

Updated delivery time of report to 12pm in leading time zone (page 36)

Updated section body of report to reflect new chargeback process (page 45)

Added new appendix of representment rejection codes (page 57)

March 2007 1.1.3 All consolidated reports are UTF-8 encoded (page 36). A file footer is present even if the report is only one file

(page 39 and page 42).

February 2007 1.1.2 Updated multiple account management details

December 2006 1.0.0 First release of Case Report Specification. Version 6.0

TABLE P.2 Version Number Format

Component Description

<release> Iterated when a new release of product function and feature is released to production. This version of the document will always match the current version of the report (see “Report Version Numbering.”

<code change revision> Iterated when the code within a specific release is changed (such as fixing a previously documented bug).

<doc clarification revision> Iterated when the documentation is changed with no corresponding code change (such as document clarifications)



eport, Version 6.0

PrefaceReport Version Numbering

10

Modifications to the quoting/context of data elements of an existing report

Modifications to the file naming convention of an existing report

Modifications to file encoding (UTF-8/UCS-2) of an existing report

Modifications columns location of an existing report

Dramatic modifications to data elements in an existing report, such as changing a text string to a single byte code

NOTE: New TCODES within an existing TCODE category range can be introduced without versioning.

Adding/Removing columns to an existing report

Modifications to the file location of an existing report on the report delivery server

Modifications to the file encryption of an existing report

Frequency of Versioning

PayPal will release new versions when the business need arises. In general, most new versions will be released concurrent to the regular PayPal product release, which occurs on a bi-monthly basis (check with PayPal Merchant Technical Services for the specific calendar of release dates). PayPal does reserve the right to periodically release new report versions asynchronous to the regular PayPal product release. Note that all releases are designed not to impact existing reports, report versions, and report users.

Version Impact/Integration

All new version releases are independent of existing report version generation. For example, the release of Report A Version 2 will not impact Report A version 3. Until specific notice is provided to merchants and/or partners, report users will not be required to upgrade to new report versions when new versions are released. Integration to new versions is voluntary. In many cases, PayPal will release documentation for new reports and report versions prior to their release to either the production environment or the beta sandbox environment.

Report / Report Version Deactivation/Deprecation

PayPal currently has a specific policy for regular report or report version deactivation or deprecation. PayPal will not deactivate or deprecate a specific version of a report without prior notice to the version's recipients. Additionally, PayPal will communicate a migration plan for the recipients of the report that is being deprecated to ensure business continuity on the part of the merchant and/or partner. This does not include deactivation of reports for an account due to account closure


Case R

PrefaceRelated PayPal Public Documentation

Version Naming

Each report document describes how version information related to each report is communicated via the report filename and/or header information. Report users should refer to the documentation for each specific report to understand how to differentiate between two versions of the same report.

Concurrent Versions

The PayPal system allows any individual account to receive two versions of the same report concurrently. For example, a user could receive both Report A Version 1 and Report A Version 2 on a daily basis. Concurrent Report Version distribution allows merchants and/or partners to upgrade to new Report Versions without impact to their existing Report integration and related business processes. Users do not have to subscribe to sequential versions concurrently and can subscribe to versions that are not in sequence. For example, a user can subscribe to Report A Version 1 and Report A version 5, effectively skipping Report A Versions 2, 3 & 4.

Related PayPal Public Documentation

PayPal’s public documentation on APIs, Website Payments Pro, Express Checkout, Website Payments Standard, and other PayPal products and features is accessible at the following location:

https://www.paypal.com/IntegrationCenter/ic_documentation.html

Related PayPal Limited Release Documentation

Other related specifications referred to in the text are available from your PayPal Account Manager.

eport, Version 6.0

https://www.paypal.com/IntegrationCenter/ic_documentation.html

PrefaceRelated PayPal Limited Release Documentation

12

1


Case Report Overview

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 and the Transaction Detail Report.

Audience

This version of the DDR is designed specifically for partners that are processing both PayPal payments and credit card payments for other payment networks.This report can only be enabled by PayPal and integration management. Additionally, because this report requires specific integration and set-up, this report must be activated in coordination with specific versions of the following reports:

Settlement Report

Transaction Detail Report

Chargebacks and the Case Report

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:

TABLE 1.1 Chargeback Process Flow

Step Description

1. First Chargeback A 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. Representment You 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 Chargeback The information provided in the Representment does not effectively prove the validity of the original transaction and the original transaction is again reversed.

August 2012 13

Case Report OverviewPayPal and Other Dispute Processing

1

14

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 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.

4. Second Representment You 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)

TABLE 1.1 Chargeback Process Flow

Step Description


Case Report OverviewChargeback Reporting Flow Overview

1

Case R

Chargeback Reporting Flow Overview

The DDR, together with the Settlement Report (STL) and Transaction Detail Report (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.

eport, Version 6.0 August 2012 15

Case Report OverviewChargeback Use Cases

1

16

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.

Activity Report(s) CodeGross Txn Amt Fee Amt

Merchant Cash Activity

Partner Cash Activity

Original Sales TDR, STL T00XX $100 ($3.20) $96.80 $96.80

Chargeback initiated DDR S1 ($100) $3.20

Chargeback processed TDR, STL T1201 ($100) $3.20 ($96.80) ($96.80)

Chargeback Handling Fee processed

TDR, STL T0106 ($10) $0 ($10) ($10)



1

Case R

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.

a. 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.

b. A new chargeback notice is created.

– The status of the claim is set to S1 in the DDR.

c. The 12 calendar day response time period begins from the Dispute File 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 are the operational steps for this use case:



a. 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.








TDR, STL T0106 ($10) $0 ($10) ($10)



1

18


– The status of the claim is set to S1 in the DDR.– Chargeback amount in DDR is the partial amount.



Use Case 1.2 - Credit Chargeback






a. Funds are returned to the merchant’s PayPal account.

– The chargeback credit appears in the STL as T1201.– The chargeback fee debit appears in the STL as T0106.


– The status of the claim is set to S1 in the DDR.– The chargeback event is logged as credit money movement



Use Case 2 - Chargeback Representment

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




Original Sales TDR, STL T11XX ($100) $3.20 ($96.80) ($96.80)

Chargeback initiated DDR S1 $100 ($3.20)

Chargeback processed TDR, STL T1201 $100 ($3.20) $96.80 $96.80


TDR, STL T0106 ($10) $0 ($10) ($10)



1

Case R

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


















TDR, STL T0106 ($10) $0 ($10) ($10)

Chargeback represented $100

Chargeback representement received

DDR S2 $100 ($3.20)

Provisional credit processed

TDR, STL T1202 $100 ($3.20) $96.80



1

20

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




















TDR, STL T0106 ($10) $0 ($10) ($10)



DDR S2 $50 ($1.45)


TDR, STL T1202 $50 ($1.45) $48.55



1

Case R


Use Case 2.2 - Partial Representment of Chargeback




















TDR, STL T0106 ($10) $0 ($10) ($10)



DDR S2 $50 ($1.45)


TDR, STL T1202 $50 ($1.45) $48.55



1

22


Use Case 3 - Chargeback Represented and Rejected




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














TDR, STL T0106 ($10) $0 ($10) ($10)



DDR S2 $100 ($3.20)


TDR, STL T1202 $100 ($3.20) $96.80

Representment rejected DDR S3 ($100) $3.20

Rejection processed TDR, STL T1207 ($100) $2 ($96.80) ($96.80)



1

Case R

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


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

a. 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)





Original Sales TDR, STL T00XX $100 ($2) $96.80 $96.80




TDR, STL T0106 ($10) $0 ($10) ($10)



DDR S2 $100 ($3.20)


TDR, STL T1202 $100 ($3.20) $96.80





1

24












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


– The chargeback debit appears in the STL as T1201. Second chargebacks are not charged another chargeback handling fee.


– 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.



1

Case R

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


















TDR, STL T0106 ($10) $0 ($10) ($10)

Consumer cancels chargeback

N/A

Chargeback refund DDR S4 $100 ($3.20)

Credit processed TDR, STL T1208 $100 ($3.20) $96.80 $96.80



1

26

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

a. The buyer logs into their PayPal account and cancels the case, or a PayPal agent cancels the case.

b. The PayPal case is closed and the status of the case in the DDR is set to S4.

c. 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 Representment









TDR, STL T0106 ($10) $0 ($10) ($10)



DDR S2 $100 ($3.20)


TDR, STL T1202 $100 ($3.20) $96.80

Consumer cancels chargeback

N/A

Chargeback refund not processed

N/A

Provisional credit not processed

N/A



1

Case R











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

a. The buyer logs into their PayPal account and cancels the case, or a PayPal agent cancels the case.

b. 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)









TDR, STL T0106 ($10) $0 ($10) ($10)



1

28










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




– The status in the DDR is set to S3.– Representment Reject debit is added to STL as T1207.


Chargeback represented out of time

N/A

Chargeback representment resolved

DDR S2 $100 ($3.20)


TDR, STL T1202 ($100) $3.20 $96.80 $96.80


Rejection processed TDR, STL T1207 ($100) $3.20 ($96.80) ($96.80)






1

Case R

Use Case 6.2 - Chargeback is Represented and Then Rejected and 2nd Representment Received















TDR, STL T0106 ($10) $0 ($10) ($10)


Chargeback represented received

DDR S2 $100 ($3.20)


TDR, STL T1202 ($100) $3.20 $96.80 $96.80


Rejection processed TDR, STL T1207 ($100) $3.20 ($96.80) ($96.80)

Chargeback represented (2nd representment)

$100

Chargeback representment received

DDR S2 $100 ($3.20)


TDR, STL T1202 $100 ($3.20) $96.80



1

30









6. Partner provides a 2nd representment with additional evidence

a. 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.



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.



1

Case R


















TDR, STL T0106 ($10) $0 ($10) ($10)

Chargeback adjustment needed

N/A $100

Chargeback credit DDR S5 $100 ($3.20)

Credit processed TDR, STL T1208 $100 ($3.20) $96.80 $96.80

Chargeback handling fee processed

TDR, STL T0106 $10 $0 $10 $10

Chargeback reissued DDR S1 ($10) $0.59


Chargeback handling fee processed

TDR, STL T0106 ($10) $0 ($10) ($10)



1

32

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.

a. The PayPal agent updates the case and a chargeback adjustment notice is sent in the DDR with status code S5.

b. A chargeback adjustment credit is sent in the STL report with TCode T1208. This credit is equal in value to the chargeback debit.

c. A chargeback handling fee credit is sent in the STL report with TCode T0106.

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

a. Funds are recovered from the merchant’s PayPal account. The chargeback debit appears in the STL as T1201.

b. A chargeback handling fee debit is sent in the STL report with TCode T0106.

c. 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

d. The 12 calendar day response time period begins from the Dispute File 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).









TDR, STL T0106 ($10) $0 ($10) ($10)

Chargeback represented N/A $100


DDR S2 $100 ($3.20)


TDR, STL T1202 $10 ($0.59) $9.41



1

Case R












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

a. The PayPal agent updates the case and a chargeback adjustment notice is sent in the DDR with status code S5.

b. A chargeback adjustment debit is sent in the STL report with TCode T1208. This debit is equal in value to the chargeback credit.

Chargeback adjustment needed

N/A

Chargeback debit DDR S5 ($10) $0.59

Debit processed TDR, STL T1208 ($10) $0.59 ($9.41) ($9.41)


DDR S2 $100 ($3.20)


TDR, STL T1202 $100 ($3.20) $96.80






1

34

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

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


2


Case Report Technical Description

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-7Box.

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. Login 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 following information:

– Third-parties’ PayPal login username– 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 programatically using an FTP client. The hostname of the Secure FTP PayPal Reporting Server is disputes.paypal.com. A user account on the Secure FTP PayPal Reporting Server has the following directory structure:

/disputes/outgoing

August 2012 35

Case Report Technical DescriptionDistribution and Access

2

36

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 time zone 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 filename naming convention depends on whether or not you are 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:

TABLE 2.1 Case Report File Naming Conventions

DDR An abbreviation for “Case Report.”

yyyymmdd The date on the data in the report. This date stamp represents the latest, or ending date, of the data.

totalFiles The 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.

version The version of the report. Three characters, right-justified and zero-filled. See “Report Version Numbering” on page 9.

format One of the following:

CSV: a comma-separated value file

TAB: a tab-delimited-field file



2

Case R

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.

TABLE 2.2 Case Report File Naming Conventions

DDR An abbreviation for “Case Report.”

yyyymmdd The date on the data in the report. This date stamp represents the latest, or ending date, of the data.

reportingWindow The 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

sequenceNumber The 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.

totalFiles The 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.

version The version of the report. Three characters, right-justified and zero-filled. See “Report Version Numbering” on page 9.

format One of the following:

CSV: a comma-separated value file

TAB: a tab-delimited-field file



2

38

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.


Case Report Technical DescriptionFile Structure

2

Case R

File 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.

Each row of the report consists of a two letter row type, followed by the details specific to that row type. Table 2.3, “Report Row Types,” lists the valid row types, along with the sections that describe the data for that row type.

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)

TABLE 2.3 Report Row Types

Code Description Section

RH Report header “Report Header Data” on page 41

FH File header “File Header Data” on page 43

SH Section header “Section Header Data” on page 44

CH Column header “Section Body Data” on page 45

SB Row data “Section Body Data” on page 45

SF Section footer “Section Footer Data” on page 52

SC Section record count “Section Record Count Data” on page 53

RF Report footer “Report Footer Data” on page 42

RC Report record count “Report Record Count Data” on page 42

FF File footer “File Footer Data” on page 43


Case Report Technical DescriptionFile Structure

2

40

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 1 File 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)


Case Report Technical DescriptionReport Data

2

Case R

Report Data

This section details the columns and related data that is delivered in the report header, report footer, and report record count records.

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

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.

TABLE 2.4 Report Header Data

Position Column Name Data Type Data Description

1 Column Type Type: Literal “RH”

2 Report Generation Date

Type: date/time The date and time when the report file was generated, in the following format:

YYYY/MM/DD HH:MM:SS offset

where:

YYYY is the four-digit year.

MM is two-digit month of the year

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, +0800.

3 Reporting Window

Type: varchar The 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

4 Account ID Type: varchar Account number receiving the report (Payer ID – encrypted hash of PayPal account)

5 Report Version Type: varchar The version of the report


Case Report Technical DescriptionFile Data

2

42

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

Report 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.

File Data

This section details the columns and related data that is delivered in the file header and file footer records.

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.

TABLE 2.5 Report Footer Data


1 Column Type Type: Literal “RF”

2 Row Count Type: Number The number of body data rows in the report (used for reconciliation). Note that the report may span multiple files.

TABLE 2.6 Report Record Count Data


1 Column Type Type: Literal “RC”

2 Row Count Type: Number The number of body data rows in the report (used for reconciliation). Note that the report may span multiple files.


Case Report Technical DescriptionSection Data

2

Case R

File Header Data

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 Data

This section details the columns and related data that is delivered in the section header, section footer, and section record count records.

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

TABLE 2.7 File Header Data


1 Column Type Type: Literal “FH”

2 File Count Type: Number The sequence number of the file in the report (used for reconciliation)

TABLE 2.8 File Footer Data


1 Column Type Type: Literal “FF”

2 Row Count Type: Number The number of body data rows in the file (used for reconciliation)



2

44

Section Header Data

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.

TABLE 2.9 Section Header Data


1 Column Type Type: Literal “SH”

2 Reporting Period Start Date

Type: date/time The date time that represents the beginning time period of the report in the following format:


where:





MM is minutes.

SS is seconds.


3 Reporting Period End Date

Type: date/time The date time that represents the ending time period of the report in the following format:


where:





MM is minutes.

SS is seconds.


4 Account ID Type: varchar Account number generated by PayPal

5 Partner Account ID

Type: varchar

Blanks: Yes

Max: 127 characters

The partner’s account ID for the merchant. This is the value passed by the partner in the <PartnerMerchantExternalID> tag of the multiple account management batch input file. See Multiple Account Management for more information.



2

Case R

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"

TABLE 2.10 Body Data

Position Column Name Data Type Data Descriptions

1. Column Type Type: Literal “SB”

2. Dispute Type Type: Text string

Unique: No

Blanks: No

Max: 12 characters

“chargeback”

The type of dispute made against the transaction is always “chargeback”.

3. Claimant Name Type: Text string

Unique: Yes

Blanks: No

Max: 128 characters

The 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.

NOTE: For transactions with disputes associated with them, claimant information is displayed only in the Case Report. It is not included in the settlement report or the transaction detail report.



2

46

4. Claimant Email Address

Type: Varchar

Unique: Yes

Blanks: Yes

Max: 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.

5. Original Transaction ID

Type: Varchar

Unique: Yes

Blanks: Yes

Max: 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.

6. Original Gross Debit or Credit

Type: Text string

Unique: No

Blanks: No

Max: 2 characters

Direction of money movement of the original transaction amount. Valid values are: CR DR

7. Original Gross Amount

Type: Currency/Money

Unique: No

Blanks: No

Max: 26 characters

The gross amount of the original transaction. The amount cannot contain decimal places, signage (+/-), or commas.

8. Original Gross Currency

Type: Text string

Unique: No

Blanks: No

Max: 3 characters

Currency of transaction.

9. Original Fee Debit or Credit

Type: Char

Unique: No

Blanks: Yes

Max: 2characters

Direction of money movement of the original transaction fee amount. Valid values are: CR DR

10. Original Fee Amount

Type: Number

Unique: No

Blanks: Yes

Max: 26 characters

The fee amount of the original transaction. The amount cannot contain decimal places, signage (+/-), or commas.

11. Original Fee Currency

Type: Char

Unique: No

Blanks: Yes

Max: 3 characters






2

Case R

12. Original Transaction Date

Type: Date/Time

Unique: No

Blanks: Yes

Max: 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 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 (e.g. +0800).

13. Dispute Transaction ID

Type: Text string

Unique: Yes

Blanks: Yes

Max: 19 characters

The transaction ID generated at the time of the money moving event for the chargeback event. This unique, 17-character ID is generated by PayPal and cannot be altered.

NOTE: 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.

14. Disputed Gross Debit or Credit

Type: Text string

Unique: No

Blanks: Yes

Max: 2 characters

Direction of money movement of the charged back amount. Valid values are: CR DR


15. Disputed Gross Amount


Unique: No

Blanks: Yes

Max: 26 characters

The amount of the chargeback reversal created in response to the chargeback request. The amount cannot contain decimal places, signage (+/-), or commas.






2

48

16. Disputed Gross Currency

Type: Text string

Unique: No

Blanks: Yes

Max: 3 characters



17. Disputed Fee Debit or Credit

Type: Text string

Unique: No

Blanks: Yes

Max: 2characters

Direction of money movement of the charged back fee amount. Valid values are: CR DR


18. Disputed Fee Amount


Unique: No

Blanks: Yes

Max: 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.


19. Disputed Fee Currency

Type: Text string

Unique: No

Blanks: Yes

Max: 3 characters







2

Case R

20. Dispute Reason Type: Text string

Unique: No

Blanks: No

Max: 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

21. Dispute Filing Date

Type: Date/Time

Unique: No

Blanks: Yes

Max: 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 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 (e.g. +0800).

22. Dispute Status Type: Varchar

Unique: No

Blanks: Yes

Max: 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.

23. Dispute Case ID Type: Text string

Unique: Yes

Blanks: Yes

Max: 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





2

50

24. Representment Rejection Reason

Type: Text string

Unique: No

Blanks: No

Max: 3 characters

The codified reason for a rejection of the representment. See Appendix B, “Representment Rejection Reason Field Values” for valid values.

25. Original Transaction Invoice ID

Type: Text string

Unique: No

Blanks: Yes

Max: 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.

26. Representment Evidence

Type: Text string

Unique: No

Blanks: Yes

Max: 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 Appendix C, “Representment Evidence Field Values” for valid values.

The evidences the seller submits are presented in the following format: 1|6|5|2

27. Buyer Dispute Amount

Type: Text Number

Unique: No

Blanks: Yes

Max: 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.

28. Buyer Dispute Amount Currency

Type: varchar

Unique: No

Blanks: Yes

Max: 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.


29. Buyer Comments For Transactions

Type: Text varchar

Unique: No

Blanks: Yes


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.

30. Sequence Number

Type: number

Unique: No

Blanks: Yes

Max: 64 characters

Sequence number of the item within the dispute transaction.

0 - there are not items

n - it is the nth item within the dispute transaction.






2

Case R

31. Item ID Type: number

Unique: No

Blanks: Yes

Max: 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 information can be different for each item in the dispute transaction.

32. Item Description Type: varchar

Unique: No

Blanks: Yes


Available if seller passed this information during checkout, and if chargeback is filed through PayPal.



33. Item Dispute Reason

Type: varchar

Unique: No

Blanks: Yes

Max: 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

34. Item Buyer Dispute Amount

Type: varchar

Unique: No

Blanks: Yes

Max: 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.


35. Item Buyer Dispute Amount Currency

Type: varchar

Unique: No

Blanks: Yes

Max: 3 characters

Currency of the amount the buyer disputed. This does not change once the dispute transaction is created.






2

52

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.

36. Filing Reasons Type: number

Unique: No

Blanks: Yes


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.


For more information, refer to Appendix D, “SNAD Filing Reason Codes.

37. Filing Notes Type: varchar

Unique: No

Blanks: Yes


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.


38. Store ID Type: varchar

Unique: No

Blanks: Yes

Max: 50 characters

The merchant’s identifier of the store where the purchase occurred.

39. Credit Card Chargeback Reason Code

Type: varchar

Unique: No

Blanks: Yes

Max: 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.

TABLE 2.11 Section Footer Data


1 Column Type Type: Literal “SF”

2 Row Count Type: Number The number of body data rows in the section (used for reconciliation)





2

Case R

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.

TABLE 2.12 Section Record Count Data


1 Column Type Type: Literal “SC”

2 Row Count Type: Number The number of body data rows in the section (used for reconciliation)



2

54

A


DDR Sample File

The following is a sample of the DDR file as defined in Chapter 2, “Case Report Technical Description.”

"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

August 2012 55

DDR Sample FileA

56

B


Representment Rejection Reason Field Values

Table B.1 lists all allowable values for the Representment Rejection Reason field of the DDR section body (see “Section Body Data” on page 45).

TABLE B.1 Representment Rejection Reason Field Values

Reason Code Code Description

100 PayPal did not receive tracking information.

105 PayPal did not receive verifiable tracking information.

115 PayPal did not receive signed proof of delivery.

120 Invalid proof of shipment provided.

200 The consumer provided proof of return to merchant.

205 The consumer provided proof of attempted return to merchant.

210 The consumer cancelled service prior to billing.

215 The merchant did not abide by their return policy.

300 Support was insufficient to show the consumer authorized the transaction.

305 The consumer maintains transaction was unauthorized.

400 The merchant accepted multiple payments for a single purchase.

600 Invalid proof of refund provided.

605 Services were not provided to the consumer.

610 Per the merchant response, the merchant accepted the chargeback liability.

615 The transaction was not marked as “SPP Eligible”.

620 The item violates the PayPal User Agreement.

625 The merchant surcharged the consumer.

630 The merchandise or services did not match item description.

635 PayPal did not receive a reply to a PayPal request for information within the required time period.

August 2012 57

Representment Rejection Reason Field ValuesB

58

C


Representment Evidence Field Values

Table C.1 lists all allowable values for the Representment Evidence field of the DDR section body (see “Section Body Data” on page 45).

TABLE C.1 Representment Evidence Types

Evidence Type Description Code

Not Representable Seller does not need to provide representment for this case.

0

Proof of Shipment Documentation 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 Refund Documentation that proves reimbursement to the buyer. 2

Return Address Seller’s return address for contested items. 3

Other Other evidence that does not fall into any category. 4

Proof of Delivery Proof 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 Confirmation

Proof 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 Authenticity Proof that validates the authenticity of an item. For example, expert’s second opinion of the buyer claims the item is “fake”.

7

August 2012 59

Representment Evidence Field ValuesC

60

D


SNAD Filing Reason Codes

Table D.1 lists all SNAD codes for the Filing Reasons field of the DDR section body (see “Section Body Data” on page 45).

TABLE D.1 SNAD Values

SNAD Codes Description

WAT_COMPLAINT_ISSUE_DIFFERENT_CATEGORY Buyer received an item that is different from what they ordered.

WAT_COMPLAINT_ISSUE_MISSING_QUANTITY Buyer received item with missing quantity of items. For example: They ordered 12 units but received 6.

WAT_COMPLAINT_ISSUE_MISSING_PARTS Buyer received an item that was missing parts that prevent the item from being used. For example: Missing computer processor.

WAT_COMPLAINT_ISSUE_INTERNALLY_DAMAGED Buyer received an item that was internally damaged. For example: Computer does not power on or function properly.

WAT_COMPLAINT_ISSUE_RUINED_FOOD_PLANTS Buyer received items that were either ruined food or plants.

WAT_COMPLAINT_ISSUE_DIFFERENT_MODEL Buyer received a wrong model of item purchased.

WAT_COMPLAINT_ISSUE_TIME_SENSITIVE_LATE

Buyer purchased a time-sensitive item that arrived late. For example: concert ticket

WAT_COMPLAINT_ISSUE_COLOR_DIFFERENCE_1 Buyer received an item with a slight color difference.

WAT_COMPLAINT_ISSUE_COLOR_DIFFERENCE_2 Buyer received an item with a significant color difference.

WAT_COMPLAINT_ISSUE_COLOR_DIFFERENCE_3 Buyer received an item with an extreme color difference.

WAT_COMPLAINT_ISSUE_EXTERNALLY_DAMAGED Buyer received an externally damaged item. For example: scratched, cracked, chipped, ripped, dented, or stained.

WAT_COMPLAINT_ISSUE_SUBSTITUTE Buyer received a less valuable substitute of the described item.

WAT_COMPLAINT_ISSUE_USED Buyer received that was used when described as new.

August 2012 61

SNAD Filing Reason CodesD

62

WAT_COMPLAINT_ISSUE_DIFFERENT_DESIGN_PATTERN

Buyer received an item with a different design as described.

WAT_COMPLAINT_ISSUE_DIFFERENT_MATERIAL Buyer received an item of a different material.

WAT_COMPLAINT_ISSUE_COPY_OF_ORIGINAL Buyer received a copy of the original item. For example: bootleg or pirated copy.

WAT_COMPLAINT_ISSUE_IMITATION Buyer received an imitation of the original item. For example: counterfeit handbag, clothing, or watch.

WAT_COMPLAINT_ISSUE_SHIPPING_COST Buyer has complaint with regards to the shipping cost of the item.

WAT_COMPLAINT_ISSUE_SALES_TAX Buyer has complaint regarding sales tax charges on the item.

WAT_COMPLAINT_ISSUE_DG_CONTENT_NOT_AS_DESCRIBED

Buyer received a digital goods item and was not satisfied with the content.

WAT_COMPLAINT_ISSUE_DG_RECEIVED_WRONG_ITEM

Buyer received a digital goods item that was completely different from the original.

WAT_COMPLAINT_ISSUE_DG_TECHNICAL_ISSUES

Buyer had technical issues during purchase of a digital good.

WAT_COMPLAINT_ISSUE_DG_OTHER Buyer had other issues during the purchase of a digital good.

WAT_COMPLAINT_ISSUE_REASON_CATEGORY Buyer received an item of different version than described.

TABLE D.1 SNAD Values

SNAD Codes Description


E

Case Report Specification, Ve

PayPal-Supported Currencies

PayPal-Supported Currencies

The following currencies are supported by PayPal for use with payments and and as currency balances:

TABLE A.13 PayPal-Supported Currencies and Currency Codes

Currency ISO-4217 Code

Australian Dollar AUD

Brazilian Real

NOTE: This currency is supported as a payment currency and a currency balance for in-country PayPal accounts only.

BRL

Canadian Dollar CAD

Czech Koruna CZK

Danish Krone DKK

Euro EUR

Hong Kong Dollar HKD

Hungarian Forint HUF

Israeli New Sheqel ILS

Japanese Yen JPY

Malaysian Ringgit

NOTE: This currency is supported as a payment currency and a currency balance for in-country PayPal accounts only.

MYR

Mexican Peso MXN

Norwegian Krone NOK

New Zealand Dollar NZD

Philippine Peso PHP

Polish Zloty PLN

Pound Sterling GBP

Singapore Dollar SGD

rsion 6.0 August 2012 63

Swedish Krona SEK

Swiss Franc CHF

Taiwan New Dollar TWD

Thai Baht THB

U.S. Dollar USD

TABLE A.13 PayPal-Supported Currencies and Currency Codes

Currency ISO-4217 Code

Case Report Specification, Version 6.0 August 2012 64

case report specification (acm)€¦ · case report, version 6.0 preface this specification details...

Documents