Evidence Packets for Marketplace Payment Disputes

Design marketplace dispute evidence around attributable records, minimized disclosure, exact packet approval and reconciled submission receipts.

audience="Marketplace product owners, payment operations and engineers responsible for dispute response workflows." decision="Choose how to preserve attributable evidence, approve an exact disclosure and settle uncertain submission state." position="Build a case-scoped packet from attributable records, keep claims separate from observations, approve the exact disclosure version and reconcile submission independently of the eventual outcome." scope="A proposed engineering design using a hypothetical coaching marketplace, synthetic records and inert payment adapters. It is not legal or financial advice, a retention prescription or a claim about winning disputes." outputs={['A scoped case identity', 'An evidence and contradiction register', 'A minimized disclosure manifest', 'A revision-bound approval', 'A submission reconciliation record', 'Independent acceptance fixtures']} />

Executive summary

A marketplace should be able to explain what its dispute response says, where each statement came from, which copy was approved and what the payment provider actually received. A current order screen does not establish those facts. Listings change, participants supply later statements, staff redact attachments and submission requests can lose their responses. The engineering problem is to preserve a defensible relationship between source material, claims, disclosed content and external operation state without turning a dispute workspace into an unrestricted customer dossier.

This paper recommends a case-scoped evidence projection backed by attributable source references, followed by a frozen disclosure manifest. Keep a useful current workspace for investigation, but distinguish it from the version reviewed for transmission. Bind approval to the exact case, provider account, environment, payload and permitted action. Revalidate the conditions that can change before a worker sends anything. A packet may be prepared without being approved, approved without being sent, and sent without the platform possessing a trustworthy receipt. None of those states establishes the eventual dispute outcome.

The illustrative case concerns a coaching-session marketplace. Synthetic order O17 refers to session S4 and payment P9. Dispute D6 alleges a service was not received. The order-time terms, session observations and later coach statement do not necessarily agree. These identifiers and conditions are teaching fixtures, not customer records or reported results. The design deliberately avoids deciding whether the complaint is valid, prescribing what evidence an issuer must accept, or promising that a technically complete response will succeed. Payment operations and qualified advisers own those judgments.

AI can assist by organizing permitted material, highlighting missing support and drafting a concise explanation with source references. It has no authority to make evidence true, waive an unresolved contradiction or submit a response. The important acceptance question is whether the platform preserves the declared case and disclosure contract under changes, delayed work and lost receipts. A measured reduction in drafting time would be useful only if attribution, confidentiality and operational settlement remain adequate. This paper supplies proposed review artifacts, not measured performance or certification.

Scope the case separately from the payment and support conversation

Start with a case identity that includes the provider account, environment and individual dispute identifier. Link the underlying payment, order and service occurrence, but do not collapse those identities into one key. A payment can support several line items, a rescheduled service can have more than one occurrence, and a support conversation can concern several issues. A response associated with the wrong dispute is not made correct by attaching an otherwise accurate order receipt. Verify associations through supported records rather than a convenient email address match.

Stripe's API dispute guide explains that multiple disputes can be associated with one payment and that each dispute has its own identifier. Retrieval also exposes evidence and response details. In this provider example, payment-level deduplication is therefore insufficient for case selection. An adapter must preserve the selected dispute's identity and current state. That is not a guarantee about another provider's object model; inspect the deployed provider contract before mapping the application's cases to its API.

Define the disputed proposition before searching for documents. Service not received, duplicate charge and cancellation disagreement raise different questions. The application should record the reported category, the actual complaint available to the operator and any uncertainty in that classification. Do not have a model silently replace a provider category with a more convenient narrative. If a staff member corrects a case mapping, preserve the reason and review the effects on previously assembled content. A correction is a new basis, not an invisible edit to old evidence.

Keep the customer conversation distinct too. A promise to investigate, a support refund discussion and a formal response are separate operations with separate owners. The proposal does not authorize outreach, refunds or access changes merely because a dispute exists. A current deadline must come from the relevant provider case interface, with observation time and timezone interpretation recorded. Internal ticket age is not that deadline. An unavailable or ambiguous case lookup should produce an operational hold or approved escalation, not an invented response window that makes a dashboard appear complete.

