The Agentic Dispute File: Bind Consent, Purchase Intent, Payment and Reversal

The evidence chain

Every arrow is a potential evidence gap.

• Agent authentication is not delegated authority.
• Delegated authority is not card or payment authorization.
• Represented consent or intent is not automatically a legal conclusion about consent.
• An approved or constrained checkout is not permission for a materially different purchase.
• A payment state is not proof of fulfillment.
• A refund instruction is not necessarily evidence that funds reached the customer.
• A valid signature or hash does not prove every statement in the signed object is true or complete.

The W3C Verifiable Credentials Data Model v2.0 makes the final distinction explicit: verification evaluates whether a credential or presentation is an authentic and current statement; it does not imply truth of the encoded claims.

Keep agent recognition, mandate and payment authorization separate

Visa’s current Trusted Agent Protocol describes an agent-recognition signature, a linked consumer-recognition object and a linked payment container. Those mechanisms can help a merchant verify a participating agent and bind consumer and payment information to an interaction. Visa also states that the product is in the process of development and deployment and may not be available in all markets.

Mastercard says its Agentic Tokens are designed to register, verify and recognize agentic transactions, connect them to consumer-defined permissions and limits, and support dispute handling. IXOPAY says its Universal Tokens preserve agent identity, customer consent, purchase intent and related context in a merchant-owned auditable record.

Bind intent to the checkout that actually executed

AP2 v0.2 defines a Checkout Mandate and a Payment Mandate. The merchant supplies a signed Checkout JWT, the closed Checkout Mandate is bound to that checkout through a hash, and the Payment Mandate is bound to the particular checkout. The protocol also defines Checkout and Payment Receipts.

In Human Present / Direct mode, the user sees the closed checkout and payment. In Human Not Present / Autonomous mode, the user approves constraints and verifiers evaluate the later closed transaction against those constraints.

AP2’s dispute verification checks the mandate and receipt bindings and says that, after successful verification, the information can be used as evidence of what the user and relevant roles saw. AP2 leaves the specific mechanics of dispute resolution, retention and retrieval outside its scope.

The reviewer should therefore preserve the represented approval or constraint set and the checkout/order that actually executed. A material change in amount, currency, merchant, item, quantity, timing or terms should remain visible as a change requiring its own evidence.

A timeout is an evidence gap, not a payment state

A client can send a payment request and time out without learning whether the provider accepted or processed it. A retry might be appropriate, but a blind retry can create ambiguity about whether one or two economic operations exist.

Stripe provides a provider-specific example. Its APIs support idempotency, and Stripe also retries undelivered webhook events while documenting duplicate-event processing controls. Stripe v1 and v2 idempotency semantics are not identical.

Keep the business obligation, local attempt ID, provider object/reference, idempotency or correlation reference, provider event time and local observed time as distinct fields. Treat a timeout as an inconclusive observation unless the relevant source of record says otherwise.

Payment state and fulfillment state answer different questions

Stripe’s PaymentIntent can move through states including requires_action, processing, requires_capture, succeeded and canceled. Those are Stripe semantics, not a universal payment taxonomy.

A successful payment still does not establish that the merchant shipped the item, delivered the service, completed the whole order or only part of it. Fulfillment assertions should be retained separately, with their source and any conflicts.

Cancellation, reversal, refund and dispute are not synonyms

Adyen’s current documentation illustrates the distinction. An uncaptured payment can be canceled; after capture, a refund is used. Adyen also exposes a reversal operation that chooses cancellation or refund according to the payment state.

A REFUND or CANCEL_OR_REFUND webhook with success:true means Adyen’s validations succeeded and the refund request was sent onward. Adyen documents that a later REFUND_FAILED or REFUNDED_REVERSED event can still occur.

Stripe provides another provider-specific variation: a refund can be pending. A dispute is a separate process again; Stripe documents an under-review state and later provider-reported won or lost outcomes. Applicable deadlines depend on the network and case context.

Agentic Payment Dispute Case File

# Agentic Payment Dispute Case File

Status: [Author synthesis] / proposed reviewer template
Not an industry standard, legal template, audit standard, scheme rule,
or existing Treasury Desk dispute-resolution product.

## Case control

case_id:
purpose:
reviewer_or_owner:
opened_at:
reviewed_at:
source_inventory:
source_completeness: complete | partial | unknown
known_source_gaps:

## Principal, agent and mandate

principal_ref_opaque:
agent_ref_opaque:
agent_authentication_evidence_ref:
delegated_mandate_ref:
mandate_version:
mandate_scope:
mandate_expiry:
revocation_evidence_ref:
revocation_event_time:
revocation_observed_time:
authority_questions_open:

## Represented consent, intent and order

represented_consent_evidence_ref:
purchase_intent_snapshot_ref:
checkout_or_order_ref:
terms_version_ref:
merchant_ref_opaque:
amount:
currency:
item_or_service_summary:
approval_or_constraint_time:
change_log:
  - changed_field:
    before:
    after:
    source_ref:
    separate_approval_evidence_ref:

## Payment attempts

