Validations in the Klarna Payment session
Klarna Payments is the gatekeeper of data getting into Klarna’s systems. This means that a lot of validation is done on data sent in by merchants throughout the session.
This article will explain what validations that are done throughout the session and what you need to think of as a merchant to ensure you adhere to these standards. This will be described call-by-call following the image below.
During the create session, KP validates that the property of a session, as defined in the payload, is correct. This includes:
- That locale is aligned with purchase_country as described in .
- That tax is validated according to the standards in the .
- Value types and restrictions on specifics fields are done as described in the api documentation
Validation logic for any updates of the session will be validated as a new session. See section above for what validations this include.
Load and Authorize calls both triggers risk and fraud assessments on Klarna’s side. Meaning that Klarna does an internal check on whether credit could be given to this user or not. To achieve this, a more strict address check is done.
In this validation the address must fulfill all standards of the country and the address must exist in the address register of the specific country. If any of these standards are broken, the validation will fail.
If any address field - in either billing or shipping - is incorrect, an error message will be returned specifying what field it is.
You can read about the error code for these adjustable errors
Place Order or Create customer token
All other validations of data quality throughout the Klarna Payments session are done using a static set of rules, defined by fixed definitions. However for the place order and create customer token calls, the validation is instead done against the most recent payload sent in by you, as a merchant.
The reason behind this being done is to ensure that session handling of Klarna and the merchant are aligned. As well as that the definition of the billing address are still aligned throughout the session, so the right person is billed for the purchase.
The following is validated:
- That the billing and shipping address objects of the place order payload are the same as the most recent billing and shipping address sent in. Even the slightest change of the address will make it invalid.
- That order lines of the place order payload are the same as the most recent order lines object that was sent in. Including the position that the order lines are in, as the object is treated as a list.
Rule of thumb
The merchant should always use the same payload in the place order/create customer token call as the most recent one sent in.
Common use cases
The following use cases describe the most common use cases of how the validation works. All cases include billing and shipping address, but the same logic applies to e.g. order lines.
1 - User details added in create session - same in Place Order
Outcome - Success Address details of the payload in place order matches that of those in create session. Since no other details have been added in between, the validation will be OK.
** 2. User details added in Authorize - same in Place Order.**
Outcome - Success Address details of the payload in place order matches that of those in authorize. Since no other details have been added in between, the validation will be OK.
3. No user details added by merchant - address module used.
Outcome - Success No address details have been added in any payload up until Place order. An empty payload in place order will thus match the most recent payload and the validation will be OK.
4. Details changed in Authorize. Initial payload used in place order
Outcome - Failure
Address details initially added in create session. These are updated with a new payload in Authorize. The initial payload it used in the place order, resulting in a failure as the most recent one is different.