Tickets can't be refunded or exchanged after you pay.
``` Continue saves the choices without charging anything, and the next page reads them back in words, with the total. Each Change link goes back to its field with every answer kept, so fixing the slip takes one change, not a new booking. Only "Confirm and pay $48" charges the card, and its name says how much. The heading and the page's title say which step this is, so screen reader users know they have arrived at the check, not at a confirmation. ## After: a stated time to cancel, with a Cancel button ```html book.html ``` ```html confirmation.html2 tickets for Friday 13 November, 7:30 pm. $48 paid with your card ending 4242.
You can cancel this booking for a full refund until 6 pm on Thursday 12 November.
``` The order is placed at once, but it can be taken back. The time is stated before people pay and again afterwards, as an actual date and time, and cancelling takes one button on the page they are already on. This holds only while the window is long enough to notice a mistake in, and while cancelling is no harder than booking: no phone call, no form to fill in, no hunting for a link in an account page. The money still leaves the account and comes back days later, and a slip noticed after the window closes is still paid for. ## After: a box to tick, beside a summary of the order ```html book.html ``` ```js const form = document.querySelector('form'); const box = document.getElementById('order-checked'); form.addEventListener('input', (event) => { if (event.target === box) return; // The order changed: say what it is now, and ask for the check again. box.checked = false; const tickets = Number(form.tickets.value); const total = `$${tickets * 24}`; document.getElementById('summary').textContent = `${tickets} ${tickets === 1 ? 'ticket' : 'tickets'} for ${form.night.value}: ${total}`; form.querySelector('button[type=submit]').textContent = `Pay ${total}`; }); ``` This is the smallest change: the form stays on one page. The summary sits next to the box and is read with it, the button names the total, and the box is required, so the browser stops the payment and says why if it isn't ticked. Changing the order after ticking unticks the box, so what was confirmed is what is paid. It is not enough on its own: a box asks people to check without showing them anything new, many tick it by habit, and people who zoom in or use a screen reader can't take in the summary and the fields together. ## Which option to use All three pass 3.3.4. Use the review step: it stops the slip before any money moves, for every kind of order, and needs no refund process behind it. Add a cancel window as well when the business can take bookings back; it also catches mistakes people only notice later, such as a clash with another plan. Use the checkbox only on a one-page checkout that can't gain a step yet, and replace it with a review when you can. ## Implementation decisions Keep the choices on the server between the steps, in the booking session, not only in the page. Then the Back button, a Change link and a reload all come back with every answer in place, as [checkout forms that ask for the same address twice](/learn/redundant-entry) explains. On the review step, write each choice out in full and as people would say it: "Friday 13 November, 7:30 pm", not "13/11 19:30" or a seat code. Give the total, how it will be paid, and any condition that matters, such as no refunds, before the button. A payment provider's hosted page often charges as soon as its own button is pressed. Put your review step before handing over, so the provider's page is the last step and says what it will take. Some actions need the same care without money: deleting an account or a project, sending a signed form, submitting an exam. For a delete, a confirmation that says what will be lost, or an Undo right after, does the job; see [confirmation dialogs that don't read out their question](/learn/confirmation-dialogs) and [toasts that vanish before you can read or undo them](/learn/toast-timing). Don't disable the final button to prevent a second press. Make the server accept each order once, with a token in the form, so a double press books once and the button still works if the first press failed. ## Verify the fix 1. Make a test booking with a deliberate slip, such as one extra ticket or the wrong performance, and go as far as the site lets you before money is taken. Confirm the slip is shown to you, in words, before it counts, or that you can cancel it afterwards. 2. From the review step, use each Change link. Confirm it goes to the right field with every answer kept, and that the review shows the corrected order. 3. Where there is a cancel window, confirm its end is stated as a date and time before paying and after, and cancel a test booking from the confirmation page with a keyboard alone. 4. With a screen reader, confirm every choice and the total are read before the button that commits, and that the button's name says what it does. 5. At 400% zoom or on a phone, confirm the summary and the final button can be read together, or one straight after the other. Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the checkout's steps or its payment provider change. ## Limits This is a starting pattern, not a guarantee for every process. The example is a ticket booking; shops, subscriptions, loans, applications and tests need the same check at the step that commits. 3.3.4 doesn't ask for a confirmation every time someone saves or edits their own data, only where a mistake would be costly or hard to undo. Test the complete process, including the emails it sends, with the people and tools your users rely on. --- Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)