Dispute Evidence Portal

[remear]

The goal of this issue is to begin a discussion on implementing a dispute (chargeback) evidence portal, a means by which evidence to dispute a chargeback may be submitted to Balanced.

Some questions to begin the discussion:

• Does dispute evidence need to be accessible via the API? Is via the Dashboard sufficient?
• What security concerns need to be addressed?
• How do you envision this working?
• How long should dispute evidence persist?

[remear]

Some mockups for Dashboard functionality. https://github.com/balanced/balanced-dashboard/issues/1002

[mjallday]

Does dispute evidence need to be accessible via the API? Is via the Dashboard sufficient?

Everything we've not provided via the API people have asked for API access for. IMO if a marketplace gets to be a certain scale they are going to need/want programmatic access to the resource.

What I'd like to know is what type of evidence needs to be submitted? Is there a standard set of evidence that is effective in fighting all chargebacks or does it change depending on the dispute?

[cohitre]

would this be the first api call that requires file uploads and hosting?

[remear]

@cohitre I believe so. I'm not aware of any others.

[andrewnossiter]

-I think our larger customers are definitely going to want to access the dispute portal via the API, although I think that if it's easier to get this up-and-running via the dashboard that's a great first step

@mjallday The type of evidence that gets submitted to fight a chargeback is either a screenshot of tracking information, a URL that leads to a shipping company's tracking page, or a .pdf/.jpeg of an email exchange, purchase receipt, things like that. Generally not enormous amounts of data

• @remear I think the mock the Damon made looks quite good actually

[mjallday]

Andrew - a URL by itself would not be sufficient right?

In the mocks the user supplies a file + some free text meta data to go along with the files.

Once they have supplied data will Balanced ask them to supply additional information? E.g. I don't think the designed UI works well if we need to go back to the customer and ask for a second round of documentation.

Does the bank ever come back with a request for additional information rather than a binary won/lost decision? If they do, we should support that.

[remear]

@andrewnossiter - Do people submit more than 1 file to dispute a chargeback? If so, how often?

Should we just require an archive (zip, tar.gz, etc) file that contains everything?

How should the API work here? Should the GET response for a dispute have an archive_url attribute that denotes from where they can download the submitted archive? Does there need to be a direct download endpoint?

[andrewnossiter]

@remear I can't speak to the API question here, but there are generally 1-3 distinct files to be uploaded, so we definitely need to offer the option to attach several things.

Also, specifically for Amex chargebacks the items submitted MUST be black and white, and a .pdf Any MC/Visa/Discover dispute goes via the other processor, and can be uploaded in any format

[mjallday]

Should we just require an archive (zip, tar.gz, etc) file that contains everything?

Asking customers to be familiar with archiving files sounds like a tall order. It also means that updating an existing file or adding another piece of evidence becomes much harder.

I think the json schema we follow makes this pretty trivial. It's just POST|PUT|GET to /disputes/DP123123/evidence. It's very similar to creating a credit on a bank account.

I'm not sure what a direct download endpoint is. GET on an evidence resource can either return the file contents directly within the payload or we can give a link to some storage mechanism like s3. You'd likely want to convey metadata with the file (e.g. created_at).

[remear]

I'm +1 for some kind of an evidence resource.

I'm looking for areas in which we can standardize the process across all. Since AMEX requires a PDF, can we require only PDFs? PDFs are relatively immutable. They're viewable with a free application (Acrobat Reader) or even by OS built-in applications (Quick Look or Preview). Requiring only PDFs might make it easier to enforce the black & white document requirement AMEX imposes because we could run the PDFs through a process to greyscale each PDF using something like ImageMagick.

@andrewnossiter Could clarify the frequency AMEX has actually rejected documents with color.

[andrewnossiter]

@remear correction, Amex accepts jpeg, doc and pdf

[andrewnossiter]

FYI, for any chargeback documentation submitted to Amex we need to make a note in the portal that documentation must be submitted in black and white (they don't accept color documents, annoyingly).

[remear]

Let's standardize accepted formats to ones they all accept: pdf, doc, and jpg/jpeg. For now, customers should be responsible for submitting in black and white at least documents for AMEX disputes.

@andrewnossiter

Would you please address @mjallday's concerns about handling requests for more information.

• How often do we currently have to ask for more information?
• Does the bank ever come back with a request for additional information rather than a binary won/lost decision?
• If we ask for more information, should we retain the already submitted information?

[dmdj03]

Correct me if I'm wrong @andrewnossiter but I thought you only have one chance to submit information (following Litle's portal). You cannot resubmit information.

[mjallday]

Either way I think that would be fine for the MVP to only handle the initial submission of information. I think the user should be able to build up all their information and take as long as they like to do so. Once they have everything uploaded and ready to go they can hit submit and we'll submit the information to the processor.

If we assume that once that's done the user just waits for a binary decision then I think we'll cover the 90% use case very well.

I agree with @remear that we just pass on whatever they give us so long as it's an accepted file type, if they submit color but we told them it needs to be b&w then that's the too bad.

[remear]

Uploaded files should probably be renamed to some standard format.

Let's talk security concerns.

There should be limits for the number of file uploads and individual file size.

We should probably run antivirus/malware scans on file uploads. Any counter arguments?

Are there any other security concerns we should address? Should we perform file encryption?

[mjallday]

Should we perform file encryption

How do we submit information to the processor once it's been uploaded to us? If we're submitting via SFTP or similar then encryption shouldn't be an issue since it's all via SSL end to end. If it's submitted via email then encryption is required when it leaves our network. The information that we store is going to contain PII such as addresses and emails so you're right that we need to think this through.

There should be limits for the number of file uploads and individual file size. We should probably run antivirus/malware scans on file uploads.

Given that it's marketplace's uploading this information I think the amount of abuse this system is going to receive is limited (IMO)/ and limits on uploads etc could be done in a second version. By the time a marketplace gets around to fighting disputes we've already confirmed their identity and they have been vetted by our staff. That said this is a great attack vector to get inside amex or visa for a malicious actor. :D

[steveklabnik]

@mjallday that's data-in-transit, I think @remear was wondering about data-at-rest.

[remear]

Both, actually.

[remear]

Now available!

http://blog.balancedpayments.com/announcing-dispute-portal/