FICTIONAL EXAMPLE · NOT A LIVE RECEIPT

See the record before you make one.

This example shows how a custom-order deposit promise can read after a merchant reviews it. It was not submitted, has no verification URL, and is not evidence of a real transaction.

Start with blank terms Ask a seller in writing
FICTIONAL · NOT ISSUED · NOT VERIFIED

CUSTOM ORDER / DEPOSIT

Northstar Studio (example)

EXAMPLE ONLY
Public reference
SAMPLE-CUSTOM-01
Total
GBP 400.00
Due now
GBP 100.00 deposit
Remaining
GBP 300.00 on final-proof approval, before production
Delivery
10–15 business days after final-proof approval
Returns
Not accepted after production starts; defects corrected or remade
Cancellation
Before proof approval; completed design work deducted from the deposit
Public offer page
Example merchant page, with query and fragment removed
Illustrative fingerprint A real receipt displays its SHA-256 checksum here after the merchant seals it.

What would be public?

The merchant or project name, non-personal reference, price and payment schedule, delivery range, return terms, cancellation terms, source page, timestamp, and checksum. A live receipt can be rechecked through its public verification page and API.

What should never appear?

Customer names, email or postal addresses, phone numbers, card data, private invoice links, secrets, or confidential project details. OfferChecksum is designed for public commercial promises, not private customer records.

READ THE LIMITS

A checksum proves record integrity—not agreement.

Verification shows that the stored receipt content still matches the content used to create its fingerprint. It does not prove identity, authority, consent, payment, delivery, performance, fairness, or legal enforceability.

Review every promise yourself.

The deposit form imports only public merchant, price, currency, and cleaned source-page metadata. Payment, delivery, return, and cancellation judgments remain blank until the merchant enters them.

Open the blank deposit form