Make the prototype unmistakable
This original example is ILLUSTRATIVE DESIGN ONLY — NOT PROOF OF PAYMENT. Keep that label visible in the receipt view, not just in surrounding article text.
Fictional source reference: DEMO-R001. Demonstration payment date: October 20, 2026. Demonstration method: cash, as supplied in the fictional note set. No real merchant, buyer, bank, card, or transaction is represented.
| Item | Quantity | Unit price | Line amount |
|---|---|---|---|
| Notebook | 2 | $6.00 | $12.00 |
| Folder | 1 | $3.00 | $3.00 |
| Total of supplied items | $15.00 USD |
No tax, discount, or fee is supplied, so this layout does not invent one or declare a tax exemption. Before creating an actual receipt, reconcile all required amounts with the authoritative payment/accounting record.
An invoice requests payment; a receipt records payment already made. That purpose distinction is described in Stripe's invoice/receipt explanation. A rendered design is neither payment validation nor a determination of tax or filing sufficiency.
Keep the reading order simple
Start with the prototype label and source reference, then the supplied payment date/method, item lines, amount, and any source-supported status note. Use the same reference in the source-reading and receipt-reading versions so a reviewer can compare them.
For this fictional key, say Demonstration payment recorded in fictional inputs: $15.00 USD. Do not present a realistic paid stamp, merchant branding, or signature that could make the example look like an actual proof.
If the payment confirmation is removed, retain the items and arithmetic but change the heading to Preview — payment confirmation needed. Leave payment date, method, and paid status unconfirmed. Do not infer those values from an invoice amount or from today's date.
Reconcile the fields, not just the appearance
Compare reference, currency, quantity, unit price, line amount, and supplied payment status across both views. Two times six is twelve; adding the three-dollar folder produces fifteen. That arithmetic establishes the example's item total, not a real payment.
If source amounts conflict, preserve the mismatch for resolution. If a later refund or return changes the record, use the actual updated transaction evidence rather than treating the original display as final. Do not include payment, verification, send, or signature buttons in a read-only design prototype.
Copy a receipt-layout prompt
Draft an original HTML receipt layout specification and copy in US English.
Purpose: [fictional design review or authorized actual-record layout]
Source transaction reference and currency: [inputs]
Item quantities, unit prices, taxes/fees/discounts actually supplied: [inputs]
Verified payment amount/date/method/status and source reference: [inputs or unconfirmed]
Required receipt/accounting format: [format]
Provide a readable source-record view and receipt-reading view with identical reference and item/payment facts. Show arithmetic and unresolved discrepancies. Use paid wording only when the supplied authorized record supports it; otherwise label Preview—payment confirmation needed. For fictional examples keep ILLUSTRATIVE DESIGN ONLY—NOT PROOF OF PAYMENT visible in every standalone view. Exclude real brands, identities, account/card data, signatures, and invented credentials.
Do not invent payment confirmation, tax rates, exemptions, legal validity, or official issuance. Use [NEEDED: input] for gaps. Specify legible narrow-screen order and text status, with no pretend payment/send/verify/export controls. Return copy and design specification only; preserve actual receipts and filing records in their authorized workflow.
Check the layout against the authorized source record before using it for a real transaction. Keep unresolved payment fields out of confirmed receipt language, and produce the required document through the approved receipt workflow.
Optional: inspect the fictional layout in NOS
NOS can save and render the prepared HTML design review with its prototype label intact. Use it to compare the source reference and item total; retain actual payment confirmation and issued receipts in the authorized transaction system.