Model records, statements and derived claims as different evidence

An order record says what the application stored about a purchase. A session event says what a component observed. A coach statement says what that participant asserted later. A summary says what a transformation produced from selected material. These are different evidence types, even when their text describes the same service. Record who or what produced each item, when the described occurrence allegedly happened, when the source recorded it and when the case system ingested it. Those times can differ without proving misconduct or a software defect.

The W3C PROV primer describes entities, activities and agents, including derivation and revision relationships. Its distinction between an original entity and a derived or revised entity is useful for a dispute packet. A redacted copy should remain related to its input and transformation rather than replacing the original's identity. Provenance describes origin and transformation; it does not establish the truth of a statement, legal admissibility or the persuasiveness of evidence to an issuer.

For O17, an attendance event may report that an account joined a session. That does not necessarily establish who attended, how long useful service continued, or whether the purchased service was delivered as described. A later assertion that the session ran successfully requires its own attribution. Keep both the event's bounded observation and the coach's claim visible. Do not allow a generated sentence such as the customer received the complete service to become a fact because it combines several weaker observations in confident language.

Define missing and unavailable separately. Missing means the expected record was not found within a documented, sufficiently complete search. Unavailable means the search or source could not be completed. Neither automatically proves that the event did not happen. Record the search scope, access conditions and source coverage before treating absence as evidence. Integrity references can help detect changed copies, but a matching digest does not validate an event's interpretation. The case reviewer needs both preserved bytes and an honest account of what those bytes can establish.

Compare a live report, a frozen export and a case projection

A live order report is inexpensive to build because it reuses current application queries. It helps an operator investigate the latest situation. Its limitation is historical ambiguity: a changed listing, merged account or corrected session record can alter what the report appears to say about the original purchase. Use live reports when the question is current status and label the observation time. Do not represent a newly rendered screen as the exact material approved or sent earlier unless its content identity is actually preserved.

A frozen export improves reproducibility. It records a selected set of bytes at a particular time, which can be compared with an approval manifest and transmitted copy. It also creates new work: restricted storage, correction handling, retention decisions and access controls. Freezing a packet does not make its contents correct or complete. A snapshot assembled before a relevant correction may faithfully preserve an outdated claim. The operator must decide whether new material invalidates readiness, requires another review or belongs in a separate later case record.

A case projection brings selected source identities, observations and claims into a workspace designed for review. It can expose contradictions and missing records before disclosure. The cost is explicit transformation and association logic. The projection must say which source revision supports each field and what its freshness means. If it silently copies current values without lineage, it becomes another live report with a more authoritative-looking interface. If it copies entire customer profiles, it creates an unnecessary privacy and security burden that does not improve the disputed proposition.

For the hypothetical marketplace, combine the projection and frozen manifest. The projection remains an investigation workspace; a reviewed disclosure version becomes a fixed candidate for one action. Store a relationship to the supporting originals and a clear disposition when an original is later corrected or no longer retrievable under approved policy. This alternative is not universally appropriate. A small manual operation may use controlled files and a disciplined register instead of a custom service. Choose the least complex implementation that preserves the required distinctions and can be inspected by its actual operators.

Recover purchase-time facts without rewriting them as current facts

Order-time terms matter because a current listing may describe a different service or cancellation policy. Preserve the accepted terms revision or another attributable representation of what was presented, along with the applicable order and selection context. Do not assume that the latest published terms governed an earlier purchase. If the marketplace never recorded the relevant version, acknowledge that evidence gap. Retrospectively attaching a current policy cannot reconstruct the information the customer saw, even if its wording seems similar.

For O17, terms T3 might describe a remote session while the current T4 listing describes a venue session. The packet should not import T4's venue requirement as though it were part of O17. Identify the historical record, its origin and any correction. If an operator cannot establish the governing version, the response can state the available bounded facts and unresolved issue, subject to qualified review. The engineering system must not invent an acceptance record or infer agreement from continued use merely to fill a required-looking field.

