AI agent refund verification: proof the refund really happened.

What the refund check actually verifies.

When the agent's refund executes, Pruvz captures the claim and the decision-time policy snapshot, then a separate verification worker reads the billing and CRM systems of record inside a defined window with retries. The refund check requires exactly one succeeded refund matching the payment correlation, the amount, the currency, and the run; the CRM read is captured as a point-in-time snapshot of the customer state. A pending or unreadable source keeps the action verification-pending rather than misclassifying it as a mismatch, and the result becomes final on a terminal observation: verified, outcome mismatch, or verification failed. Only the verification worker assigns that result; the agent's claim never decides it.

Watch it catch a refund that never happened.

The recorded product demo runs this workflow twice with a live AI agent: one run where the refund is independently confirmed and classified as verified, and one run where the agent reports success while the billing system shows no refund, so Pruvz classifies an outcome mismatch and a human review decision closes the loop on the evidence trail. The public demonstration runs against deterministic sandbox source systems, a billing system and a CRM system with isolated state that resets per run. That is a deliberate strength of the demo: every verification path, including the failure paths, is reproducible end to end on demand, on the same verification engine and evidence model that will be applied to production systems of record with the founding design partners.

The evidence a refund leaves behind.

Every verified refund produces an evidence packet: the claim, the policy snapshot, the execution receipt, the independent billing and CRM read-backs with server-assigned trust levels, and the derived result, in an ordered, append-only sequence. The packet published on this site is a real one, captured from the product demo's refund workflow and explained field by field, with the public schema and a local validator. That is the artifact your operations, compliance, and finance teams read when someone asks, months later, whether a specific refund really happened.

How does Pruvz verify that an AI agent's refund really happened?

After the agent executes, an independent verification worker reads the billing system of record directly, read-only, inside a defined verification window with retries. The refund check requires exactly one succeeded refund matching the payment correlation, the amount, the currency, and the run; a successful CRM read containing all required fields is captured as an evaluable point-in-time snapshot alongside it. Only that read-back decides the result: the action is classified as verified, outcome mismatch, or verification failed, and the agent's own success report is recorded as a claim, never as proof.

Can Pruvz verify refunds in Stripe or my live billing system today?

Not off a shelf today, and this page will not pretend otherwise. The full refund verification flow runs end to end in the product demo against deterministic sandbox billing and CRM systems. Production connectors to live systems of record, such as Stripe and HubSpot, are exactly what the founding design-partner program exists to build: they will be selected and developed with the founding design partners, on the same verification engine and evidence model the demo runs.

What happens if a refund is reversed or disputed after verification?

The recorded result remains the record of what the billing system showed during the verification window, which is what an audit needs it to be. Later facts, such as a human review decision or an externally resolved dispute, are appended to the evidence trail as new entries and never rewrite the original result. Automatic re-verification of a source system after a final result is a planned, explicit capability on the roadmap; Pruvz does not claim continuous monitoring it does not do.

Does Pruvz issue, approve, or block refunds?

No. Pruvz never moves money, never executes corrections, and never approves or blocks an agent's action at runtime. It records what the agent claimed, verifies what the systems of record actually show, and routes mismatches to human review with the complete evidence attached, so your team resolves the discrepancy through normal business channels and the resolution becomes part of the record.