An expired invoice, four different clocks
Move four fictional payment records around an invoice deadline. See which times are before, at or after the cutoff, and what those times cannot decide.
A clock exercise, not a payment checker. All ten cases are fictional. Nothing here sends a payment or reads a wallet. A checkout deadline does not erase an ordinary Litecoin output or tell you to pay again.
Choose a situation
Load a case, then change one clock. The original service snapshot stays separate from your edited lesson.
Include seconds and Z or an explicit offset. For example, 12:15:00+02:00 and 10:15:00Z describe the same instant.
Each control uses whole seconds relative to the deadline: negative is before, positive is after. Range: −1800 to +1800 seconds.
A sender’s record, rather than proof of the receiver’s arrival time.
This receiver’s first record. Another node may have seen the payment earlier.
A separate observer sees block inclusion. This is not the block header time.
A fictional internal service record; an explorer cannot establish it.
Edits stay in this page’s memory. Reloading starts again. The controls are for invented examples; they are not a place to record an actual invoice.
Read the clocks separately
Loading the fictional clocks…
| Record | UTC instant | Relative to the deadline |
|---|
Acceptance is a separate question
A before/after label does not establish credit, order fulfillment or a refund. At exactly zero seconds, ask how the service treats its cutoff and what its full-resolution record shows.
Try changing just one record
The sender says “before,” but the receiver says “after.” Which one is wrong?
Neither has to be wrong. Case I03 places the sender’s report 20 seconds before the cutoff and the receiver’s observation eight seconds after it. These are two different records. Ask which event the actual invoice terms use; another observer’s time cannot prove this receiver’s earlier awareness.
What happens at exactly zero seconds?
Choose I05 or move the receiver’s clock to zero. The arithmetic says “at the deadline.” It supplies no inclusive or exclusive cutoff rule. Whole-second records can also hide finer timing. The receiver’s policy and evidence are still needed.
Can the confirmation observer see a block before the receiver sees the payment?
Yes, these controls deliberately describe separate observers. Try a broadcast at −60, confirmation observation at −20 and receiver observation at +10. A receiver that was offline or delayed may notice the already included payment later. That does not change the receiver’s original observation time.
What the simulator checks
- The four entered times use aligned clocks and refer to one fictional payment. If a known observation precedes its reported broadcast, the lesson asks you to correct the record instead of silently moving it.
- The same receiving service cannot credit this payment before its own first observation. Credit is not forced to wait for the separate confirmation observer: the simulator does not invent a service’s confirmation policy.
- Unknown stays unknown. It does not become zero, “not sent,” “failed” or permission to retry. No first-seen time for the entire Litecoin network is calculated.
- The block header timestamp remains separate metadata. It is never used to prove checkout arrival. Addresses, networks and amounts are not validated by this clock exercise.
- Changing the timeline does not predict a new merchant outcome. The original case’s status is supplied fictional evidence, not an output of the clock arithmetic.
The ten starting cases come from our invoice-expiry guide. Its method and limitations, offline reproducer and simulator input cases are public. No real payment, processor test or support outcome was measured.
Primary references: Litecoin Core’s header timestamp field, BitPay’s invoice fields and its distinct invoice states. BitPay is a policy example; this tool does not simulate its acceptance rules.