# Dispute and Refund Flow

**Status: LOCAL SANDBOX.** "Chargeback" here means a protocol refund from local reserved pool coverage. It is not a card-network chargeback, a bank reversal or a guarantee of recovery.

1. Once the simulated delivery window has elapsed, the original buyer may open one non-delivery claim with evidence.
2. Support can assign a separate test reviewer to triage; support cannot vote or directly issue a refund.
3. If admitted, support assigns two independent reviewers from separate test organizations.
4. The local clock must reach the protocol's decision window. Both assigned reviewers submit a reasoned vote.
5. A matching refund decision remains subject to its appeal period. The local expiry processing then consumes the reservation, debits the pool and credits only the original buyer.

The buyer recipient is fixed by the original payment. The merchant's account is not debited by the refund; any prior merchant transfer goes only to a simulated external account. Duplicate votes and payment actions use backend idempotency; invalid roles and states are rejected.

The UI's clock buttons are explicit local test controls. They do not create an automatic financial correction. Read-only reconciliation reports inconsistencies without changing the state.

The process has no production reviewer governance, evidence storage, legal process, independent arbiter or testnet dispute transaction.