attempts:
  - local_attempt_id:
    provider_or_rail:
    provider_object_ref:
    request_time:
    provider_event_time:
    locally_observed_time:
    original_provider_status:
    documented_status_meaning_ref:
    retry_reason:
    idempotency_or_correlation_ref:
    previous_attempt_relation:
    evidence_gap:

## Fulfillment

fulfillment_assertions:
  - assertion:
    asserted_by:
    event_time:
    evidence_ref:
    evidence_scope:
    conflicting_evidence_ref:

customer_acceptance_evidence_ref:
fulfillment_open_questions:

## Dispute

dispute_ref:
dispute_reason_original:
dispute_opened_at:
provider_network_region_scope:
evidence_requested:
evidence_received:
evidence_missing:
applicable_deadline:
deadline_primary_source_ref:
deadline_scope_check:
deadline_verified: true | false

## Refund / cancellation / reversal

recovery_actions:
  - action_type_original:
    instruction_ref:
    requested_amount:
    requested_currency:
    provider_ref:
    provider_validation_or_acceptance_evidence_ref:
    later_execution_or_outcome_evidence_ref:
    partial_outcome:
    failed_outcome:
    reversed_outcome:
    reconciled_amount:
    reconciliation_ref:
    open_question:

## Human disposition and integrity

supported_findings:
unsupported_inferences_not_made:
pending_questions:
escalation_owner:
provenance_checks:
integrity_checks:
source_conflicts:
access_rationale:
data_minimization_rationale:
retention_rationale:
reviewer_disposition:
reviewed_at:

## Provider-specific appendix

AP2-only fields, when actually present:
- checkout_mandate_ref
- checkout_hash
- checkout_receipt_ref
- payment_mandate_ref
- payment_receipt_ref
- direct_or_autonomous_mode
- open_constraint_evidence_ref

Stripe-only fields, when actually applicable:
- payment_intent_ref
- original Stripe status
- event IDs
- idempotency reference
- refund status / pending_reason where available
- dispute ref/status

Adyen-only fields, when actually applicable:
- payment PSP reference
- reversal PSP reference
- REFUND validation result
- REFUND_FAILED event ref
- REFUNDED_REVERSED event ref
- CANCEL_OR_REFUND event ref

Do not copy:
- PAN/card credentials
- passwords, secrets, API keys or tokens
- raw identity credentials where an opaque reference is sufficient
- private DMs or unrelated personal data
- full customer/payment-account records merely for convenience

Synthetic walkthrough

In synthetic case CASE-SYN-AGENT-01, an earlier purchase intent permits one specified product from Merchant-A within a stated ceiling. The later checkout contains a higher amount and a substituted item.

The reviewer records the mismatch without calling it fraud or invalid consent. A first payment request then times out and is retried. Provider objects, correlation/idempotency references and provider events are needed before the reviewer can determine whether one or two provider operations exist.

Only part of the order is fulfilled. A partial refund is requested. The provider validates the refund request, but later outcome evidence has not yet been attached. The correct state is therefore “refund outcome pending evidence,” not “customer refunded.”

A signed receipt later verifies correctly. That improves integrity evidence but does not supply missing fulfillment evidence or establish that the refund completed.

Reviewer checklist

• Separate agent identity from mandate and payment authorization.
• Record mandate/version, scope, expiry and revocation evidence.
• Bind represented intent to the exact executed checkout/order.
• Keep post-approval changes visible.
• Separate obligation, local attempt and provider payment object.
• Retain event time and local observed time.
• Resolve retries through provider-specific evidence rather than assumption.
• Keep payment and fulfillment evidence separate.
• Separate refund/reversal instructions from later outcomes.
• Keep provider-specific statuses in their documented scope.
• Use dispute deadlines only with proven rail/network/region applicability.
• Escalate legal validity, liability and fraud questions to qualified human review.

What this does not prove

A technical case file does not by itself prove legally valid consent, fraud or absence of fraud, liability, compliance, chargeback entitlement, correct accounting treatment or legal sufficiency of evidence.

For one EU issue-spotting example, consolidated PSD2 Article 64 ties authorization to payer consent given through the procedure agreed with the relevant payment service provider. A technical intent artifact should therefore not be silently renamed “legal consent.”

Absence of an available record is an evidence gap; it is not automatically proof that consent never existed. Technical payment completion is also distinct from fulfillment closure, reconciliation closure and the end of a commercial dispute.

This method does not imply that Treasury Desk authenticates agents, executes payments, processes refunds or reversals, detects fraud, resolves disputes, represents merchants in chargebacks or provides legal advice.

Sources and methodology

• AP2 v0.2 specification
• AP2 Checkout Mandate
• Visa Trusted Agent Protocol specifications
• Mastercard Agentic Tokens material
• IXOPAY Agentic Suite
• Stripe PaymentIntent lifecycle
• Stripe disputes documentation
• Adyen refund documentation
• Adyen reversal documentation
• W3C Verifiable Credentials Data Model v2.0

Provider claims remain provider-attributed. Provider-specific statuses are not generalized into a universal rail taxonomy. The case-file schema and reviewer workflow are author synthesis.

Stress-test the template against a public or fully synthetic flow. No private payment data is needed.