ReCart

When a part goes missing, ReCart rebuilds the whole order, asks the buyer again, and settles once on PayPal.

Comment

Inspiration

A podcaster orders two microphones, an audio interface, headphones, cables and stands. At the packing check, the interface is missing. Sending the next interface can quietly break the whole setup: a USB-B model needs a different cable and an adapter; a cheaper one may lack the routing a remote guest needs; a pricier one may break the budget.

Meanwhile, the buyer's money is still held for an order the store cannot fulfill. We built ReCart to recover both the working setup and the payment.

What it does

ReCart rebuilds the whole purchase when one part goes missing, explains every change, and asks the buyer to approve the exact new version before settling the money on PayPal.

  1. Confirm the need. An AI drafts requirements from the buyer's words and quotes the text behind each value. The buyer fills in anything missing and confirms the form.
  2. Check the whole setup. A deterministic solver tries every in-stock combination allowed by the store's recipes against eleven checks, including connections, microphone inputs, remote-guest routing, operating-system support, stock, deadline and the all-in budget. The filmed example tries 480 combinations and finds 12 complete setups.
  3. Hold before charging. PayPal authorizes the total. The store must confirm the exact goods before the deadline for the payment to be captured.
  4. Recover with fresh consent. If a part is missing, ReCart releases the original hold before a new payment can start, proposes a complete replacement, shows the changed parts and price difference, and asks the buyer to approve again.
  5. Stop when necessary. If the only complete fix exceeds the budget, ReCart asks instead of raising the limit. If nothing works, it releases the hold and charges nothing.

The same planning engine is available through a REST API and a remote MCP server. Agents can draft requirements and propose recoveries; they cannot approve a proposal or move money. External stores retain their own inventory, orders and checkout. The hosted guided demo is a separate, self-contained shop that executes the PayPal Sandbox payment flow.

How we built it

The server uses TypeScript, Fastify and PostgreSQL, with a React front end. A signal-path diagram shows which connections fail when a part goes missing, and the guided demo derives its next step from the server's records.

PayPal JS SDK v6 opens server-created Orders v2 orders with AUTHORIZE intent. The store confirms before capture; otherwise ReCart voids the authorization. A capture confirmed at or after the fulfillment deadline is fully refunded. Every PayPal call is a persisted operation with its own PayPal-Request-Id. An uncertain reply is reconciled with PayPal before the next step, and verified webhooks trigger reconciliation rather than deciding the payment state themselves.

AI has two bounded jobs: drafting requirements and explaining a recomputed bundle. The primary provider is GPT-6 Luna through our own OpenAI-compatible gateway, with Claude Haiku 4.5 on an Astropods-hosted agent as the backup. Code resolves dates, asks about ambiguity and conflicting budgets, and checks that quoted words actually name the proposed value. A quote saying "USB-C laptop" cannot establish macOS. Explanations are checked against the solver's amounts and products and use the visible setup names, "Fewest changes" and "Alternative"; a deterministic template takes over when a check fails. The model does not select products, declare that no solution exists, or change payment state.

The platform exposes REST, OpenAPI 3.1, signed merchant webhooks and Streamable HTTP MCP over shared services and scoped keys. An independent Python sample store integrates through the public API. A Shopify development-store example reads catalog and stock through the Admin API; it does not edit Shopify orders or handle Shopify checkout or payments.

Challenges

A payment can succeed while its reply disappears. We deliberately discarded a real PayPal Sandbox capture response. ReCart reconciled the unknown outcome, and PayPal showed one capture. Keeping payment operations durable matters more than retrying an HTTP request.

A slow explanation must not block money. We separated payment and language work into durable job lanes, aligned proxy timeouts with the allowed call budget, and bounded shutdown. Tests exercise concurrency and a process killed mid-transaction.

A quote can be accurate and still fail to support a value. Our extraction checks now require both an exact quote and support for the field being populated. Unknowns become questions. Our evaluation also exposed ambiguous dates, conflicting budgets and a bug in our own scorer; we published the failures and corrections.

Sandbox webhook delivery needed a relay. PayPal Sandbox deliveries did not reach the demo domain. An Astropods-hosted agent relays the original event bytes, and the ReCart server still verifies the signature with PayPal before using the event.

Accomplishments

  • Recorded real PayPal Sandbox authorize, capture, void and refund paths, recovery after a lost capture reply, and verified webhooks. Public evidence links the resource IDs and recorded results.
  • In 20 frozen, team-authored cases on fictional products, the deterministic solver classified all 20 correctly and solved all 14 feasible cases with the exact expected bundle and total. It produced no invalid payable bundles in those cases.
  • Across 19 recovery cases, whole-bundle recovery found 14 complete solutions; replacing only the missing item found 8. The extra solutions needed dependent changes such as a cable and host adapter.
  • Claude Haiku 4.5 extraction got 17/20 whole cases right on the untouched first pass. After examining those failures, the revised product path reached 20/20 on the same cases, then 8/8 on a fresh holdout. The later scores include deterministic checks after the model. These are small, builder-authored engineering fixtures, not a real-user study or an accuracy claim for GPT-6 Luna.
  • Release 17 passes 261 automated checks: 232 for the TypeScript app and 29 for the hosted agent. Stories A, B and C were re-run against the public release on October 24: A and B recovered, while C closed with its original hold voided and no capture. Type checking and the build also pass. Checks cover payment recovery, idempotency, merchant isolation, signed webhooks, MCP, language fallbacks and shutdown behavior.

What we learned

Payment correctness lives in the unhappy paths: lost replies, late events, expired holds, ordering and restarts. Keeping AI in a narrow, checkable role made it useful without giving it authority over compatibility or money. Exact quotes help, but their meaning still needs checking.

What's next

We want to test real merchant catalogs with reviewed compatibility facts, interview merchants before making commercial claims, add self-serve production keys, and run the five-person comprehension check that remains unperformed.

Demo and evidence

  • Try the guided demo, read the judge's guide, or inspect the evidence.
  • Watch the 2:51 demo film.
  • Public source code, under the MIT License.
  • The live demo is release 17 (r2026.10.24-signal-room-17). The 2:51 film was recorded live on October 23, 2026 against release 16 and PayPal Sandbox. Its "229 automated checks" figure is the historical snapshot shown at recording time. Story A combines two disclosed takes, stories B and C are separate runs, waits are cut and labeled, and three shots hold recorded frames still.
  • The products, prices, stock and store are fictional. PayPal resources are real Sandbox resources; no real money moves. The demo does not establish physical equipment compatibility, customers or commercial readiness.

Built With

Share this project:

Updates

Submission history