March 28, 2026SecurityTransactions

Escrow Protection: Securing Agent Transactions

When an AI agent commits funds on behalf of a user, the stakes are higher than a typical checkout. The user did not click "Buy" - an agent did. If something goes wrong, the user's trust in the entire agent commerce model is at risk. This post explains how ACP's escrow system works, from the technical implementation to the dispute resolution mechanics.

Why agent commerce needs escrow

Traditional e-commerce relies on credit card chargebacks as the ultimate consumer protection. If a merchant fails to deliver, you dispute the charge with your bank. It works, but it is slow (45-90 days), adversarial, and expensive for everyone involved.

Agent commerce needs a faster, more structured protection mechanism for several reasons:

Delegation risk. When a user delegates purchasing authority to an AI agent, they accept a new category of risk - the agent might make a purchase they would not have made themselves. Escrow gives users a window to review and confirm agent-initiated purchases before funds are irrevocably transferred. Speed of transactions. Agents can complete transactions in seconds. A human shopping on a website takes minutes to hours, providing natural "are you sure?" friction. Escrow provides that friction programmatically - funds are committed but not released until conditions are met. Multi-party accountability. In agent commerce, there are three parties: the user, the agent, and the storefront. If a transaction goes wrong, who is responsible? Escrow creates a neutral holding period where all parties can verify that the transaction was executed correctly before funds move.

How ACP escrow works

ACP escrow is built into the transaction protocol. When an agent creates a transaction with escrow: true, the following sequence occurs:

Step 1: Escrow funding

The user's payment method is charged and the funds are held in an escrow account managed by ACP's payment partner. The funds are not accessible to the storefront. The transaction moves to ESCROW_FUNDED state.

POST /v2/transactions
{
  "negotiation_id": "neg_abc123",
  "escrow": true,
  "escrow_config": {
    "release_condition": "delivery_confirmed",
    "timeout_hours": 168,
    "auto_release": true
  }
}

The escrow_config object controls the release behavior:

release_condition specifies what must happen before funds are released. Options are delivery_confirmed (default), user_approved, or time_elapsed.

timeout_hours sets the maximum escrow duration. If the release condition is not met within this window, the escrow expires and funds are returned to the user. Default is 168 hours (7 days).

auto_release determines whether funds are released automatically when the condition is met, or whether the user must explicitly approve. Default is true.

Step 2: Order fulfillment

The storefront receives the order and begins fulfillment. As the order progresses, the storefront updates the transaction status through ACP:

POST /v2/transactions/txn_xyz789/fulfillment
{
  "status": "shipped",
  "carrier": "fedex",
  "tracking_number": "FX123456789",
  "estimated_delivery": "2026-03-30T18:00:00Z"
}

ACP verifies shipping status by polling the carrier's tracking API. This is not based on the storefront's self-reported status alone - we independently verify that the package is in transit and progressing toward the delivery address.

Step 3: Delivery confirmation

When the carrier confirms delivery, ACP updates the transaction to FULFILLED state and emits a transaction.fulfilled webhook. If auto_release is true, a release countdown begins (default: 24 hours). During this window, the user can inspect the product and raise a dispute if something is wrong.

Step 4: Fund release

If no dispute is raised during the release window, funds are transferred to the storefront. The transaction moves to RELEASED state. The storefront receives a transaction.released webhook and can reconcile the payment against their records.

The dispute resolution process

If something goes wrong - the product does not match the description, it arrives damaged, or it never arrives at all - the user or their agent can open a dispute.

Filing a dispute

Disputes can be filed by the user directly or by the agent acting on the user's behalf. The dispute includes a reason code and evidence:

POST /v2/transactions/txn_xyz789/disputes
{
  "reason": "product_not_as_described",
  "description": "Product listing showed genuine leather; received faux leather",
  "evidence": [
    {
      "type": "image_url",
      "url": "https://user-uploads.example.com/dispute_photo_001.jpg"
    }
  ]
}

Reason codes include: product_not_as_described, product_damaged, product_not_received, unauthorized_transaction, duplicate_charge, and other.

Resolution process

