What an order receipt fails to preserve.

The missing layer is the offer.

An ordinary receipt usually identifies a merchant, amount, date, and purchased item. Those facts matter. But many later disagreements concern details that live elsewhere at checkout:

• the final product or service description;
• the delivery range and whether it meant business or calendar days;
• the return window, its starting point, and who pays return shipping;
• the cancellation window and any important conditions.

If those details remain only on a product or policy page, the page can change after purchase. A screenshot can help, but screenshots are inconsistent, awkward to structure, and easy to lose.

Payment platforms already ask for surrounding evidence.

Shopify’s current chargeback guidance lists several records beyond the payment itself. Depending on the dispute, these include the product listing at the time of purchase, the return policy and process, an itemized receipt, checkout confirmation, and the policy terms agreed to at checkout.

WooCommerce’s dispute-evidence guidance similarly describes receipts, policies, and—in refund-policy cases—a screenshot showing where the customer accepted or acknowledged the policy.

Primary sources: Shopify: responding to chargebacks and inquiries and WooCommerce: dispute evidence suggestions.

A small structured record is easier to repeat.

A merchant does not need to copy an entire storefront into every order. A useful minimum can be narrow: merchant, total price, delivery promise, return promise, cancellation promise, and a non-personal order reference.

That record should be created after the customer accepts the terms, timestamped by the service, and linked from the confirmation page. A checksum can then reveal whether the stored content still matches the original fingerprint.

What a checksum does—and does not—prove.

A matching checksum supports one limited statement: the stored receipt content still matches the content used to create its fingerprint. It does not prove that the creator was authorised, that the merchant performed the promise, that the customer read every term, or that a bank or court must accept the record.

That boundary is why OfferChecksum is described as tamper-evident application evidence, not a digital signature, qualified timestamp, or legal guarantee.