Is it cheaper to build accessibility in or to add it later?

Building it in. A payment flow touches authentication, error messages, timeouts and confirmation screens. Fixing each of those after launch means reopening every integration that depends on them, including the merchants' own. When accessibility is part of the shared checkout component from the first specification, the operator does the work once and every merchant using that component benefits.

Where accessibility lives in a checkout

Form labels, focus order, error messages, timeouts, authentication challenges, confirmation screens. These are not decorations added at the end; they are the structure of the flow. Changing them after launch means changing the component every merchant integrates, and often the merchants' own code around it.

The cost of retrofitting

• Reopening integrations that were considered finished.
• Re-testing 3-D Secure and wallet flows that depend on the same screens.
• Coordinating releases with merchants who did not plan the work.
• Living with the legal exposure in the meantime.

The cost of building in

A specification that includes EN 301 549 requirements from the first version, a design review with assistive technology, and a test plan that keeps accessibility in every release. The work is done once, in the shared component, and every merchant benefits without touching its integration. The same logic applies to payment terminals: choosing accessible devices at procurement costs nothing, replacing a fleet later costs a lot. For operators, accessibility is a case where doing it first is also the cheapest option.