In the request to the Hosted Payment Page (HPP), you can dynamically set the language you want to display to the customer. If you're not using the SDK, this is set in the HPP_LANG field.
{
"English": "en",
"Basque": "es_eu",
"Bulgarian": "bg",
"Catalan": "es_ca",
"Chinese": "zh",
"Croatian": "hr",
"Czech": "cz",
"Danish": "da",
"Dutch": "nl",
"Estonian": "et",
"Finnish": "fi",
"French_fr": "fr",
"French_ca": "fr_ca",
"Gaelic": "ga",
"Galician": "es_gl",
"German": "de",
"Greek": "el",
"Hungarian": "hu",
"Italian": "it",
"Latvian": "lv",
"Lithuanian": "lt",
"Maltese": "mt",
"Norwegian": "no",
"Polish": "pl",
"Portuguese": "pt",
"Romanian": "ro",
"Russian": "ru_ru",
"Slovak": "sk",
"Slovenian": "sl",
"Spanish": "es",
"Swedish": "se",
"Welsh": "cy"
}To ensure accurate handling of special characters and diacritics:
All merchant requests must use UTF-8 encoding unless explicitly specified otherwise.
If a different character encoding is required (e.g., ISO-8859-1), the merchant must specify this in the Content-Type HTTP request header.
Content-Type: application/x-www-form-urlencoded; charset=ISO-8859-1If a charset is specified, HPP will attempt to decode the request using the specified value.
If decoding fails or no charset is specified, HPP will fall back to its default decoding mechanism based on predefined character sets.
HPP supports the following characters when encoded correctly using UTF-8. These characters will be accepted and passed to the merchant via post-back as-is. If encoded correctly, no validation errors will be shown for these characters.
Ą, Ć, Ę, Ł, Ń, Ó, Ś, Ź, Ż, ć, ń, ó, ś, ź, ż, ł, ą, ę
Ä, Ö, Ü, ä, ö, ü, ẞ, ß
ě, š, č, ř, ž, ý, á, í, é, ů, ú, ň, ď, ť, ó, ä, ĺ, ŕ, ľ
Ě, Š, Č, Ř, Ž, Ý, Á, Í, É, Ů, Ú, Ň, Ď, Ĺ, Ť, Ó, Ä, Ŕ, Ľ
Ă, ă, Â, â, Î, î, Ș, ș, Ț, ț
Á, á, É, é, Ó, Ö, Ő, ó, ö, ő
А, а, Б, б, В, в, Г, г, Ґ, ґ, Д, д, Е, е, Є, є, Ж, ж, З, з, И, и, І, і, Ї, ї, Й, й,
К, к, Л, л, М, м, Н, н, О, о, П, п, Р, р, С, с, Т, т, У, у, Ф, ф, Х, х, Ц, ц, Ч, ч,
Ш, ш, Щ, щ, Ь, ь, Ю, ю, Я, я
These diacritic characters are accepted in the following fields:
Cardholder NameHPP_SHIPPING_STREET1HPP_SHIPPING_STREET2HPP_SHIPPING_STREET3HPP_SHIPPING_CITYHPP_BILLING_STREET1HPP_BILLING_STREET2HPP_BILLING_STREET3HPP_BILLING_CITYCOMMENT1COMMENT2HPP will return diacritic characters, exactly as submitted, without modifying or normalising them in the post-back
While HPP accepts and returns diacritic characters, downstream systems (e.g., 3DS2, DCC, IPS) may normalize these before storage.
| Region | Original Diacritics | Normalized |
|---|---|---|
| Poland | Ą, Ę, Ł, Ż | A, E, L, Z |
| Germany | Ä, Ö, ß | A, O, SS |
| Slovakia | Č, Ť, Ď | C, T, D |
| Romania | Ș, Ț, Â | S, T, A |
| Hungary | Ő, Ö, Á | O, O, A |
| Ukraine | Є, Ї, Ю, Я | ye/ie, yi/i, yu/iu, ya/ia |
Always verify encoding using tools like OpenSSL or request inspection.
If not using UTF-8, ensure your request headers explicitly state the correct charset.
If encountering decoding issues, review logs for charset mismatches or fallback behavior.