snapflip

Inspiration

Resellers carry all the risk. They buy inventory on a hunch, spend time listing it, and hope it sells. Tools like eBay’s AI lister, Vendoo, and Poshmark save typing — but none of them tells you, at the rack, whether a real buyer will pay for the item. Collectors have the opposite problem: they know exactly what they want and what they’d pay, but they have to keep refreshing marketplaces to find it.

We wanted the moment of discovery — a cartridge in a thrift-store bin — to meet the demand that already exists for it, instantly. And we wanted to test a real question for the Agentic Payments track: can an agent be trusted to commit actual money on its own, within limits a human has set?

What it does

SnapFlip is an order book for secondhand goods where AI agents bid on your thrift find while it’s still on the rack — it sells before you buy it.

• A collector sets a standing order in plain English: “Pokémon Yellow, cartridge only, authentic, good label, up to $45.” They can do it through Claude (our remote MCP server), a Brainbase-hosted concierge agent, or a web page — and grant a capped, expiring spending limit backed by a saved card.

• A reseller snaps a photo in Telegram. A vision model identifies the exact SKU and grades its condition (A–D), with flags like reproduction or water damage that can disqualify the auction.

• Every buyer agent whose standing order matches enters a 60-second ascending-clock auction. The price ticks up live; each agent drops out at its buyer’s true value for this item at this grade — and tells the buyer why (“grade B, capped at $32”).

• The seller watches the price climb, sees what they’d net after fees, and only then decides to buy the item. One tap confirms; the winner’s card is charged for real via an off-session manual-capture PaymentIntent. Funds release to the seller through Stripe Connect on delivery.

• If nothing clears the reserve, the seller walks away having lost nothing.

The result: price discovery happens before the reseller spends money — the risk is inverted. collectors, $ in standing demand, real transactions during the event (demo data excluded — the numbers are real).

How we built it

A single deployed Cloudflare Worker is the backbone — everything below is live at go.snapflip.workers.dev.

• Anthropic Claude (vision + text): identifies the exact SKU and grades condition from the photo, parses plain-English order rules into structured constraints (grade_caps, require, reject), and values each item against every matching order at auction time. An OpenAI-compatible fallback (Featherless), plus a request-hash response cache in D1, keeps the pipeline alive through API hiccups.

• Cloudflare: a Durable Object per live auction (alarm-driven price clock, hibernatable WebSockets fanning out the live bid tape to the seller and a public /a/{id} page), a Durable Object per buyer agent (Agents SDK), D1 for the order book, R2 for photos, Queues for match jobs, cron for sweeping stale payment holds, and a remote MCP server that collectors attach to Claude as a connector.

• Stripe: Checkout in setup mode saves the buyer’s card with a code-enforced spending limit. Off-session PaymentIntents with manual capture handle the full lifecycle — authorize on clear, capture on seller confirmation, void on timeout, refund pre-transfer, Connect Express transfer on delivery — reconciled by a signature-verified webhook.

• Brainbase: a hosted concierge agent (snapflip-concierge) that onboards collectors in chat and registers standing orders through our API.

Challenges we ran into

• Trusting a model with money. Our answer is split authority: deterministic code computes the hard cap from both the order maximum and the payment limit; the model can veto or lower a bid, but never raise it. A bad model response can never cause overspending.

• A real payment lifecycle in eight hours. Authorization without capture is a hold, not a charge. Confirm, void-on-timeout, refund, and Connect transfer are distinct states — plus an authorization-failure path where the next-highest agent wins at the same clearing price.

• Provider resilience under demo pressure. Model calls go through a provider chain with 20-second timeouts and a response cache, so retries and re-sent photos cost nothing. An API hiccup degrades gracefully instead of killing a live auction.

• Cold start on both sides at once. We attacked it the way the wedge works in production: recruit collectors first (demand is portable — a QR at our table), then let supply walk around thrift stores.

Accomplishments that we’re proud of

• A real transaction, cleared by agents in under 60 seconds — real buyer, real card, real cartridge, real Stripe capture.

• Agents with actual financial authority, not a chatbot. Buyer agents evaluate the item against their human’s rules and commit money autonomously, bounded by limits enforced in code — autonomy with guardrails.

• Three independent buyer surfaces — a Claude MCP connector, a Brainbase-hosted concierge, and the web — all writing to the same order book.

• The auction is watchable. A live WebSocket tape shows per-agent dropout reasons, with a Telegram override allowing a losing buyer to raise their cap mid-auction.

• The full money loop works end to end: limit → authorize → capture → ship → Connect transfer on delivery, with cron sweeping abandoned holds.

What we learned

• Agents that spend need a split brain. The model should propose and the code should dispose. Once we stopped asking “how do we make the model careful?” and instead made overspending structurally impossible, everything got simpler — the model can only ever veto or lower.

• Auction format determines agent complexity. We chose an ascending-clock auction because it makes truthful bidding the dominant strategy: each agent only needs to know its buyer’s true value. No sniping, no bid-shading, no game theory. Choosing the right mechanism let our agents stay simple and honest — and made for a better live show.

• “Charge a card” is five state machines in a trench coat. Auth vs. capture, expiring holds, refunds that are only safe pre-transfer — the payments lifecycle was the deepest code we wrote. Separate charges + transfers, rather than destination charges, are what let us hold funds until delivery.

• Demand first beats listings first. Every marketplace starts by chasing supply. Putting the order book before the listing inverts the cold-start problem — a seller doesn’t need our traffic because the buyers are already standing there with money committed.

What’s next for SnapFlip

• More exact-identity collectibles — vinyl pressings, LEGO set numbers, TCG. The catalog is a table, so each category is a data migration, not a rebuild. Sneakers once authentication exists.

• Shared Payment Tokens for buyer limits — the slot is already marked in settleAuction, pending whether SPTs support manual capture.

• Transfer-on-delivery with tracking integration, plus a buyer subscription for priority matching.

• Demand-data products. A real-time order book for secondhand goods is a dataset nobody else has: we know what collectors will pay before the item is even bought.

Built With

• brainbase
• claude
• cloudflare-agents-sd-k
• cloudflare-durable-objects
• cloudflare-workers
• featherless
• model-context-protocol
• stripe
• telegram-bot-api
• typescript