Customer billing and shipping addresses are essential in the handling and assessment of a transaction. Validate any provided data and ensure it is handled in accordance with the data requirements outlined in the API reference and the additional guidelines provided below.
Klarna performs ongoing assessments to ensure that address handling continues to meet security and operational needs.
Partners must provide Klarna with all gathered customer information relevant to a purchase, ensuring compliance with any applicable privacy laws. This includes both billing and shipping addresses. Any address provided to Klarna as part of the client-side purchase flow must be included within the confirmation request to ensure the data is aligned between parties. This validation helps protect partners and customers against fraud by detecting any changes made on the client side. If the shipping address in the initial payment request differs from the one in the confirmation, a BAD REQUEST error will be returned.
The shipping address is not required at the confirmation stage for S2S integrations as Klarna assumes server-provided data comes from a trusted, authorized source. However, if a shipping address is included in the S2S confirmation request, it must match the initially provided data.
Data Quality and Format
Providing data in a standardized format is essential for effective fraud assessment. This includes billing and shipping addresses, email, postal code, street address, city, and phone number. If the data fails Klarna’s validation or the addresses differ between requests, an error message will be generated, which should be handled as outlined in Error handling.
Customer information must not be sent prior to the customer indicating a clear intention to pay with Klarna, following all applicable local privacy regulations (e.g. GDPR). This typically occurs at the time of authorization.
Unicode Support
The following Unicode blocks are supported for all markets
The following Unicode blocks are supported only for Greek
Additionally, characters are also matched against the following Unicode categories
Any characters that don't belong to the categories above are considered special characters. Further field-specific requirements are available within the API reference.