Decide what the confirmation proves
An order confirmation answers a narrower question than an invoice or a carrier tracking page. It should tell the customer which order the shop has received, what items and amounts were accepted, the delivery or collection method, and what will happen next. It must also state the actual payment state. A page displayed after a payment redirect does not by itself prove that payment settled; the backend order and payment records must determine the wording. If the payment is pending, say so and give a usable next step. Do not call every confirmation a receipt or tax document by habit. Decide which documents your business actually issues and link to them only when they exist.
The customer may save a PDF through the browser or print the page for a purchase record. That is a real use case even if the shop also sends an email. Email can arrive late, land in spam, or become inaccessible; the confirmation screen should be useful on its own. Conversely, the printed page must not depend on the current browser tab for meaning. A label such as “this one” beside a product image or a coloured payment dot is insufficient once the image or colour disappears in print. Build a clear textual record first, then design its screen and print layouts. This is about preserving information across media, not promising a legal status for a browser printout.
Keep the transaction facts together
Show a stable order identifier and the date or time the order was accepted, with a stated time zone if the audience might be outside Hong Kong. Name each purchased item in a way the customer can recognise, including selected size or colour where relevant, quantity, unit amount, discounts actually applied, delivery charge, and final total with currency. The figures should come from the accepted order snapshot, not the current product page, because catalogue prices and titles may later change. If shipping and billing addresses are shown, label them distinctly and avoid displaying more personal detail than the customer needs on a shared printer. State the delivery choice and any confirmed collection point.
Order, payment, and fulfilment are separate states. An order may be received while a payment attempt awaits final confirmation; a paid order may be awaiting packing; a dispatched order may have a carrier reference. Do not compress these into one cheerful “complete” badge. A simple three-part summary lets the reader understand what is certain now and what will change later. Include the customer support route and what identifier to quote, but do not print a session token or private action link. If a correction or cancellation window exists, explain the actual policy and provide a route to request help. Avoid inventing a deadline merely to make the page look operational.
Design a real print view
MDN documents the print media query for rules that apply when a page is printed or saved as PDF. Use it to remove navigation, promotional banners, sticky chat widgets, and controls that do nothing on paper. Keep the order heading, identifier, item lines, totals, status words, support information, and any terms the customer needs to understand the record. The print view should retain a legible hierarchy with headings and labels, not shrink the screen layout until everything fits one sheet. Paper sizes, browser settings, and user scaling vary; let the content flow to a second page when necessary. A forced one-page design can clip a long item name or address.
A print button can call the browser’s print interface, but the ordinary browser Print command should produce the same essential record. MDN also describes print lifecycle events, yet a robust design should not rely on event handlers to insert missing transaction facts at the last moment. The data should already be present in the document; print CSS changes presentation. Check page breaks around item rows and totals so a number does not become detached from its label. If a link matters on paper, show enough destination context or a short stable URL; an unlabelled “click here” is useless in a PDF. Test grayscale and a printer with backgrounds disabled.
Keep the on-screen page usable
The page must still work before anyone prints it. Use an informative page title, a visible order heading, and headings for items, payment, delivery, and help. W3C form guidance emphasises labels that identify controls; apply the same plain-language discipline to the print button and any correction action. A keyboard user should reach those actions in a sensible order and see focus. A screen reader user should hear the order identifier and payment status in text, not infer them from a decorative icon. If status changes after loading, the page must show the current state without implying a stale snapshot is live. Provide a refresh or status link when necessary.
Protect the confirmation route. A printed record may be kept for years, but the live URL must still enforce the appropriate access decision each time it is opened. Do not put an account session key, payment secret, or full card information in the URL, page, or printed output. For guest orders, choose an access method and expiry that match the business process rather than making a permanently public order page. If the customer needs a new copy later, provide a supported way to retrieve one. The print design cannot repair a broken access model; both the on-screen view and saved document need a deliberate privacy review.
Rehearse the awkward order
Imagine a hypothetical order with two items, one promotion that actually applied, a delivery fee, and a payment still pending confirmation. The customer reaches the confirmation page after returning from a provider. On screen they see the order identifier, accepted item and amount snapshot, and a direct statement that payment is pending, with instructions for checking status. When they save the page as PDF, the same status remains visible; the print style hides the navigation but not the amount breakdown. The shop should not use “paid” merely because the redirect succeeded. After the backend verifies payment, the live order-status view may change, but the saved copy should be understood as a record of its creation moment.
Run a second hypothetical case with a long Chinese product name, an English delivery address, and enough item rows to cross a page boundary. This tests the layout rather than the payment flow. The Chinese glyphs must render, currency and quantities must remain paired with their items, and the support route must appear in a place the customer can find. Save to PDF in more than one browser and print a grayscale copy. Compare each output against the screen record field by field. A beautiful preview is not enough if the last line of the total or a status qualifier disappears on paper.
Accept the page only after comparing outputs
Before release, identify the authoritative source for each displayed field: order snapshot, payment record, delivery selection, or current fulfilment status. Then make a short acceptance sheet that compares the screen, print preview, PDF, and a physical page. Include a pending payment, successful payment, guest order, multi-page item list, and the two site languages. Check that printed dates have a time zone where ambiguity matters, money has a currency, and every state can be understood without colour. Record defects in the page or data mapping and fix them at the source. The result should be a confirmation that people can keep and understand, without pretending it proves events that have not happened.
One more edge case deserves its own comparison: an order total can change before acceptance because delivery eligibility or a promotion changed, but the accepted confirmation must use the final committed amount. If the browser cached an earlier checkout summary, the printed confirmation must not recycle that stale total. Test a last-minute delivery-method change and a promotion that becomes ineligible, then compare the accepted order record, payment instruction and printed page. If the values differ, pause the customer-facing confirmation and reconcile the data path; a polished print stylesheet cannot make inconsistent amounts trustworthy.
Before you proceed
- Does the page distinguish order, payment, and fulfilment states?
- Do screen, print preview, saved PDF and paper show the same amount and status qualifiers?
- Can a guest retrieve a later copy without exposing the order publicly?