Preserve relationships when bookings change. A reschedule can create a new occurrence while the payment remains associated with the same order. A cancellation may affect one line rather than the entire purchase. The case workspace should distinguish scheduled occurrence, replaced occurrence and observed service event. Without those relationships, an attendance event for S5 might be offered as proof about S4. Use independently specified association cases to test that a plausible date or shared customer identity cannot override the actual order-to-service relationship.

Historical reproduction also has access limits. An operator may have permission to review a case but not to retrieve every old attachment. An approved disposition policy may have removed a source copy. Keep the meaningful attribution that remains permitted and state when the underlying material cannot be fetched. Do not retain everything forever on the assumption that a future dispute might need it. Legal and data owners determine appropriate retention and holds for the actual organization and jurisdictions; engineering implements and verifies that policy without converting this proposal into a universal duration rule.

Preserve contradictions instead of manufacturing a single story

An evidence register should let reviewers distinguish supported observations, attributed assertions, unresolved contradictions and unsupported conclusions. For each proposed claim, list the exact source references and the reasoning needed to connect them. A successful login may support access, not service completion. A payment receipt supports a transaction, not necessarily the quality or occurrence of the service. The disputed proposition determines relevance. Do not score evidence only by how easy it is to summarize or whether it favors the marketplace's preferred outcome.

In D6, the coach says the session lasted an hour, while the available connection record shows a short interval and an interruption. That conflict should remain explicit. There may be another approved source that explains the gap, or there may not. A reviewer can request permitted clarification or decide how the known facts should be represented. A model should not bridge the gap with a sentence asserting an offline continuation. Keeping uncertainty visible is a useful operational result, not an editorial failure that must be polished away.

The proposed lineage view shows relationships rather than a provider implementation. Original records remain separate from disclosure copies; a manually prepared narrative can follow the same claim review as an AI-assisted draft. Missing support remains in a review register, not an invented attachment. No arrow means that a record is legally conclusive. The companion text defines the information contracts that the visual deliberately keeps concise, including access, source time and correction handling.

Make reviewer disagreements attributable too. Two reviewers can interpret the same limited source differently. Preserve the permitted disposition and its reason rather than replacing one opinion with another without history. Define who can settle a disputed interpretation and which changes invalidate the current candidate. Do not confuse agreement between two model-generated narratives with independent corroboration. Independence requires a distinct basis or review method, not merely another fluent response generated from the same incomplete packet.

Minimize disclosure without losing the explanation of its origin

The investigative source set and the disclosed response are not the same data product. A session record might include unrelated participants, device details or household information. The relevant extract should include what the approved response needs, not the entire raw record by default. Give each disclosure artifact a relationship to its original, the transformation performed and the reviewer who accepted the copy. A source-linked extract can be easier to inspect than an unfiltered log while keeping omitted details out of the transmission path.

Redaction requires more than hiding text in a preview. Check the actual exported bytes, searchable text, embedded objects and metadata using a suitable review process. A black rectangle placed over visible text may leave the underlying content accessible. This paper does not certify a redaction tool or prescribe a legally adequate method. The data owner should select a process and define acceptance evidence. Engineering should then verify the exact artifact that the submission adapter will upload, not a different screenshot or rendered view.

Keep access controls on both sources and generated copies. OWASP's authorization guidance recommends denying by default and validating permissions on every request. Applied to this proposed workspace, a case relationship must be checked when retrieving evidence, previews and exports. Permission to read an order does not automatically grant permission to transmit its attachments. An opaque file ID or difficult-to-guess download link does not replace authorization for a restricted disclosure copy.

Changing access can invalidate delayed work. If a reviewer loses the relevant case relationship before packet retrieval, refuse the retrieval under the declared policy. If a candidate has already been created, determine whether its continued use is permitted; do not silently treat historical access as permanent transmission authority. Record sensitive operational evidence in restricted locations rather than replicating whole packets into general application logs. A troubleshooting identifier should help locate the case without itself disclosing the complaint, customer identity or source content to every engineer.

