What Test Clocks Simulate
Test clocks compress time for billing logic, but not everything in a payment system is governed by billing logic. This page is the definitive list of what moves with the clock and what stays on real time.
What the clock animates
| Billing behaviour | Clock-animated? |
|---|---|
| Payment plan scheduling (next due dates) | ✅ Yes |
| Payment dispatch for card plans and subscriptions | ✅ Yes — card collection completes in sandbox |
| Subscription period rollover | ✅ Yes |
| Payment-link expiry | ✅ Yes |
| Dunning / retry schedules | ✅ Yes |
| Plan failure behaviour (retry dates, catch-up) | ✅ Yes |
Card is the fully animated payment method: when the clock dispatches a card payment, the sandbox processes it to a final outcome immediately, so a single advance takes a card plan through dispatch and result.
What the clock does not animate
| Behaviour | Why |
|---|---|
| BECS collection outcomes | Bank debits are inherently multi-day and externally governed — see below |
| Settlement, holds, payouts | Governed by real time and banking calendars; compressing them would misrepresent real cashflow |
| 3D Secure challenges | Require customer interaction; time alone can’t complete them |
| Refund timing | Refunds aren’t time-scheduled |
| Sandbox funds becoming spendable | Balances show in-transit and lodged amounts, but never advance to spendable in sandbox |
| Audit timestamps | created_at and similar always record real wall-clock time |
The BECS carve-out
If a clock-bound customer has a BECS payment plan or subscription, the clock schedules and dispatches those payments at simulated time — the scheduling side is fully clock-aware. But the collection outcome (success, dishonour, retry) does not fire from the advance: the payment stays in its post-dispatch state until the normal sandbox BECS pathway processes it on real time.
Practical implication: use a test clock to verify when BECS payments fire and how schedules behave; use the normal sandbox flow to verify BECS outcomes. Card plans can verify both in one advance.
Timestamps: simulated vs real
Two kinds of time appear on clock-bound objects:
- Scheduling fields (
frozen_time, next payment dates, period starts and ends, link expiry) — simulated time - Audit fields (
created_at,last_advanced_at) — real wall-clock time
A payment intent generated at simulated Feb 1 will show a real-world
created_at of whenever you ran the advance. This is expected.