VERIFIEDRetry not needed
One matching economic effect is independently proven.
Exactly one external effect, linked to exactly one ledger posting, with matching authorization binding and passing receipt integrity.
Payment recovery · evidence & verdicts
Can your workflow prove zero, one, or unknown effects after a timeout?
A provider can prove its own request state. The hard part is proving one economic outcome across the provider, the external rail, the recipient, and the customer ledger — before an automated retry is permitted.
A method and a published sandbox result — not a payment processor, not a custody service, and not a claim of universal exactly-once execution.
The chain that must agree
One intent, four systems, one outcome
A verdict is only as strong as the weakest independently observed link in this chain.
- 01
Provider
Was the request accepted?
Provable by the provider alone. This is the only link most systems can prove.
- 02
External rail
Did money actually move?
Must be observed independently, never inferred from acceptance.
- 03
Recipient
Was the credit received?
Confirms the effect landed where the intent said it should.
- 04
Customer ledger
Is it recorded exactly once?
One posting linked to one intent — or the books disagree with reality.
provider → external rail → recipient → customer ledger
Four verdicts
Replace “it probably worked” with a named verdict
Every post-timeout state resolves into exactly one of four verdicts, and each verdict says clearly whether a retry is allowed.
SAFE_TO_RETRYRetry permitted
Zero external effects and a pre-effect rejection are proven.
The request was refused before any movement occurred and no ledger posting exists, so a new attempt cannot duplicate an effect.
UNVERIFIEDRetry blocked — investigate
The provider accepted, but the expected external effect is absent.
Acceptance is not finality. Until the effect is observed independently, the outcome is not established either way.
RECONCILE_REQUIREDBlind retry blocked
The effect may have happened or evidence disagrees, so blind retry remains blocked.
Sources conflict or observation is unavailable. The path stays closed to automation until reconciliation produces a single answer.
Public sandbox proof
24 attempts, one effect, one posting
A published sandbox run where 24 concurrent retry attempts contend for one payment intent.
24
retry attempts
1
durable reservation owner
23
stale or duplicate attempts rejected
1
external rail effect
1
linked customer-ledger posting
PASS
receipt integrity
Boundary of this result
These numbers prove only the declared sandbox boundary. They do not prove universal exactly-once execution, and they say nothing about any production system, provider, or rail outside that boundary.
Seven-question self-test
Where does your workflow lose the answer?
Any question you cannot answer with a confident yes is a place where an automated retry can create a second economic effect.
- 1Is authorization bound to the exact amount, recipient, target, and action?
- 2Is one execution owner durably reserved before dispatch?
- 3Can stale workers be fenced after timeout or restart?
- 4Is provider “accepted” kept separate from settlement finality?
- 5Can the external economic effect be observed independently?
- 6Does an unknown outcome block blind retry?
- 7Can another process replay the evidence and reach the same verdict?
Downloads
Take the materials with you
Plain text and JSON, no form required.
Plain textAmbiguous Payment Recovery Self-TestSeven questions with YES / NO / UNSURE scoring and the verdict vocabulary, ready to fill in during a review.Download →Plain textCross-System Payment Proof CardThe four systems that must agree, the evidence fields to collect per attempt, and the rules for each verdict.Download →Machine-readable JSONSample JSON proofA complete sandbox proof record: intent binding, attempt counts, observations, receipt integrity, and verdict.Download →
Request the kit
Send one answer, get the full kit
Tell me which transition goes unknown in your workflow after a timeout. It shapes what gets published next.
- · No submissions are stored by this site.
- · No newsletter subscription, automatic or otherwise.
- · Consent is explicit, required, and never pre-checked.
- · Privacy statement is one short page.