A checkout is a complete process, and WCAG is unusually blunt about what that means. Where a page is one of a series presenting a process, every page in the series has to conform for any page in it to conform. The standard's own worked example is an online store's select-and-purchase series, so this is not a stretch of the rule. It is the rule's home ground.
Then the payment step arrives and the ownership goes strange. Your page renders a frame. The frame is served by your gateway. Inside it, during a card authentication challenge, some of the content is the cardholder's own bank talking to their own customer. Three parties, one visual step, and a report that treats it as one thing will be wrong about whose defect it is.
You Cannot Leave the Payment Frame Out of the Claim
The instinct is to scope the payment step out, and the standard closes that door explicitly. Conformance is for full pages only and cannot be achieved if part of a page is excluded. There is no version of a claim that covers your checkout with a hole where the card fields are.
What WCAG offers instead is two routes for content from sources you do not control, and only two. Either the page is monitored and non-conforming content is repaired within two business days, in which case a determination of conformance can be made. Or a statement of partial conformance is published, saying the page does not conform but would conform at a stated level if the named uncontrolled parts were removed, with those parts described so a reader can identify them. WCAG adds that no claim can be made at all if monitoring and correcting is not possible.
For a payment integration the honest reading is that route one is usually unavailable, because nobody can repair an issuer's challenge screen inside two business days. That is worth knowing before somebody publishes a conformance claim they cannot support.
Three Ways the Card Challenge Reaches the Screen
Card authentication is not one design. A widely used gateway's documentation sets out three ways a merchant can present it, and the choice is yours rather than the bank's.
- A pop-up modal, which the gateway's own library opens by default. Everything our modals and dialogs guide covers applies, except that you cannot fix what is inside it.
- A redirect to the bank's website, where the customer leaves your site entirely and comes back to a return address afterwards. Your page is not on screen at all, which simplifies the claim and complicates the journey.
- An iframe you place yourself, inline with the payment form or inside your own modal component. Most control, most responsibility for the frame's surroundings.
Two details from that documentation matter more than they look. The gateway states that in live mode the card issuer controls some of the content inside the frame, and that you cannot use the sandbox attribute on it, because some issuers' implementations fail when sandboxed and the payment does not go through. So the frame is deliberately less contained than a security review would like, and the content in it is not yours to fix.
The third detail is a test condition. For the current version of the protocol, issuers are required to support showing the challenge at five sizes, 250 by 400, 390 by 400, 500 by 600, 600 by 400 and full screen. The smallest of those is narrower than the width Reflow is tested at, which does not by itself make anything a failure and does mean the size you chose belongs in the report as a recorded condition.
You Cannot Make the Challenge Appear on Demand
Here is the fact that decides how a payment test plan has to be written. Whether a challenge appears at all is the issuer's decision. A merchant can request a preference, either for a frictionless flow or for a challenge, and the gateway states plainly that it cannot guarantee the preference because the issuer determines the final flow. You can read afterwards which flow actually happened. You cannot order one in advance.
In a sandbox this is solvable, which is the whole reason payment testing happens in a sandbox. A test card triggers the authentication flow and the process shows a mock authentication page with controls to authorize or to fail the payment, so both branches are reachable without a real charge. In production it is not solvable, and a report that promises to test the live challenge is promising something outside its control.
The Payment State and Ownership Matrix
This is the artifact. Ten states, and for each one the question that actually gets argued afterwards, which is who fixes it.
| State | Who renders it | What to test | Who fixes a finding |
|---|---|---|---|
| Card fields on your page | Gateway, usually in hosted fields | Labels, input purposes, inline validation | Gateway, with your configuration |
| Field-level error | Gateway or you, depending on integration | Whether the error is announced and reachable | Whichever owns the message |
| Submit and wait | You | The waiting state as a status message | You |
| Frictionless authentication | Nobody, visually | That nothing traps focus while it happens | You |
| Challenge appears | You choose modal, redirect or iframe | Focus moves into it, and can get back out | You, for the container |
| Challenge content | The card issuer | Record what you observe, and that you cannot change it | Nobody you can reach |
| Challenge cancelled | Issuer, then you | Where focus lands and what the customer is told | You |
| Authentication failed | You | Error identification and a route to retry | You |
| Payment declined | You | Whether the reason is announced and the form is still usable | You |
| Return and confirmation | You | That the return page announces the outcome and focus is sensible | You |
Read the ownership column top to bottom and the shape of the report writes itself. One row is genuinely nobody's, most rows are yours, and the ones marked for the gateway are usually a configuration you can change without touching their code.
What Error Prevention Actually Requires Here
A payment is a financial transaction, so Error Prevention (Legal, Financial, Data) applies, and it asks for less than people fear. The criterion is satisfied by at least one of three safeguards. The transaction is reversible. The data is checked for input errors with a chance to correct them. Or the submission is confirmed, with a review step and a chance to change or cancel.
One of three. A confirmation screen before the charge satisfies it, which most checkouts already have. Nothing in the criterion requires a refund policy, and anyone telling you WCAG mandates reversible payments has read one of the three options and stopped.
Testing This Without Charging Anybody
- Agree a sandbox before anything else. A gateway sandbox with test cards is the whole basis of this work. Testing in production with real cards is not a method, it is an incident.
- Get the test card list for the branches you need. Gateways publish cards that always require authentication, cards that always decline, and cards that succeed. Each is a row in the matrix.
- Fix the display route. Modal, redirect or iframe, and if you offer more than one, each is a separate pass.
- Record the frame size. If the challenge renders in an iframe, the dimensions are part of the tested condition and one of the permitted sizes is narrow.
- Write the issuer content down without claiming it. Observe it, note it, and say plainly that it is not the merchant's content and was not evaluated as such.
- Never ask for real card details, and never send them. Not in a form, not in an email, not in a ticket. This one has no exceptions.
One honest limit
We audit and never repair, so this is not an offer to rebuild your checkout. It is also not payment security work of any kind, and an accessibility report says nothing about whether your integration is safe or compliant with card scheme rules. What an evaluation produces is the state matrix worked in your sandbox, with findings attributed to the party that can act on them. Scope it at contact or read what the checkout audit covers.