Investigate
Collect evidence from the systems involved. Keep observations separate from established facts.
Resolve In Development
When financial systems disagree, someone still has to decide what happens next.
Resolve handles consequential operations that cannot safely continue: the outcome is uncertain, a required condition is not met, or the next valid action cannot yet be established. It gathers evidence, establishes what is known, applies policy, and determines what can safely happen next.
Status: In Development
Resolve is designed and being built. This page describes how it is designed to work. Today, operations with
an uncertain outcome surface as explicit statuses (such as processing or
requires_action) together with payment timelines and attempt history, rather than being reported
as success or failure. The governed case layer described below is not yet available.
Problem
When automation stops, operations begins.
Financial systems automate the happy path well. But some operations reach a point where systems disagree, evidence is incomplete, or policy prevents them from continuing. Then people open multiple systems, reconstruct what happened, and decide what is allowed.
- A payout times out, but may still settle.
- A withdrawal fails and it is not clear whether retrying is safe.
- A refund is accepted and later reversed.
- The PSP reports one state while the ledger reports another.
- Settlement does not match what was expected.
- A customer says the money never arrived, and the evidence is spread across three systems.
Principle
Proof establishes evidence. Reconciliation detects divergence. Resolve governs what happens next.
Not generic error handling
Retry systems recover failed attempts. Resolve handles the cases where you first need to establish whether retrying, or doing anything else, is safe. Ordinary validation failures do not become Resolve cases.
The question it answers
Can the previous action still create an economic effect? That question decides whether retrying, rerouting, refunding or continuing is safe. It is a question about finality and evidence, not workflow status.
How it works
Verification first. Resolve only when it is needed.
- Expected state Ledger and execution record
- Reconciliation Compared with observed provider reality
- Match Verified outcome
- Mismatch or ambiguity Resolve case
Establish
Determine what is known, what is unknown, and whether the prior attempt is final.
Decide
Apply resolution policy and authority to choose a disposition.
Verify
Observe authoritative evidence after the owning system acts, and confirm the result.
Dispositions: continue · wait · remediate (retry, compensate, reverse) · escalate to a person.
Example
An uncertain payout.
A payout is sent to Provider A. The request times out. Failing over to Provider B could pay the beneficiary twice. Waiting may never produce an answer.
- Payout sent Provider A
- Timeout Outcome unknown
- Resolve Is the attempt final? What evidence exists? Is a retry safe?
- Disposition Safe next step or explicit escalation
Resolve does not turn uncertainty into a guess. If the evidence cannot support a conclusion, the case stays explicitly unresolved and goes to a person.
Architecture
Domains execute. Resolve governs uncertainty.
Signals are not authority
PSPs, banks, ledgers, KYC, fraud and support systems inform Resolve. Their signals are evaluated under policy; none becomes authority by default.
Authority stays with the owner
Resolve investigates and decides. The system that owns the operation executes the remediation. Recommendation, decision and execution stay distinct.
AI assists, it does not decide truth
Governed intelligence can help investigation and reasoning. It is never a source of financial truth or authority.
Adoption
Start with one exception flow.
Resolve sits alongside your PSPs, orchestration, ledger, and risk and compliance systems. None of them is replaced. Begin with one bounded operational problem rather than an infrastructure migration.
For developers
Inspect how to integrate it.
The v4 API is described by an OpenAPI contract. Start with the quickstart, then the parts that matter in production: errors, webhooks and the sandbox.
- Quickstart Authenticate, choose an environment, create a payout.
- API reference Representative v4 routes, objects and lifecycle statuses.
- Errors Errors versus unknown outcomes, and when retrying is safe.
- Webhooks Signatures, at-least-once delivery, retries and ordering.
- Sandbox Deterministic test provider, including failure outcomes.
- Integrations Providers, rails and channels in the catalog.
Show us one exception your team still investigates by hand.
We will map how it is resolved today and what Resolve could govern.