Give AI a bounded drafting task and a usable manual path

The assistance task should be concrete: draft a concise description from selected permitted claims, identify unsupported sentences and list contradictions for review. Supply stable local references rather than asking the model to discover arbitrary documents or contact participants. Require each factual sentence to identify its supporting item or declare that it is an attributed statement. A schema can ensure references have the expected shape. It cannot establish that a sentence is entailed by the source or that the source's own assertion is true.

Keep the disputed proposition and the permitted output format explicit. The model should not optimize for a forceful rebuttal at the expense of the record. A response that sounds less persuasive because the evidence is limited may be the correct draft for review. Test omissions, overstated completion, incorrect chronology and association with the wrong session. Judge useful organization separately from factual support, privacy and readability. A single overall quality score can conceal a severe disclosure or attribution failure behind otherwise polished writing.

Untrusted records may contain instructions, forged approvals or requests to send content elsewhere. Treat that material as case data, not workflow authority. The drafting environment should have no payment-submission credentials or general customer-export capability. Any future tools require their own permission and effect-recovery contracts. A reviewer must be able to reject the draft and build the same candidate manually. Provider unavailability should reduce optional drafting assistance, not remove the core ability to inspect permitted evidence and record an authorized operational decision.

Record the assistance configuration only to the extent needed for approved reproducibility and investigation. Include the input packet identity, task version and relevant output lineage without creating an unrestricted prompt archive. A regenerated narrative is a new candidate even when it uses the same sources. It can change wording, emphasis and disclosure, so it must not inherit an earlier approval automatically. Evaluate whether the assistance actually reduces total review work after accounting for corrections and unresolved cases. This proposal establishes no model accuracy, cost saving or resistance to every hostile instruction.

Freeze a manifest that describes the actual intended disclosure

A disclosure manifest should identify the case, provider account and environment, selected fields, attachment identities, content integrity references, transformation lineage and the approved response action. It should also name the candidate revision and the conditions that make that approval usable. Keep internal source references separate from provider-facing field values. A local reference useful to a reviewer may be meaningless to an issuer, and it should not be inserted as an external link in place of the evidence the selected provider interface expects.

For the synthetic D6 candidate M2, a field-level description might refer to historical terms T3, session observation E4 and attributed coach statement C2. The disclosed attachment A2 is a minimized derivative of a restricted source, with a documented review. These are local illustrative identifiers, not provider object formats. Approval applies to M2's exact content and action. If A2 is replaced, an explanatory field changes or another dispute is selected, the manifest changes and the old approval no longer establishes readiness for the new candidate.

Content integrity is one part of binding, not the whole permission model. Matching bytes do not prove that the caller has authority, the case is still accepting responses or the intended provider account is correct. Conversely, a changed internal audit annotation that is not part of the payload should not necessarily force reapproval of identical disclosure. Define material change boundaries explicitly. A manifest should make those distinctions inspectable so that staff do not learn to dismiss every invalidation as an arbitrary technical inconvenience.

Review the final export in the form that will actually cross the boundary. Check legibility, page order, completeness and supported evidence type. A technically valid file can be unreadable or associate a claim with the wrong page. Keep an unresolved-items register next to the approval view so that frozen content is not mistaken for settled interpretation. The operator needs a reasoned choice about proceeding with known limitations, declining a response or requesting an allowed correction. The software records that authorized choice; it does not choose a commercial or legal response simply because all required fields parse.

Make staging and submission different commands

Stripe's dispute-update reference documents a submit parameter: false stages evidence, while true, the default, immediately submits it to the bank. This is an important provider-specific boundary. An adapter that intends to save a draft must explicitly use the supported staging behavior; an omitted parameter must not accidentally turn editing into submission. Keep different application commands and permissions for staging and final transmission. Inspect the deployed API contract and version rather than relying on a suggestive button label.

