Klarna Docs - Customer data requirements per market

Customer data requirements per market

Klarna has different requirements on received customer data depending on market. This article will describe what is expected by the merchant for every market to be able to place an order.

Why do we care?

We care for two reasons really. The first is that we offer credit to consumers, this means that we need to have enough data to do a proper assessment of risk and fraud. This is only possible if we have consumer data of high quality and in a standardized format. The second reason is due to us also being a part of the order management-process.

Note: Please see that you can share the customer data in either create_session, load and authorize if you are using Klarna Payments. Validation will happen for all entered fields at each call step and added details in every step will be combined.

Best Practice: street_address2 should only be used to add extra details to the address, such as floor, apartment number etc. It should not be used to send in e.g. street number separately. This should be included in the regular street_address field.

Billing address and shipping address

Our API can handle both billing and shipping addresses separately. If no shipping address has been entered, we will duplicate the billing address and use that as shipping address in our customer data.

Please note that our risk assessment might differ if the billing and shipping are different addresses, as the fraud risk might be seen as higher.

Also note that if the customer of the billing and shipping address is different, this might also be seen as being a larger risk for fraud.

Adding Customer data throughout the session

Klarna Payments can receive customer data for a purchase throughout the session. From create_session and up to the authorize call. Any customer data added throughout the session will be be merged and taken into account for the risk assessments that takes place at both load and authorize.

Any customer data in a later call will take precedence over customer data entered in a previous call. If new customer data is amended in subsequent call, this will be merged to the previously entered data.

If any mandatory customer data field (see section below for mandatory fields per market) is still missing at point of authorize, Klarna Payments will respond with an error message. You must collect these and attempt a new authorize to complete the purchase.

Note: There is also a validation being done during Place Order where the consumer data you send in the create_order call is validated against the customer data you sent in during the session.

Details needed per market

Different markets have different standards when it comes to required input. This is mainly due to the internal standards in a country. E.g. are national identification numbers commonly used in Nordics, while not in other countries. In other countries, titles are important.

You need to provide customer details in the fields marked as Mandatory and Optional below for a good customer experience. If you e.g. provide vital aspects of the address in field street_address2 in markets where not marked as Optional this will not be used in all customer-centric systems.

Legend

SymbolMeaning
*Mandatory
-Optional
>Derived
!See notes
?Depending on payment method. Klarna will collect in purchase-flow if not added.

Sweden, Norway, Finland and Denmark

Customer detailsComment
* emailMust include @ and domain.
* postal_codeValidation according to Universal Postal Union addressing systems
? national_identification_numberNecessary for all credit payment methods and Pay Now.
* given_name
* family_name
* street_addressAlso includes street number.
- care_of
* city
* region
* phoneFollow the standards defined in https://github.com/googlei18n/libphonenumber
> gender - from PNO
> date_of_birth - from PNO

United Kingdom

Customer detailsComment
* emailMust include @ and domain.
* postal_codeValidation according to Universal Postal Union addressing systems
- titleMr, Ms
? date_of_birthNecessary for all credit payment methods and Pay Now.
* given_name
* family_name
* street_addressAlso includes street number.
- street_address2
* city
* phoneFollow the standards defined inhttps://github.com/googlei18n/libphonenumber
> genderDerived from title

United States

Customer detailsComment
* emailMust include @ and domain.
* postal_codeValidation according to Universal Postal Union addressing systems
? date_of_birthNecessary for all credit payment methods.
* given_name
* family_name
* street_addressAlso includes street number.
- street_address2
* regionUse two-letter format, e.g. “CA” for California. Follows ISO 3166-1 alpha-2.
* city
* phoneFollow the standards defined inhttps://github.com/googlei18n/libphonenumber

Germany

Customer detailsComment
* emailMust include @ and domain.
* postal_codeValidation according to Universal Postal Union addressing systems
? date_of_birthNecessary for all credit payment methods.
- title“Herr”, “Frau”
* given_name
* family_name
* street_addressAlso includes street number.
- care_of
* city
- phoneFollow the standards defined inhttps://github.com/googlei18n/libphonenumber
> genderDerived from title.

Austria, Switzerland, Netherlands and Belgium

Customer detailsComment
* emailMust include @ and domain.
* postal_codeValidation according to Universal Postal Union addressing systems
? date_of_birthNecessary for all credit payment methods.
- titleAT: “Herr, “Frau” de-CH: “Herr, “Frau” it-CH: “Sig.", “Sig.ra” fr-CH: “M", “Mme” BE: “Dhr.", “Mevr.” NL: “Dhr.", “Mevr.”
* given_name
* family_name
* street_addressAlso includes street number.
- care_of
* city
- phoneFollow the standards defined in https://github.com/googlei18n/libphonenumber
> genderDerived from title.

Australia

Customer detailsComment
* emailMust include @ and domain.
* postal_codeValidation according to Universal Postal Union addressing systems
? date_of_birthNecessary for all credit payment methods.
* given_name
* family_name
* street_addressAlso includes street number.
- street_address2
* regionUse three-letter format, e.g. “QLD” for Queensland.
* city
* phoneFollow the standards defined in https://github.com/googlei18n/libphonenumber

France

Customer detailsComment
* emailMust include @ and domain.
* postal_codeValidation according to Universal Postal Union addressing systems
? date_of_birthNecessary for all credit payment methods.
? place_of_birthNecessary for all credit payment methods.
* given_name
* family_name
* street_addressAlso includes street number.
* city
* phoneFollow the standards defined in https://github.com/googlei18n/libphonenumber

Italy

Customer detailsComment
* emailMust include @ and domain.
* postal_codeValidation according to Universal Postal Union addressing systems
? date_of_birthNecessary for all credit payment methods.
* given_name
* family_name
* street_addressAlso includes street number.
* city
* phoneFollow the standards defined in https://github.com/googlei18n/libphonenumber
? national_identification_numberNecessary for all credit payment methods

Spain

Customer detailsComment
* emailMust include @ and domain.
* postal_codeValidation according to Universal Postal Union addressing systems
? date_of_birthNecessary for all credit payment methods.
* given_name
* family_name
* street_addressAlso includes street number.
* city
* phoneFollow the standards defined in https://github.com/googlei18n/libphonenumber
? national_identification_numberCould be required