When verification says paid but settlement disagrees, who wins?

Been thinking about a gap that keeps showing up in agent payment flows.

Verification and settlement are usually treated as the same event. The facilitator checks the payment, says it is valid, the resource gets served. But they are two different claims. Verification says this authorization is genuine and matches the terms. Settlement says value actually moved on chain. Most of the time they agree, and when they do not, the disagreement is discovered later, by whoever is doing the accounting.

We have seen the shapes this takes. A payment verifies, the call is served, and the settlement quietly fails or lands for a different amount. Or the reverse: value moves, but the verification record never gets written, so the seller's books say unpaid while the buyer's wallet says otherwise. Either way one side is holding a receipt the other side does not recognize.

The interesting question is what the protocol should do at serve time. Serve on verification and treat settlement as a back office problem, and sellers carry the risk. Wait for settlement finality before serving, and every call inherits chain latency. Serve on verification but keep a first class record of the disagreement, so it can be reconciled instead of argued about, and now somebody has to define what that record contains.

If you run paid endpoints or agents that pay for calls: when verification and settlement disagree on one of your payments, which one do you treat as the truth today, and what breaks because of that choice?