1. Define the safeguard before designing the screen
WCAG 2.2 success criterion 3.3.4 covers financial transactions and specifies at least one safeguard: reversible submissions, checked input with an opportunity to correct errors, or review, confirmation, and correction before final submission.[3] It does not require all three simultaneously.[3] The Understanding document is informative rather than an additional normative requirement.[3] This article proposes the review-and-correct route. All implementation examples below are editorial recommendations, not tested Payin features, evidence of WCAG conformance, or legal advice. Local obligations need separate assessment.
2. Make review a real decision point
The Understanding document's retailer example displays order details and lets the user confirm or make changes.[3] Editorial recommendation: place the payee, purchase description, amount, currency, fees, total, and selected payment method in a readable sequence. Label edit actions specifically, such as ‘Edit payment method’, rather than repeating ‘Change’. After editing, preserve unrelated entries and return to the updated review. Distinguish ‘Return to review’ from ‘Confirm payment’. Never treat opening the review page as authorization; the final action should describe the actual commitment.
3. Turn errors into a route back to correction
WAI recommends an error list before the form, with a distinctive heading; each item should identify the control, explain the problem, give correction guidance, and link to that control.[4] Editorial example: ‘Billing postcode is missing. Enter the postcode for your billing address.’ Pair the summary with a nearby field message, not just a red border. Fields can reference their error text through aria-describedby.[4] Keep valid information intact, and remove resolved errors when validation confirms the correction. Avoid exposing sensitive payment data in summaries.
4. Specify focus instead of leaving it to chance
WAI describes focusing the first invalid input after submission as a useful approach.[4] Editorial recommendation: choose and document a focus policy for each transition. Multiple errors may justify focusing a summary; a single error may justify the relevant input. Neither choice is a universal rule. Verify that summary links actually move keyboard focus to the intended control. After editing, return users to a meaningful review location. Test visible focus, reverse navigation, and every action without a pointer; avoid unexpected jumps during ordinary typing.
5. Announce asynchronous changes without constant interruption
For dynamically inserted error summaries, WAI describes a prominent container with role=alert; its live-feedback example uses aria-live=polite to avoid interrupting current screen-reader activity.[4] Editorial recommendation: reserve urgent announcements for actionable failures and use a polite region for routine progress. Say ‘Submitting payment request’ while awaiting a response, not ‘Payment complete’. A timeout with an unknown result should explain the uncertainty and offer a status check rather than demand another payment. Check for duplicate announcements when focus movement and live regions operate together.
6. Separate correction, uncertainty, and completion
WAI recommends clear, concise notifications with correction instructions, and success messages that confirm task completion.[4] It also describes headings and page titles as feedback channels.[4] Editorial recommendation: distinguish an invalid field, an unavailable service, an unresolved request, and a confirmed result. Do not blame the card number for every server failure. On a confirmed result, show the payment reference and next action in readable text. Keep important messages available for review instead of hiding them in short-lived notices.
7. Use a matrix and record observations
Editorial test plan, not executed results: test keyboard-only navigation, a desktop screen reader with a supported browser, and a mobile screen reader. Across each configuration, cover successful review, editing, one error, several errors, asynchronous rejection, delayed responses, and confirmed completion. Record focus destination, spoken label and message, correction-link behavior, retained values, and duplicate announcements. Include browser, operating system, assistive-technology versions, expected behavior, observed behavior, and defects. Automated checks can supplement this plan; do not mark scenarios passed without observing the complete journey.
Sources and dates
Verified on 2026-09-20. Source dates are explicit page-update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.
More new articles
A payment API key leaked: how do you rotate every consumer? →
Payment troubleshooting logs: redact sensitive data without losing investigation clues →
All field guides →