a plastic card, payment, money, electronic payment, credit card, mastercard, business, finance, income, trade, to pay, invest, credits, map, debit card, saving, payment, credit card, credit card, credit card, mastercard, mastercard, mastercard, mastercard, mastercard, debit card. Building an evidence file for a disputed digital payment case
Photo by AKuptsova on Pixabay

Features

Part of Fintech consumer protection guide: terms, errors, complaints, privacy, and records

Building an evidence file for a disputed digital payment case

Digital payment dispute case showing how to preserve statements, confirmations, screenshots, call notes, notices, provider responses, and investigation records.

What to take away

  • This fictional case separates original records, observations, provider statements, and unresolved conclusions.
  • The evidence file follows one transaction from instruction through posting, notice, investigation, and response.
  • A clear error notice identifies the account, amount, date, transaction, and reason for the claimed error.
  • Screenshots supplement statements and confirmations; they do not replace complete provider records.
  • The file preserves deadlines and requests without predicting the investigation outcome.

This case is fictional and educational. It does not determine whether a transfer is covered, unauthorized, refundable, or subject to a particular remedy.

The event

On March 4, Luis uses a payment app linked to his checking account. The app displays a failed $380 payment. He tries once more, and the second attempt displays completed.

On March 5, the bank account shows two $380 debits. The recipient says only one payment arrived. Luis needs to report the event without assuming where the second debit went.

First evidence snapshot

ItemWhat it establishesWhat it does not establish
Failed-screen screenshotWhat the app displayed at a timeWhether a payment instruction entered processing
Completed confirmationOne app reference and shown statusFinal interbank settlement by itself
Bank statementTwo posted debitsWhich provider process caused each debit
Recipient messageWhat the recipient reportsIndependent recipient-account records
Support chatWhat Luis told the appBank investigation result

The file labels each item and keeps the original creation or download time.

Chronology

Luis writes one dated line per event:

Two Days of Disputed Payment Events

  1. March 4, 2
    03 p.m. First payment submitted
  2. March 4, 2
    04 p.m. App displayed failed
  3. March 4, 2
    08 p.m. Second payment submitted
  4. March 4, 2
    09 p.m. App displayed completed
  5. March 5, 6
    20 a.m. Two bank debits observed
  6. March 5, 9
    15 a.m. Recipient reported one credit
  7. March 5, 9
    40 a.m. App support case opened
  8. March 5, 10
    05 a.m. Bank error notice made

The CFPB's suspicious charge and debit guidance recommends contacting the bank or card provider promptly and keeping letters and follow-up call dates together. That page addresses suspicious charges broadly and does not classify this fictional debit.

File structure

Luis creates folders with stable names:

Evidence Folder Structure

  • 00-index
  • 01-chronology
  • 02-app-confirmations
  • 03-bank-statements
  • 04-recipient-messages
  • 05-provider-support
  • 06-bank-notice
  • 07-responses
00-index
01-chronology
02-app-confirmations
03-bank-statements
04-recipient-messages
05-provider-support
06-bank-notice
07-responses
08-final-records

The index lists each file, source, date, and relevance. Sensitive copies shared outside the formal process are redacted, while originals remain protected and unchanged.

The provider report

Luis tells the app provider:

The app displayed the first $380 attempt as failed and the second as completed. My bank statement now shows two $380 debits. The recipient reports one credit. Please identify both app references, their current status, and any available trace or reversal information.

He asks for a case number and written response. He does not say the recipient stole money or that the first transfer settled.

The bank error notice

Luis uses the bank's disclosed error-reporting channel and identifies:

What the Bank Error Notice Includes

  • Name and account
  • The two March 5 debits
  • Both amounts and descriptors
  • Why one debit may be an error
  • App confirmations and case number
  • Requested investigation and correction

The current Regulation E error-resolution section specifies content and timing for covered notices, investigation duties, correction timing, and a written explanation when an institution finds no error or a different error. It also states that a consumer may request documents relied on for that determination. Whether the fictional case falls within the rule depends on facts not supplied here.

Response reconciliation

The app later supplies two internal references. It states that the first moved from failed to reversed and the second completed. The bank initially reports that both entries posted.

Luis adds both responses to the file and asks precise follow-up questions:

  • What date and amount correspond to the claimed reversal?
  • Does the reversal have its own reference?
  • Is either bank entry temporary or adjusted later?
  • Which records support the bank's finding?
  • Has the recipient institution returned any amount?

He waits for written records rather than treating a support label as final proof.

Fictional resolution

On March 8, the bank statement shows a $380 credit with a reference matching the app's reversal record. Luis confirms that the other $380 debit remains and the intended recipient still reports one payment.

He saves the corrected statement, final app response, bank response, and closing note. The case file records a corrected duplicate debit in this invented scenario. It does not imply that all failed-screen cases resolve this way.

Closing checklist

  • Original screenshots preserved.
  • Full statement saved.
  • Provider and bank case numbers recorded.
  • Error notice date and content logged.
  • Written responses retained.
  • Final credit matched to a reference.
  • Recipient report kept separate from provider records.
  • Closing balance and downstream fees reviewed.

Common questions

Why not call the first debit fraud?

The evidence initially shows a possible processing or posting error, not deception or unauthorized access.

Is a failed app screen proof that no payment started?

No. It proves what the interface displayed. Provider and bank records may show more of the processing path.

Should originals be redacted?

Keep protected originals unchanged. Create redacted copies for recipients who do not need complete sensitive data.

When is the file complete?

After the written outcome, account correction or final finding, related fees, remaining deadlines, and monitoring needs are documented.

More in Features

Latest from Guides Desk