When a dispute is filed, the escrow is frozen - funds cannot be released to the storefront. The resolution process follows a structured timeline:

Days 1-3: Storefront response. The storefront receives a dispute.opened webhook and has 72 hours to respond. They can accept the dispute (triggering an immediate refund), reject it with counter-evidence, or propose a resolution (partial refund, replacement, etc.). Days 4-7: Mediation. If the storefront rejects the dispute, ACP's automated mediation system evaluates the evidence from both parties. The mediator considers the storefront's trust score history, the user's dispute history, the evidence provided, and the product category's typical dispute patterns. Day 7+: Resolution. The mediator issues a binding resolution: full refund, partial refund, or dispute rejected. Funds are disbursed accordingly. Both parties receive detailed reasoning for the decision.

Dispute economics

Disputes are expensive for storefronts. Each dispute, regardless of outcome, incurs a $2.50 processing fee. Storefronts with a dispute rate above 1% of transactions are flagged for review and may see their trust score reduced. Storefronts with a dispute rate above 5% are suspended pending investigation.

This economic structure incentivizes storefronts to maintain accurate product data, fulfill orders reliably, and resolve issues proactively before they escalate to formal disputes.

Fraud detection

ACP's escrow system includes automated fraud detection that runs on every transaction. The fraud engine evaluates signals including:

Velocity checks. Unusually high transaction volumes from a single agent, user, or storefront trigger review.

Amount anomalies. Transactions significantly above a storefront's typical order value are flagged.

Pattern matching. Known fraud patterns (e.g., high-value orders to new shipping addresses, bulk purchases of easily resellable goods) trigger additional verification.

Cross-reference signals. The fraud engine cross-references agent behavior, user history, and storefront trust scores to compute a composite fraud risk score.

Transactions flagged as high risk are held for additional verification. In practice, this affects less than 0.3% of transactions and adds 1-2 minutes of processing time. The false positive rate is under 0.1%.

Escrow for negotiated transactions

Escrow interacts with the negotiation protocol in a specific way. When an agent negotiates a discounted price and then creates an escrowed transaction, the escrow is funded at the negotiated price, not the list price. The negotiation record is linked to the transaction, creating an auditable chain from price agreement to payment.

If a dispute arises on a negotiated transaction, the mediation system considers the negotiation context. For example, if a storefront offered a "final sale, no returns" condition during negotiation and the agent accepted, that condition is factored into the dispute resolution.

Implementation details

Payment processing

ACP escrow uses a licensed payment facilitation model. Funds are held in FBO (For Benefit Of) accounts at our banking partner, segregated per transaction. ACP never commingles escrow funds with operating funds. All escrow accounts are subject to quarterly audits.

Timeout handling

Escrow timeouts are critical safety mechanisms. If a storefront never fulfills an order, the escrow must eventually return funds to the user. The timeout clock starts when the escrow is funded, not when the order is placed. When a timeout occurs:

The transaction moves to ESCROW_EXPIRED state.

Funds are automatically returned to the user's payment method.

The storefront receives a transaction.escrow_expired webhook.

The incident is recorded in the storefront's trust score history.

Partial releases

Some transactions involve partial fulfillment - for example, a multi-item order where some items ship immediately and others are backordered. ACP supports partial escrow releases:

POST /v2/transactions/txn_xyz789/release
{
  "type": "partial",
  "amount": 4500,
  "line_items": ["item_001", "item_002"],
  "reason": "partial_fulfillment"
}

The remaining escrow balance stays locked until the rest of the order is fulfilled or the timeout expires.

What's next

We are working on several enhancements to the escrow system:

Instant refunds. For disputes on orders from Platinum-certified storefronts, we plan to issue instant refunds from a pre-funded pool, rather than waiting for the full dispute resolution process.

Escrow for subscriptions. Extending the escrow model to recurring transactions, with per-period holds and automated release on service delivery.

Multi-currency escrow. Supporting escrow accounts denominated in multiple currencies, with automatic conversion at the best available rate at time of release.

Questions about ACP escrow? Reach out at developers@cresva.ai or join our GitHub discussions.