The Trust Problem in AI Marketplaces (And How Credit Escrow Fixes It)

Marketplaces that connect buyers with custom agents, fine-tuned models and automation work have a basic problem: the buyer wants to pay after the work is delivered, and the seller wants to be paid before they spend compute on it. Without a neutral middle layer, a lot of deals never happen.

That middle layer is escrow. It used to be enough work that many teams skipped it. With a credit ledger, it's a few API calls.

Why trust is the bottleneck

In a physical-goods marketplace, the buyer confirms receipt and disputes are a known cost of doing business.

AI work is different. The "product" is a computation — a model run, a data enrichment job, a generated video. It's consumed instantly and can't be returned. If the buyer pays first and the output is poor, they have little recourse. If the seller delivers first and the buyer disappears, the seller eats the compute cost.

That asymmetry shows up in three ways:

1. Low fill rate: buyers browse but don't buy because they're unsure of quality.
2. Seller churn: good sellers move to direct deals where they control payment terms.
3. Leakage: transactions move off-platform, and the marketplace loses its take rate.

How credit escrow works

Escrow isn't new. Doing it with credits instead of cash is what makes it cheap to build.

On cred.diy:

1. A buyer buys marketplace credits through hosted checkout.
2. When they order a job, your platform places a hold for the quoted amount. The credits leave the buyer's available balance but don't move to anyone yet.
3. If the output meets your acceptance rules, your platform captures the hold and settles the credits to the seller.
4. If the job fails or is disputed, your platform releases the hold and the credits go back to the buyer.

Each step is a single ledger operation, and the marketplace — not the buyer or the seller — decides when to capture or release. You set the dispute rules, review windows and seller tiers without touching a bank API.

Why credits rather than cash

• No settlement delay: capturing a hold is a ledger write, so a seller's balance updates as soon as you capture — there's no card or bank settlement step between buyer and seller inside your platform.
• Small amounts work: card fees make very small cash holds uneconomic. A hold of a few credits costs nothing extra, which makes single prompt runs and quick evaluations viable.
• One wallet across your apps: end users are identified by email within a project, so credits earned in the marketplace can be spent in your other apps on the same project.

A minimal implementation

The buyer and seller are end users in your project; your server holds the API key.

Step 1 — The buyer funds their wallet through hosted checkout. cred.diy credits their balance when payment completes.

Step 2 — Place a hold when the order is placed:

curl -X POST "https://eutdgemlrpvnxfkkpvlu.supabase.co/functions/v1/credits-api/escrow/hold" \
  -H "x-api-key: sk_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "user_email": "buyer@example.com",
    "credit_type_id": "ct_abc123",
    "amount": 50,
    "reference_id": "order_789"
  }'

The response includes a hold_id and the buyer's new available balance.

Step 3 — Capture or release after delivery. If the job is accepted, capture it to the seller:

curl -X POST "https://eutdgemlrpvnxfkkpvlu.supabase.co/functions/v1/credits-api/escrow/capture" \
  -H "x-api-key: sk_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{ "hold_id": "hold_abc123", "to_user_email": "seller@example.com" }'

If it fails, release it back to the buyer with POST /escrow/release and the same hold_id.

Step 4 — Don't leave holds open forever. Decide how long a hold may stay open, and release the ones your policy considers abandoned. GET /escrow?status=held lists the open ones.

Dispute policy

The hard part of escrow is the policy, not the engineering. Who decides whether a deliverable is good enough? Some options:

• Auto-approve after a review window: if the buyer doesn't flag the job within, say, 24 hours, capture it.
• Reputation-based windows: longer reviews for new sellers, faster capture for established ones.
• Partial capture: capture part of the hold for partly acceptable work; the remainder is released to the buyer automatically.

What to measure

Escrow changes buyer and seller behaviour, so track it before and after launch:

• Fill rate: the share of listings or quotes that turn into paid orders.
• Dispute rate: the share of holds released or partly captured after a complaint.
• Time to capture: how long sellers wait to be paid.
• Leakage signals: repeat buyer–seller pairs who stop transacting on the platform.

These numbers tell you whether your review windows and dispute rules are set right.

The bigger picture

AI marketplaces compete on the quality of their supply and on how safe it feels to transact. Reviews and badges help with the first. Escrow handles the second without building a payments company.

Read the escrow docs and add holds to your marketplace.