Refunds and failed delivery#

The case this page covers: money moved and the capability did not arrive.

Why it is handled separately#

Because paying and receiving are separate stages. A confirmed payment is a milestone; the purchase completes only when the capability is delivered. A gap between those two is a real state the system recognises rather than a silent loss.

What triggers it#

• Settlement succeeded, provisioning did not.
• A vendor accepted a charge and then could not deliver.
• A settlement result was indeterminate and reconciliation showed the charge stood without a delivery.

What happens#

Refund handling is the safeguard for delivery failure after a successful availability check. A settled purchase that is not provisioned requires refund handling — it is not left as an open purchase indefinitely.

Duplicate protection#

While a purchase for the same agent and capability is unresolved, another attempt is blocked. An indeterminate settlement keeps that block until reconciliation. This is deliberate: retrying into an ambiguous charge is how people get billed twice.

What is not a refund case#

Situation	Why not
Provider unavailable. at checkout	No money moved, so there is nothing to refund
A failed live signup where nothing was purchased	Nothing was charged
A capability you no longer want	Delivered is delivered — a refund covers failed delivery, not a change of mind

What to have ready#

The purchase and the agent it was for, from Payment history. Those two facts identify it.