The buyer's language

The hosted pages (checkout, the invoice payment page, the card-update page and their error and thank-you screens) can present themselves in a buyer's language.

Where the language comes from

Two places, in order:

1. A ?locale= on the link. Send a specific buyer a link ending in ?locale=de and their page uses German, whatever your default is. The value survives the whole flow, including form re-renders after a validation error and the redirect to the thank-you page, so a buyer who starts in one language is not dumped into another halfway through. Unknown values are ignored, never echoed back into the page.
2. Your default. Settings, then Preferences, has a Default locale; every hosted page reads it when the link carries no explicit choice. The dropdown offers only languages the system knows, and the same rule applies if you set it through the API or an import.

What actually changes

Three layers, and they are not the same:

• The page declares its language, so a screen reader picks the right voice and the browser hyphenates and spellchecks correctly.
• The payment provider's own UI follows it. The card form, its validation messages and the 3-D Secure screens come from your gateway, and each gateway is handed the locale in the format it expects. This works for every language the provider ships, so a French buyer gets a French card form today.
• Our own page copy (order summary labels, the pay button, loading and failure lines, the thank-you and expired-link screens) comes from a translated catalog. That catalog covers English and its regional variants today, so the dropdown says "pages in English for now" for other languages rather than implying more.

What is deliberately never machine-translated

Statutory tax wording, the auto-renewal mandate above the pay button, and anything you wrote yourself: headlines, thank-you messages, terms. A legally load-bearing sentence in a language nobody reviewed is a liability, not a feature; those stay exactly as authored until real translations exist.