Name the event before choosing an action
A cancellation stops a proposed purchase or a supported pending operation. A refund returns money after a successful payment through the available mechanism. A card dispute follows an issuer and network process. These events can affect the same customer order, but they should not be stored as one generic “reversal” with no financial detail.
In a fictional example, Sam buys Cedar's $29 research report through an authorized assistant. If Sam stops before payment completion, Cedar must resolve the pending checkout under its actual rules. If payment succeeds and delivery fails, Cedar needs a fulfilment or refund decision. If Sam disputes the card charge through the issuer, the merchant needs to handle that dispute through its provider's process.
Stripe's documentation distinguishes cancellation before completion from refund after success and describes supported partial refunds. Its dispute documentation describes a separate card-dispute lifecycle. Those are provider-specific operational references, not a universal statement that every rail exposes the same actions or timelines. [1] [2]
Find the original order and its financial state
Before taking an action, retrieve the authoritative order and payment records. Check the purchased item, license, amount, currency and provider reference. Determine whether a completion response was lost, whether the payment is still unresolved and whether a refund or dispute already exists. Acting on a customer's or agent's free-text description alone can create a second financial problem.
A checkout canceled in your application does not necessarily prove that the associated financial operation was canceled. Likewise, a support note that says “refund approved” does not establish that money was returned. Record the business decision and the provider result separately, and update the customer when the relevant operation reaches its actual outcome.
For a partial resolution, calculate the amount explicitly. Suppose Cedar sold an illustrative two-part package for $40, with two agreed $20 components, and only one component is to be refunded under the merchant's policy. The teaching refund amount is $20, leaving $20 of the original payment unreimbursed. This arithmetic is synthetic; a real allocation must follow the actual offer and agreed resolution.
Choose the operation by event
Scroll the table to compare all columns.
| Route and event | Next responsibility | Responsible owner | Evidence to keep |
|---|---|---|---|
| Pending checkout canceled | Resolve the supported session and any pending payment operation | Checkout owner and payment operator | Session state and provider operation result |
| Successful card payment; refund agreed | Use the provider’s supported refund process | Authorized payment operator | Original payment, refund amount and refund status |
| Formal card dispute | Follow the provider’s dispute response process | Dispute case owner | Case reference and accurate purchase evidence |
| Direct stablecoin payment; return agreed | Use the supported return-payment process after destination checks | Authorized wallet/payment operator | Original transaction and new return transaction |
| Delivery failure with valid payment | Recover delivery or apply the disclosed resolution policy | Fulfillment owner and support | Paid order and fulfilment exception |
Card and stablecoin routes need different playbooks
A card route can include provider refund operations and issuer-led disputes under the applicable contract. Use the payment provider's current instructions for your payment method and account. Do not publish a universal dispute deadline, fee or guaranteed outcome based on a general article.
A direct stablecoin payment should not be described as having the same card chargeback mechanism. If the merchant agrees to return funds, determine the supported refund or outgoing-payment process, verify the recipient and asset, and record the new financial reference. Do not infer an automatic reversal API merely because the original payment used x402.
The absence of a card-style dispute process does not explain whether the merchant delivered the promised product or what obligations apply to the sale. Keep commercial policy, payment mechanics and applicable legal requirements distinct. Obtain qualified advice for the operator's actual markets and terms rather than copying a universal policy from this guide.
For either route, verify the destination through the supported process. Stripe's documented card refund behavior returns funds to the original payment method. A request from an assistant to refund a card purchase to an unrelated wallet should not be treated as an ordinary equivalent action. [1]
Collect evidence of the defined purchase
The useful record starts with what was offered: the report edition, license, price and delivery promise. Then retain the applicable authority reference, the final checkout terms, the verified payment reference and the fulfilment result. These records should join to the same order and be available to authorized operators.
A customer instruction to “find a report” is different from authority to pay for this specific license. A trusted agent identity is different from customer consent. If your route uses AP2, its linked checkout and payment mandates are designed to support that evidence connection. Follow the actual verification contract instead of presenting an informal approval note as a cryptographic mandate. [3]
Delivery evidence also needs context. A generated link may show that the merchant attempted delivery, but it does not automatically prove the buyer received usable access. Record the entitlement or fulfilment outcome appropriate to the product. Avoid collecting unnecessary personal data merely to make a case file appear more extensive.
- Match the product, license and final total to the original order.
- Verify the applicable authority and original payment outcome.
- Check the entitlement or delivery result, including missing evidence.
- Check existing refund and dispute records before another reimbursement.
- Record the resolution owner, authorized operation and final financial or delivery reference.
Handle paid but undelivered orders first as delivery exceptions
If Cedar has verified payment and no working report access, inspect the delivery service. A recoverable outage can often be resolved against the original order. Keep the customer informed of the actual state and provide a support reference. Do not ask the assistant to repeat the purchase as a workaround.
If fulfilment cannot be completed, apply the merchant's disclosed resolution policy. A refund may be the appropriate action, but it still needs its own provider operation and tracked result. If the refund fails or requires additional action, preserve that exception rather than marking the case closed because an API request was submitted.
Where a product has partially delivered value, define the relevant facts before choosing a partial refund. The agent may have received an API result, downloaded one part of a bundle or obtained a license that remains active. State the agreed resolution clearly and record any entitlement change. Do not invent a universal “consumed digital goods” rule that overrides the actual contract or applicable law.
Coordinate refunds with open disputes
Check whether the payment already has a dispute or pending reimbursement before issuing another action. Stripe's refund documentation warns about duplicate reimbursement risks in some payment-method situations. Follow the provider-specific instructions for the current case rather than assuming a refund and dispute can be resolved independently without financial consequences. [1]
Assign a case owner who can see both the customer support history and the provider's current financial state. If the buyer's assistant contacts several channels, link the requests to the same order. A second support message should not trigger a second refund solely because it looks like a fresh conversation.
Communicate the difference between a merchant decision, a submitted operation and a confirmed result. “We approved the refund” and “the provider records the refund as successful” convey different facts. Use the wording that matches the evidence. Avoid exact arrival promises unless your provider and operation can support them for that payment method.
Illustrative delivery incident
- Customer request
Sam reports missing access to the $29 Cedar report.
- Verify records
Support joins the order, payment and entitlement references.
- Decide resolution
Recover delivery or approve an appropriate resolution under the actual policy.
- Execute operation
The authorized system retries access or performs the supported refund action.
- Confirm outcome
The customer receives the real delivery or financial status and a case reference.
Give the reviewer a compact case packet
A useful packet includes the order reference, product and terms, authority evidence, payment outcome, delivery history, customer issue and proposed resolution. Keep sensitive credentials out of it. If the provider requests specific dispute evidence, prepare it through the provider's current supported workflow and review it for accuracy.
Do not use a generated narrative to fill gaps in the records. If the merchant cannot show that a report was delivered, say that the evidence is missing. An assistant can organize existing events, but it must not invent a timestamp, customer acknowledgement or successful access event to make the case stronger.
Preserve source records and distinguish them from an analyst's interpretation. A concise summary should point to the underlying event references so another operator can check it. If an agent produced the summary, review factual assertions before sending them to a provider or customer. This guide does not submit disputes or contact anyone on the merchant's behalf.
Define a merchant resolution workflow
Write a short operational policy for pending checkout, unresolved payment, paid-but-undelivered, customer cancellation request, partial delivery and formal dispute. For each category, identify the owner, evidence needed, permitted operation and customer-facing status. Keep provider deadlines and requirements in the actual runbook with their source dates.
Limit who can move funds or change entitlements. An assistant can collect the relevant records and propose an action, while your protected payment or support workflow enforces the applicable approval. A positive risk score is not enough to authorize an arbitrary refund destination or an amount unrelated to the original order.
Agentify Commerce is an affiliated route for digital offers, direct-to-merchant USDC/x402 payment and digital delivery. In that route, keep payment and delivery references together so support can locate the underlying purchase. This product description does not claim a universal refund engine, card chargeback service or escrow.
Test the resolution without inventing an incident
Use synthetic records or provider-supported test operations to exercise the workflow. Try an unresolved payment, confirmed payment with delivery failure, duplicate refund request and a case already in dispute. Record the expected permitted action and the evidence required before money moves.
The report and package examples in this article are fictional. They demonstrate state and arithmetic, not observed customer incidents or dispute success rates. Do not publish a provider ranking based on them. A real assessment needs the actual payment method, account configuration and reproducible evidence.
A good dispute playbook leaves a readable result: what the buyer approved, what was paid, what was delivered and which resolution occurred. Where a fact remains unknown, keep it explicit and assign the next investigation. Clear records reduce avoidable confusion even when the merchant cannot guarantee the final decision in a formal dispute.