Why agent purchases are hard to dispute
A normal bad purchase is easy to argue: you know what you clicked. An agent purchase removes the click. The merchant sees a payment that went through cleanly. The platform sees a completed call. You see an item you did not want and a charge you did not expect, and the only account of how it happened is a conversation you could have edited and a summary the agent wrote about itself. Dispute processes settle on documented evidence, and a transcript is the weakest evidence there is, because it can be rewritten by the side presenting it.
What changes the argument is a record that was fixed before the dispute existed: the instruction as it was given, the purchase as it was made, each saved at its own moment. That is the record a Zambo connection keeps automatically, because every call on it leaves a verifiable receipt when it runs.
The two records that decide it
The instruction record. The call that set the task, with the parameters it carried: the item, the version or size, the budget, the conditions. Saved when the task was given, not reconstructed when the argument started.
The purchase record. The buying call itself: what it returned, what it cost, when it happened. Saved when the purchase ran.
Put them side by side and the dispute usually resolves into one of two honest shapes. Where the two records differ, the agent departed from its instruction, and the difference is the dispute, stated in the merchant's own terms: instructed this, bought that, at these times. Where the two records match, the purchase was faithful and the problem was the instruction, which is a different conversation, with yourself, and the record settles that too. Either way, you stop arguing about what happened and start arguing about the remedy, which is where disputes are actually won.
Worked records: a refused payment, and an approval, both on record
These are live records, opened on the day this page was written. The refusal: on October 16, 2026, a payment attempt on a connection whose daily spend cap was set to $0 came back spend_limit_reached with limit_usd 0, and nothing was charged. The attempt and its refusal are preserved as verifiable receipt 2f8bd3d1: purchase attempts on the connection are recorded whether the money moves or not. The approval: handover 45434a17 delivered four steps of work, and its acceptance record at acceptance.json reads accepted, decided by the client, release hint ok_to_release, four of four steps checked. Where a purchase sits behind an acceptance like that, the approval record is part of the packet: it shows who let the work proceed, and when.
The packet to send
Send links, not screenshots. A screenshot asks the merchant to trust your picture of a record; a receipt link lets them open the record and check it themselves.
- The instruction receipt. The link to the call that set the task, showing what the agent was told to buy and when.
- The purchase receipt. The link to the buying call, showing what was actually bought, the amount, and the time.
- The timeline. The two timestamps, in order, with any calls between them that changed the task.
- The spend-limit state. What spend_limit_status reports for the connection: the cap in force and the charges list, so the merchant can see whether a fence existed and what it allowed.
- The approval record, if there is one. The acceptance state for the work, or the honest absence of one.
- One paragraph. Instructed this. Bought that. The difference is the dispute. Keep it to the records; they do the arguing.
What the record does not do
- It does not reverse the charge. Zambo never holds your money and cannot claw a payment back. Reversal is the merchant's or the payment provider's decision; the record is the strongest evidence you can put in front of that decision, not the decision itself.
- It does not prove the instruction was wise. A receipt proves the saved record of the instruction and the purchase has not changed since it was saved. If the record shows the agent bought exactly what it was told to buy, the dispute is with the instruction, and this page will not dress that up as the merchant's fault.
- It does not cover purchases made elsewhere. Work the agent did outside this connection was never recorded by it. The packet covers what ran through the connection, and says so.
- It does not prove the bought thing works. Whether the purchase was correct, or the work behind it was right, is judgment the record informs but never replaces.
Make the next one impossible to misbuy
Two fences, both cheap. A cap: spend_limit_set sets a daily amount the connection enforces before money moves, so a wrong instruction has a ceiling; the morning-after page works the runaway version of this problem, and setting the cap before the agent spends is the preventive one. A gate: for purchases above a size you choose, require human sign-off before the agent acts, so a person reads the exact purchase before it becomes a charge. The merchant-side mirror of this page is the client who refuses to pay because an AI did the work: same record, other side of the table.
Questions, answered
My AI agent bought the wrong thing. How do I dispute the charge?
Build the dispute from the record, not from memory. Every call the agent made through Zambo was saved as a verifiable receipt when it ran, so you hold two records: the instruction (what the agent was told to buy, with the time it was given) and the purchase (what it actually bought, with the time it happened). Put them side by side, add the connection's spend-limit state and the approval record if the purchase sat behind one, and send the merchant or payment provider the receipt links with one paragraph stating the difference. The links matter: the other side can open each receipt and check it without trusting you. The reversal decision stays with the merchant or provider, and Zambo never holds your money, so the record is the strongest thing you can send, not a promise of the outcome.
The merchant says the payment was authorized. What does the record change?
It separates two questions the merchant's answer mixes together. Whether a payment was authorized is about the payment rail. Whether the purchase matched the instruction is about the agent, and that is the question your dispute actually turns on. The receipts answer the second question with saved results and timestamps that neither side can edit after the fact: the instruction as it was given, the purchase as it was made. An authorization log shows money moved. The record shows what the money was told to do, and what it did instead.
What if the record shows the agent bought exactly what I told it to buy?
Then the record clears the merchant and the agent, and the mistake was the instruction. That is an honest outcome and a common one: a vague brief, a wrong size or version named in the task itself, a budget with no cap behind it. The same record is what prevents the repeat: a daily spend cap the connection enforces before money moves, and a sign-off gate for purchases above a size you choose, so the next wrong instruction gets caught by a person before it becomes a charge.
Does a receipt prove the agent was wrong?
No. A verifiable receipt proves that the saved record of a call, the instruction, the purchase, the times, has not changed since it was saved. It does not prove the purchase was wrong, and it does not prove the work behind it was right. Wrongness is the comparison you and the merchant make from the record: instructed this, bought that. The receipt's job is narrower and stronger: nobody in the dispute has to take anybody's word for what the record says.
How do I stop the agent from buying the wrong thing again?
Fence the purchase before it happens. spend_limit_set puts a daily cap on the connection, enforced before a payment is taken, and a payment attempt past the cap returns spend_limit_reached with nothing charged; that refusal is itself saved as a verifiable receipt. For purchases that should never run unreviewed at any size, add a human sign-off gate: the work waits at hold until a person accepts it, and only then does the acting step proceed. Both spend tools are free. For $0.99, put the record in front of the next purchase, so the wrong buy gets flagged before the money moves: get the Day Pass. The Day Pass covers 24 hours; ongoing use is the Zambo Pass at $29 a month or $290 a year, $19 a month for $ZAMBO holders.