paybondpaybond
Sign in

Use case

Refunds that happen automatically—and can still be explained.

When a run stalls, a tool errors, or output fails your checks, the fair default is often a refund. Paybond records the refund as a settlement outcome: criteria you defined, evidence you captured, and a decision you can walk through with support or a partner without reconstructing the story from chat logs.

Start now>View walkthroughExplore Harbor

Automatic doesn’t mean opaque.

Refund semantics that are deterministic, evidence-backed, and safe for operators to explain.

  • Refunds follow agreed rules

    A refund is a normal settlement path—not a one-off exception—when the predicates on your signed intent are not satisfied.

  • Partial progress, full trail

    Even if work stops halfway, artifacts and actions stay on the same intent so “what happened” does not get lost in side channels.

  • Support and ops can replay the call

    Reviewers see which checks failed and what evidence was available, without privileged database spelunking or screenshots.

  • Scoped to the right org and role

    Refund operations carry tenant and operator context from authentication through to exports so boundaries stay clear under audit.

How automatic refunds are determined

Refund decisions are just settlement outcomes—evaluated deterministically.

  1. Step 1

    Define failure modes

    Attach success and failure conditions to the signed intent as predicates, so the default is explicit before money moves.

  2. Step 2

    Capture evidence as you go

    Store signed artifacts and operator actions as the run proceeds so a later “no” is not a void.

  3. Step 3

    Evaluate with the same rules every time

    Run resource-bounded evaluation over that evidence so release versus refund is reproducible, not a gut call.

  4. Step 4

    Issue the refund

    Record refund as a named settlement outcome with provenance in the ledger, not a silent adjustment elsewhere.

  5. Step 5

    Report with confidence

    Use receipts and rollups for finance, partners, and risk to confirm refund volume and root causes over time.

Refund logic you can audit.

“Automatic” is only credible if the decision is inspectable: same inputs yield the same outcome, every touch is signable, and every API hop carries tenant context—so you can show your work to customers, auditors, and your own team.

Guarantees

  • Default outcomes come from the evaluation graph you ship, not from someone editing a dashboard after the fact.
  • Provenance links evidence and human steps so overrides stay visible, not off-books.
  • Every boundary derives tenant and operator scope from authenticated credentials, not from caller-provided labels alone.
Intent lifecycle docsLedger and provenance

Where it’s used

Make refund behavior predictable across workflows and integrations.

  • Agent execution failures

    Refund when tools error, policy blocks an action, or validation rejects output—without a manual ticket to decide each time.

  • Quality gates for deliverables

    Ship acceptance checks and refund when the bar is not met, with a record of what was delivered and what failed.

  • Customer-friendly defaults

    Give buyers predictable semantics and a defensible reason when the answer is a refund, not a debate.

Automatic refunds FAQ

Questions about refund semantics and evidence trails.

Are refunds always automatic?

No. You can make refund the default when predicates fail and still require operator sign-off, dispute flow, or an explicit override—recorded as its own attributable event on the same intent.

What if evidence is missing?

Define what “missing” means in your predicates—often a failed check or a refund path. The history still shows what was recorded so you can close instrumentation gaps with facts, not guesses.

Can I support partial refunds?

Yes, when your settlement policy models split outcomes. The important part is that the split maps to the same evaluation and provenance rules as a full refund.

Is this a substitute for network chargebacks?

No. This page is about the settlement and evidence story inside Paybond. Card-network disputes follow separate rules; Paybond gives you a consistent internal record you can line up with those processes.

How does this remain tenant-safe?

Decisions, evidence, and exports stay bound to the tenant and operator identity established at sign-in. Any cross-tenant access attempt is a critical security event and a hard boundary violation, not a recoverable oops.