Skip to content

PayPal sandbox only. No real money moves.

ProveProof

The 30 day simulation

Eight scenarios on a fake PayPal and a fake clock. Labelled SIMULATED.

Simulatedour code over a model of PayPal on a fake clock

Page last changed 7 Nov 2026 (from the git history)

30 day simulated timeline

SIMULATED
30 day simulated timelineEight simulated scenarios on a day axis from day 0 to day 32, run on a fake PayPal with a fake clock. Each row shows holds as hatched bars and captures as solid blocks. Dashed lines mark the model's 3 day honor period and 29 day validity. The bottom shows the totals of scenario S8 and that the ledger balances. This is a simulation, not real traffic and not the PayPal sandbox.SIMULATED: fake PayPal, fake clock. Not real traffic, not sandbox.Day 0Day 4Day 8Day 12Day 16Day 20Day 24Day 28Day 32honor period ends, day 3 (model)valid until day 29 (model)S1 hold day 0, capture day 16/6 PASSS2 close day 2.5, inside honor period6/6 PASSS3 capture day 3.5, reauthorized8/8 PASSS4 reauth day 3, capture day 55/5 PASSS5 never reauthorized, day 306/6 PASSS6 crash and restart at day 210/10 PASSS7 late expiry webhook, day 315/5 PASSS8 40 lots, 100 bidders, crashes7/7 PASSdiamond: reauthorize. cross: process crash. solid: capture. hollow block: hold released or expired. hatched bar: hold open.S8 TOTALS (read from SIM-MULTIDAY.md)40 lots, 100 bidders: 40 settled, 0 in review. 294 holds, 94 reauthorize calls, 51 crashes survived, 31 PayPal faults armed.3 lots used the runner-up. 8 of 8 injected rate-limit storms settled after a restart.balances to the centheld $159,385.00 = captured $34,170.00 + released $125,215.00 + open $0.00Fault positions inside the 30 days are random (seed 20261107) and are not in the file, so they are not drawn.heldchargedreleasedneeds review

Scroll the figure sideways, or open it full size.

What this shows: the settlement code kept its invariants under injected crashes and faults, on a model of PayPal. What it does not show: real PayPal behaviour over days. That is gate G3, still in progress. The honor period (3 days) and validity (29 days) are assumptions of the model, not PayPal facts. Figures are read from docs/evidence/SIM/SIM-MULTIDAY.md (seed 20261107).
Text version of this diagram

Everything here is simulated: a fake PayPal and a fake clock.

  • S1: hold day 0, capture day 1. 6/6 checks, PASS.
  • S2: close day 2.5, inside honor period. 6/6 checks, PASS.
  • S3: capture day 3.5, reauthorized. 8/8 checks, PASS.
  • S4: reauth day 3, capture day 5. 5/5 checks, PASS.
  • S5: never reauthorized, day 30. 6/6 checks, PASS.
  • S6: crash and restart at day 2. 10/10 checks, PASS.
  • S7: late expiry webhook, day 31. 5/5 checks, PASS.
  • S8: 40 lots, 100 bidders, crashes. 7/7 checks, PASS.

S8 ran 40 lots: 40 settled, 0 in review. 294 holds, 94 reauthorize calls, 51 process crashes survived, 31 PayPal faults armed, 3 lots used the runner-up fallback, 8 of 8 injected rate-limit storms settled after a restart.

Ledger: held $159,385.00 = captured $34,170.00 + released $125,215.00 + open $0.00.

What it is

The settlement saga, the reauthorization pass, the journal stores and the webhook merge run over simulated days against a model of PayPal's authorization rules, in seconds, with an injected clock. The model is the fake PayPal with these assumptions: honor period 3 days, authorization valid 29 days, reauthorize allowed only after the honor period and answered with a new authorization id, capture after validity fails.

Simulated scenarios on a fake PayPal and a fake clock.
ScenarioTitleChecksResult
S1Hold at day 0, capture at day 16/6SIMULATED PASS
S2Auction closes at day 2.5, capture before the honor period ends6/6SIMULATED PASS
S3Capture at day 3.5, after the honor period, with reauthorization8/8SIMULATED PASS
S4Capture at day 5 after reauthorization at day 35/5SIMULATED PASS
S5Hold never reauthorized, capture at day 306/6SIMULATED PASS
S6Server crash and restart between hold and capture at day 210/10SIMULATED PASS
S7Webhook for an expired authorization arriving late5/5SIMULATED PASS
S830 simulated days, 100 bidders, random crashes7/7SIMULATED PASS

S8: thirty days, a hundred bidders, random crashes

Forty lots, 100 bidders, a 3 percent crash chance at every boundary, outages of 1 to 4 days in 5 percent of crashes, and random PayPal faults. Every fifth lot gets two injected rate-limit (429) answers on its first capture and a restart after a two hour outage. The figures on the timeline above are read from the committed file.

Process crashes in this suite are exceptions at a saga boundary: they are not real process kills.

Edit on GitHub

Last updated on

Gate G5: speech accuracy partial

Is speech-to-text accurate enough to accept bids without confirmation? Not proven. On synthetic audio the numbers now meet the limit, but they were tuned on the same clips. Real numbers, method and limits.

Latency in progress

Measured PayPal sandbox latency and the targets it does not meet.