> ## Documentation Index
> Fetch the complete documentation index at: https://docs.younegotiate.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Payment Dispute Center

> See reported payment disputes, refunds and ACH returns alongside the original payment and captured evidence.

<Info>
  Review-branch implementation: backend APIs and evidence capture are available for integration. This does not mean a new creditor-portal screen is already deployed. Webhook credential collection, OAuth Connect and automatic processor enrollment are deferred pending client confirmation.
</Info>

## Real-World Example

Jane pays ABC Collections \$500. Later, her bank or payment processor reports a dispute, return or refund. ABC Collections needs to find the original payment, understand what was reported, and gather the evidence it actually has.

A supported ACH return can be discovered by an enabled background check. A card chargeback or a separately issued refund may still require a report from the processor. The creditor can record that report against a captured payment. The center labels it as creditor-reported rather than pretending the processor verified it.

The same visibility applies when Alex pays Jane's bill through an existing Bill Pay Gift or Helping Hand link. Alex is the payer; Jane remains the recipient/account holder. This feature does not add group donations or any new donation flow.

## Visual Flow

```mermaid placement="top-right" actions={true} theme={"system"}
flowchart TD
    A["Consumer or gift-link payer makes a payment"] --> B["Capture available payment context"]
    B --> C{"How is a later issue discovered?"}
    C -->|"Supported ACH check"| D["Record processor-observed update"]
    C -->|"Processor report"| E["Creditor records a labeled report"]
    D --> F["Match the original payment within the creditor account"]
    E --> F
    F --> G["Review case, timeline and evidence"]
    G --> H["Download evidence and respond through the processor"]
    C -->|"Feed unavailable"| I["Show coverage limitation; do not imply no disputes"]
    classDef actor fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E;
    classDef system fill:#F8FAFC,stroke:#64748B,color:#0F172A;
    classDef decision fill:#FEF3C7,stroke:#D97706,color:#78350F;
    classDef risk fill:#FEE2E2,stroke:#DC2626,color:#7F1D1D;
    classDef outcome fill:#DCFCE7,stroke:#16A34A,color:#14532D;
    class A,E actor;
    class B,D,F system;
    class C decision;
    class I risk;
    class G,H outcome;
    linkStyle default stroke:#94A3B8,stroke-width:2px;
```

## How It Should Work

### Payments in scope

* Existing scheduled payments, Pay Now, partial payments, extra payments and remaining-balance payments.
* Existing external Bill Pay Gift / Helping Hand payments, including a separate payer and account recipient.
* Search by internal payment ID, gateway reference, account reference, amount, date, payment origin and captured last four.
* Retained historical payments remain searchable. When no capture-time evidence exists, say **Historical evidence unavailable** rather than reconstructing consent from today's settings.

### Cases and updates

* Keep **chargebacks**, **refunds** and **ACH returns** distinct. They are not consumer account disputes and are not membership/platform billing disputes.
* Show the affected amount, source, reported processor reference, reason when available, response deadline when supplied, outcome and event timeline.
* Support open, under-review, resolved and requires-review cases.
* Keep separate partial-refund references as separate cases. Totals are affected case amounts, **not confirmed net loss**; several cases may concern the same payment.
* Duplicate deliveries/reports must not create duplicate cases. Retain older events without replacing newer outcomes.
* An update becomes unread independently for each creditor user. Marking the version that was viewed as read must not hide a newer update.
* A manual report is an auditable creditor assertion. It must not overwrite an automatically observed case or imply processor verification. It requires captured evidence with an identifiable original processor connection.
* Unmatched or ambiguous events are retained for review, not matched by amount, name or date alone.

### Evidence

* Preserve the available context at charge submission: actual processor account, payer/recipient, account reference, amount, masked method details and existing authorization context.
* Preserve available AVS/CVV **result codes**, authorization code and receipt details, without exposing card numbers, CVV values, vault tokens, processor credentials or raw gateway responses.
* Existing authorization text is context; it is not automatically proof of fresh consent to this specific amount. If the original checkout did not retain exact wording, version, IP or acceptance time, show that gap.
* Do not claim verified payer identity, 3-D Secure authentication or liability shift when those facts were not captured. Current evidence is labeled partial.
* Evidence downloads are private PDFs and are audited. A PDF is not a guarantee of winning a dispute and is not automatically sent to the processor.
* A scheduled payment whose response was lost can retain its original snapshot when the existing payment-attempt reconciliation later resolves it. Ambiguous direct/external attempts still follow their existing reconciliation/review limitations; this center does not invent a successful payment.

### Automatic monitoring and notifications

* No new creditor credentials or Merchant Settings fields are required for this release. Existing gateway credentials can support eligible ACH status checks when enabled by the deployment owner.
* The reconciliation dispatcher runs every five minutes; eligible captured ACH payments are normally checked daily for up to 180 days. This is not real-time monitoring, and it does not automatically change balances.
* General card-chargeback feeds and automatic refund discovery are not promised by the existing integrations. A successful API connection alone is not proof that these feeds are available.
* Webhook setup remains deferred and disabled by default. There is no OAuth Connect screen or automatic credential retrieval in this branch.
* Optional queued email alerts go to verified, unblocked master creditor users. Monitoring and email alerts are off by default until the client approves rollout.
* Show monitoring coverage, last successful check and check failures. An empty case list is not proof that the processor has no disputes.

### Access and accounting

* Require existing creditor authentication, verified email, active membership and billing-access rules.
* Enforce company and sub-account boundaries for searches, summaries, individual cases, reports and PDF downloads.
* Recording or viewing a case must not issue a refund, retry a charge, reopen debt or change settlement balances.
* Preserve the existing scheduled-ACH return accounting, including its once-only balance adjustment. The Dispute Center must not apply that adjustment a second time.
* Creditor responses to disputes, acceptance of liability and evidence submission continue through the processor.

### Client decisions before activation

Confirm the processor's actual chargeback/refund data source, any supported return statuses, who receives alerts, and whether assisted webhook setup is wanted later. Confirm which existing checkout authorization wording should be versioned and retained before claiming stronger evidence completeness.

## How It Should Not Work

* Do not ask every creditor to find new webhook credentials just to use payment search and evidence.
* Do not label a creditor-entered report as an authenticated processor update.
* Do not claim all card disputes/refunds are automatically discovered, or silently treat unavailable feeds as healthy.
* Do not generate missing historical authorization, identity, signature or authentication evidence.
* Do not combine a gift payer's identity with the account recipient's identity.
* Do not expose another creditor's or sub-account's data.
* Do not change payment balances merely because a case was reported or a duplicate event arrived.
* Do not show new donation types, group donations, a deployed portal screen or automated processor response submission as part of this feature.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.