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:
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.
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 merchant should always use the same payload in the place order/create customer token call as the most recent one sent in.
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.
NOTE: In the example above, no billing details are added. However email must be sent in.
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.
NOTE: This change could be both major (a completely new address) or minor (one field changed). It would still fail the validation.