“The payment went through. My ticket didn’t arrive.”
For a support team, that complaint starts a conversation with a worried customer. For an engineer, it starts a search across the checkout, the payment provider and the fulfillment database. A successful charge answers one question. The customer is waiting for the thing they bought.
CrashCart gives those teams a shared investigation workspace for the gap between payment and delivery. Start with the complaint, open the payment and ticket records, and work toward a clear answer: Promise kept, Promise broken, or More evidence needed. Each case keeps the observations behind that answer close enough to inspect, so a support handoff can carry the incident itself rather than a loose collection of screenshots.
The prototype focuses on a deliberately small purchase: one $29 workshop ticket, delivered within 60 seconds of a completed payment. The store is owned by the project, and every payment uses PayPal Sandbox. That concrete promise makes a subtle failure understandable: PayPal can complete a capture while the merchant loses the response and leaves the ticket undelivered. The customer can be paid up and still have nothing to use.
PayPal is central to investigating that failure. CrashCart creates sandbox orders, follows buyer approval and captures payment. It then reads the order independently to establish what happened at the provider, including the amount, currency and completion time. The merchant’s ticket is checked separately. Fixed rules compare those records with the original delivery promise; missing information stays unresolved. A confident explanation cannot turn an unknown payment into a successful one.
The AI investigator helps decide what to examine next. Modal-hosted DeepSeek proposes a hypothesis, requests an allowed check and revises its explanation as results arrive. In an actual investigation of a saved paid purchase, it read the provider record, asked for the missing delivery information, then connected the matching ticket to the payment. With unpaid records, it preserved the uncertainty. Its requests have explicit limits, and deterministic code makes the payment and delivery decision. The assistant cannot rewrite the promise or declare its own conclusion verified.
Once an engineer has a reproducible failure, CrashCart can turn the saved checkout into an offline regression package. That package runs without payment credentials or another charge. In a recorded response-loss case, the same input reproduced a missing ticket in the defective merchant and timely delivery in the repaired merchant. Replaying a saved checkout is clearly labeled, and a new sandbox purchase remains a separate test. This gives the next engineer something they can run while keeping the original incident intact.
AG Studio brings the investigation into a connected workspace. Custom widgets show recorded browser observations, provider records, the ticket, a comparison and the event trace. Its native assistant can filter saved investigations into an Answers widget, with code computing the matching rows. The interface keeps the customer outcome prominent, while technical details remain available when a developer needs them. Investigations survive a refresh, and stopping an investigation preserves what it has already collected.
CrashCart is a working local prototype with actual sandbox payments, real model analyses and executed offline replays. A complete KERNEL checkout now connects buyer approval, confirmed payment and the customer’s ticket in one recorded journey. Payment-notification verification and access to recordings inside the workspace are still being finished. Judge access and AG Studio licensing coverage are also pending. The current demonstration uses owned test purchases and saved incidents, with no customer data. The aim is a practical handoff: understand the missed promise, give the developer a reproducible case, and check the repair against that same promise.
Log in or sign up for Devpost to join the conversation.