Staged evidence is provider-visible state, not proof of final submission. A final submit request is an external effect, not an ordinary local save. The proposed interface should explain the action before the operator confirms it and show the exact reviewed candidate. Avoid a generic save button whose meaning changes based on hidden workflow state. If staged provider fields can be changed outside the application, the final worker needs an explicit consistency strategy. Either transmit the approved payload under the supported contract or verify that the provider-held content still corresponds to the approved candidate.

Stripe's Dashboard response guide says final Dashboard responses cannot be amended with more files, distinguishes category-specific evidence and says external content links are not reviewed. It also separates submission from issuer review. Those documented limits support checking the selected evidence before final transmission, not attaching links and assuming someone will retrieve them later. Do not generalize the Dashboard procedure into every provider API behavior; use the exact supported path for the implementation being reviewed.

Deadlines are part of eligibility, not a countdown decoration. Record the case's current response window and verify it at the appropriate execution boundary. A local safety margin can help operators prepare, but its duration is an organization-specific policy, not a substituted provider deadline. Define what happens if the worker cannot obtain current case state or the window has closed. An urgent case does not authorize an unreviewed payload. The operating owner should establish an escalation and manual procedure before relying on asynchronous workers to meet time-sensitive obligations.

Protect the local transition without claiming a cross-provider transaction

Several operators can investigate the same case, and several workers can observe the same queued command. Protect the transition from an approved candidate to a recorded submission intent against stale revisions, revoked grants and competing attempts. Every relevant writer must participate in the same invariant. A UI confirmation alone cannot prevent a background importer or administrative path from replacing the candidate after approval. Test those paths explicitly rather than assuming the main screen is the only route that can change the record.

PostgreSQL's transaction-isolation documentation explains that repeatable reads do not automatically make every business rule serializable and that a serialization failure requires retrying the whole transaction. For a PostgreSQL implementation, choose constraints, locking and isolation around the actual case invariant. Re-evaluate the relevant basis on retry. A stable database snapshot does not establish that an independent provider has accepted the operation, and local transaction rollback does not undo a provider request that already executed.

The proposed local transaction checks the approved manifest revision, current local grant and existing operation state, then records the stable submission intent and pending effect before execution. The external request occurs under a separate reconciliation contract. Avoid holding a database transaction open while waiting indefinitely for a provider. It can increase contention without creating distributed atomicity. The intent record should preserve the selected action and content relationship so that a later operator can investigate an interrupted attempt without constructing a new one from current mutable records.

Cancellation and changed authority need explicit limits. A queued command can be held before it crosses the write boundary. Once the provider may have accepted it, changing a local flag cannot promise cancellation or retraction. Preserve the uncertain or confirmed effect and use the supported provider procedure, if any. Likewise, revoking a local grant prevents new unauthorized work but does not erase transmitted evidence. The case record should communicate that distinction to operations, rather than showing cancelled as though it means nothing ever left the platform.

Reconcile uncertain submission before admitting another attempt

A lost response can leave the application unable to distinguish rejected, accepted or still-pending provider execution. Preserve that uncertainty with the original operation identity and attempted payload binding. Do not mark failed solely because a local timeout elapsed, and do not create a fresh submission identity simply to make a retry button work. Read back through a trustworthy supported interface, with the correct provider account, environment and case. Record what that observation proves and what remains unknown.

Stripe's idempotent-request reference describes POST retry behavior scoped to an idempotency key, including saved failure responses, parameter comparison, key pruning and cases where execution never begins. That is not permanent exactly-once business execution. Keep the unchanged request bound to its key while the documented behavior applies, and distinguish confirmed non-execution from uncertainty. A local operation ledger still needs to explain what happened when the key is no longer usable or the readback does not establish the submitted content.

Trustworthy receipt evidence should correspond to the intended case and operation. A case status such as under review can be relevant, but may not by itself prove that the exact approved packet was submitted by this worker, especially if another channel can act on the case. Establish the supported correlation and content evidence available from the provider. If it is insufficient, keep the narrower observation and unresolved association. Do not invent an exact payload acknowledgment that the destination contract does not supply.

