← All use cases

Escrow providers · PSPs · platforms on Stripe Connect

Escrow without adjudication is a timelock

Every escrow product has the same missing sentence in its docs: what happens when the parties disagree. Recourse is that sentence — a signed money instruction your rails execute, with our liability behind it, never touching the funds.

Escrow is easy until it isn't. Holding funds is a solved problem; deciding who gets them when the buyer says "not as described" and the seller says "exactly as described" is the part every escrow provider improvises — an ops queue, an email thread, a coin flip with a support macro. Until then the product is a timelock, not an escrow.

Recourse completes the product: your customers agree to the venue in your flow, your systems hold the funds as they already do, and when a dispute opens, the evidence bundle comes to us. Minutes later your endpoint receives one signed instruction — release, refund, or split, summing exactly to the held amount — ready to execute on your rail.

The lifecycle, end to end

1. POST /disputes            → ruling issued (Tier 1, minutes)
2. webhook → your endpoint     escalated: true?  → you HOLD (draft pending our bench)
3. bench final ruling          → superseding webhook, escalated: false
4. you EXECUTE                 rail_instruction, verbatim:
     escrow_webhook   → split against held funds
     stripe_connect   → transfer to connected account + refund on the PaymentIntent
     tempo            → stablecoin transfer intents, dispute id in the memo
     x402             → facilitator settlement splits

HMAC-signed, idempotent on event_id, replay-protected, at-least-once. The reference receiver in our integration kit implements the whole contract in ~80 lines.

Why partner rather than build

One endpoint turns a mess into a decision.

Get API access Read the docs