Submit must yield a checkable receipt immediately

What it is

After pay is pressed and a success response arrives, the current UI must become a checkable receipt: order id, what was bought, how much, to whom, where it goes. Checkable means this screen can be matched to memory or an SMS—not a “Success” and a bounce away. This is the moment-of-submit screen, not how e-invoices differ from till receipts in law, and not whether email, SMS, and the app say the same thing.

Why it happens

Capture is an invisible backend event; people infer from the UI whether money moved. A success page of motion or “thanks” lets amount and goods fade in seconds, so people check the bank app and often pay again. A receipt replaces inference with comparison: id, goods, amount co-present, anxiety drops. Fast redirect, a promo modal on top, or a success page without an order id kills that beat. Sharing a spinner “processing” end state for success and failure leaves people unsure whether to wait or pay again.

Studying it

After simulated success, compare thanks-only, a static page with id and amount, auto-redirect home, and a coupon modal covering the receipt.

Independent variables: receipt fields in the first viewport, auto-leave, whether a countdown can be stopped. Dependent variables: restating id and amount, repeat pay attempts, immediate support contacts asking “did it charge.”

Lab participants know the task is over and will not open a bank app. Remote tasks should allow it. Do not count email delivery as “we gave a receipt”—the live screen did not; mail is another channel.

Where it stops holding

If the issuer shows its own receipt after redirect, the merchant still owes a merchant order id on return, or the two sides cannot be matched. Cash-on-delivery has not captured at submit; the receipt is “placed, to collect,” not paid. Orders pending review are “accepted” plus a lookup id, not a ship promise. Celebration motion is fine; it does not replace fields.

Applying it

• The paid landing page shows, in the first viewport, order id, goods summary, amount due and captured, delivery or redemption; those fields are readable before any redirect or modal.
• Do not leave the page with no input; if “Continue shopping” exists, keep “View order.”
• Do not end success and failure on the same field-less spinner.
• Verify by paying a test order, closing help, and having someone else write the order id and captured amount from the current screen only. Failure: they cannot, or they must open mail.

Related

• Within the group: H7.05.2 The receipt must carry undo and after-sales entry points · H7.05.3 Confirmation must be savable and retrievable
• Adjacent: H7.12 Order confirmation and receipts · H1.16 Post-submit result presentation · H7.02 Checkout flow
• Search terms: order confirmation · payment success page · order number