Separate operation settlement from dispute outcome. Confirmed submission means the supported evidence establishes that the response action happened. It does not mean the complaint was rejected or funds have been recovered. A later outcome has its own source, observation time and accounting consequences, owned by the appropriate workflow. Likewise, a confirmed provider rejection can permit an authorized correction only under the current window and contract. Recovery is a controlled disposition of retained state, not an excuse to repeat every step or silently broaden the original action.

Use independent fixtures that expose wrong associations and hidden effects

Specify expected outcomes before exercising an adapter or model. Use synthetic records and inert destinations, not real disputes or customer communications. Change one boundary at a time so that a failure can be traced to association, evidence interpretation, approval binding or effect settlement. Include positive cases too: a properly supported, minimized and authorized candidate should reach the declared test destination. A harness that rejects every operation has not demonstrated a useful response workflow, even if it prevents unauthorized transmission.

This proposed state view does not depict a cross-provider transaction or an automatic dispute outcome. Its pending record preserves the intended operation before the external request. Reconciliation can establish a bounded receipt, confirmed non-execution or continued uncertainty. Only the current supported contract and authority determine whether another attempt is permitted. The visual leaves issuer decision and accounting workflows outside the submission boundary deliberately.

| Synthetic condition | Required disposition | Evidence that decides | | --- | --- | --- | | Current service terms differ from purchase-time terms | Use attributable historical terms; do not substitute current terms | Purchase record and applicable terms revision | | Coach statement conflicts with the session observation | Preserve the contradiction for review | Separate source identities and unresolved claim | | Payment has two dispute IDs | Select and authorize the individual case | Provider account, environment and dispute ID | | Approved packet changes before the worker runs | Hold for revision-bound review | Approved manifest versus attempted payload | | Submission times out without a trustworthy receipt | Preserve unknown and reconcile the original operation | Stable operation identity and supported destination readback |

These are expected dispositions, not measured results. Extend them with revoked access, unavailable sources, malformed disclosures, staging without submission and a lost local commit response. Use an intentionally incorrect adapter as a negative control: for example, select a dispute by payment only or omit the staging flag. The harness must detect the wrong behavior. Test privacy and useful case handling separately. Keep inconclusive observations in the review denominator rather than reporting success only for easy, fully observed runs.

Acceptance checklist and the next useful artifact

Use this acceptance checklist before changing a dispute response path. Can an operator identify the exact provider account, environment, dispute, order and service occurrence? Does each proposed claim distinguish source observation from participant assertion and generated interpretation? Are purchase-time terms attributable, missing support explicit and later corrections related rather than silently substituted? Can a reviewer understand a contradiction without retrieving unrelated customer information? Those questions establish the evidence contract before the team discusses automation speed or document-generation quality.

Then inspect the disclosure and execution boundaries. Does the manifest identify the exact field values and attachment copies reviewed for transmission? Do source retrieval, exported-copy access and submission permission have separate checks? Is staging visibly different from final submission under the chosen provider contract? Can a changed payload, expired window or revoked grant hold a delayed worker? Is a stable intent recorded before a potentially uncertain write, and can supported readback settle only what it actually proves? Keep confirmed submission distinct from issuer outcome.

Review limitations with the operating owner. This design does not decide which evidence is legally sufficient, which commercial response to choose, what retention period applies or whether a dispute will succeed. It does not replace provider-specific requirements or qualified professional judgment. A frozen packet with unsupported claims is still unsupported, and a secure workspace with inadequate source records cannot reconstruct facts never captured. Choose another approach when the custom projection adds more operational complexity than the team can maintain; controlled manual preparation remains valid if it preserves the same required distinctions.

The next useful artifact is one completed synthetic case register: source identities, bounded claims, unresolved items, minimized manifest, approval scope and observed operation state. Use the dispute evidence retrieval article for the narrower retrieval question and the marketplace webhook replay playbook for adjacent payment-event rehearsal. Neither replaces this submission review. If the gaps cross several services, bring that register to the backend systems and APIs service or system architecture design service. Agree the required controls, acceptance evidence and operating dependencies before building a broader response system.