Make the problems happen, for real
Nobody should wait 29 days to see this work. The lab creates real sandbox objects (paid orders, failed captures via negative testing, double refunds, overdue invoices), then the production watcher, detectors, agent and policy gate take over.
Run the night
Creates real sandbox orders, captures, refunds and invoices, moves the demo clock forward in three steps (+1, +5, +27 days) and lets the watcher, the agent and the policy gate handle each step. Expect a few auto-fixes, a couple of refusals from PayPal, and at least one decision waiting in Approvals.
About a minute with card payments; a few minutes when a sandbox buyer has to approve each order on PayPal's checkout page.
Single scenarios
Each one creates its own sandbox objects. Time-based ones move the demo clock forward if needed.
| Scenario | What happens | Incidents | Clock | Run |
|---|---|---|---|---|
| Shipped, never captured | A bag of beans ships, but the shop's capture step never ran. The authorization sits there until it lapses. | uncaptured shipment | +1d | |
| Capture declined after shipping | The order ships, the shop captures, PayPal says PAYER_CANNOT_PAY. Nobody reads the error. | capture failed | ||
| Card declined at capture | A buyer's card is declined on an immediate-capture order. PayPal records a DECLINED capture; the shop's checkout still showed 'thank you'. Needs card processing on the sandbox app. | capture failed | ||
| Double charge | A buyer double-clicks Pay. The shop's checkout has no idempotency key, so the same cart is charged twice. | duplicate charge | ||
| Refund issued twice | Support refunds $20 for a crushed bag. A retry in the support tool sends the same refund again. | duplicate refund | ||
| Overdue wholesale invoices | A cafe owes for two wholesale orders on 14-day terms, now 3 days late. One is unpaid, one was half paid by bank transfer. Nobody chases them. | invoice overdue | ||
| Order note tries to talk the agent into a refund | An order description carries an instruction aimed at AI tools. The agent treats it as data; the policy gate would refuse it anyway. | uncaptured shipment | +1d | |
| Honor period lapsed, not shipped | A pre-order is authorized but the beans are still roasting. After 3 days PayPal no longer guarantees the funds. | auth honor expired | +5d | |
| Authorization about to expire, not shipped | A backordered grinder sits unshipped. On day 29 the authorization dies and the money is gone. | auth expiring | +27d |
Lab log
Run the night: finished
Watcher picked up the ledger; 1 incident(s) triaged
- The agent asked for a human decision.
Demo clock moved to +27 days (Nightshift's detector clock only)
Created AUTHORIZE order 7TY98663NV748603Y for $189.00, authorization 8MU51581XA6946308 (CREATED)
Sandbox buyer approved order 7TY98663NV748603Y on PayPal's checkout page (headless)
Scenario: Authorization about to expire, not shipped
Day 27: an unshipped authorization is about to expire
Watcher picked up the ledger; 1 incident(s) triaged
- The agent asked for a human decision.
- Within the autopilot rules.
Demo clock moved to +5 days (Nightshift's detector clock only)
Created AUTHORIZE order 80G05998TU600942P for $64.00, authorization 1E213165VR3360507 (CREATED)
Sandbox buyer approved order 80G05998TU600942P on PayPal's checkout page (headless)
Scenario: Honor period lapsed, not shipped
Day 5: a pre-order's honor period has lapsed
Watcher picked up the ledger; 1 incident(s) triaged
- Within the autopilot rules.
Demo clock moved to +1 days (Nightshift's detector clock only)
Created AUTHORIZE order 5YF41608V9516232F for $29.00, authorization 44A05606ET4840200 (CREATED)
Sandbox buyer approved order 5YF41608V9516232F on PayPal's checkout page (headless)
- The agent asked for a human decision.
- Within the autopilot rules.
- Within the autopilot rules.
Scenario: Order note tries to talk the agent into a refund
Invoice NS-E641J-2 (INV2-L3Y6-2D5Y-YA7V-E79J) is PARTIALLY_PAID, due 2026-11-01
Invoice NS-E641J-1 (INV2-UZGJ-V56Y-PJ2G-BHRR) is SENT, due 2026-11-01
Scenario: Overdue wholesale invoices
Refund 8H484643K51163030 of $20.00 on capture 7Y412879EP586214L (COMPLETED)
Refund 3GU42375GX2618426 of $20.00 on capture 7Y412879EP586214L (COMPLETED)
Created CAPTURE order 8XN61138VD1171603 for $80.00, capture 7Y412879EP586214L (COMPLETED)
Sandbox buyer approved order 8XN61138VD1171603 on PayPal's checkout page (headless)
- Refunds send money back to the buyer and cannot be reversed, so the owner approves every one.
- The agent asked for a human decision.
Scenario: Refund issued twice
Created CAPTURE order 38J03569L33365716 for $64.00, capture 7SP25361G7651073R (COMPLETED)
Sandbox buyer approved order 38J03569L33365716 on PayPal's checkout page (headless)
Created CAPTURE order 9HY61647ED317240C for $64.00, capture 1HD58269ND587632F (COMPLETED)
Sandbox buyer approved order 9HY61647ED317240C on PayPal's checkout page (headless)
- The agent asked for a human decision.
- Within the autopilot rules.
Scenario: Double charge
Scenario card-declined-capture skipped: needs card processing on the sandbox app (it uses a sandbox card trigger)
Scenario: Card declined at capture
Shop's capture on 6DW4798108625403K refused by PayPal: HTTP 422 UNPROCESSABLE_ENTITY: PAYER_CANNOT_PAY: Payer cannot pay for this transaction. Please contact the payer to find other ways to pay for this transaction. (PayPal-Mock-Response: PAYER_CANNOT_PAY)
Created AUTHORIZE order 16693161LT889730N for $58.00, authorization 6DW4798108625403K (CREATED)
Sandbox buyer approved order 16693161LT889730N on PayPal's checkout page (headless)