The authorization of a purchase means that you will send in all necessary customer details for Klarna to make a decision about whether or not credit could be offered for the purchase.
When the consumer has chosen a payment method and wants to complete the purchase, you will need to use our Javascript SDK to authorize the purchase. During this authorization step, Klarna takes all the order and customer data from the session and makes an assessment, to see if we could offer the selected payment method for this purchase.
When the authorization is successful, you will receive an authorization token in return which gives you the ability to place an order towards Klarna. The authorization token is delivered via the Javascript authorize callback, and can optionally be received through a server-side authorization callback.
Note: A successful authorization guarantees that the order can be created within 60 minutes.
The authorization is made with a client side authorize()-call. The result of a successful authorization (approved: true) is an authorization_token. This is used when placing the order towards Klarna.
In the authorize() call you must pass the billing (and optionally shipping) address that has not been shared already. Please note that Klarna will use all information that has been collected throughout this session when authorizing the order.
For more information about what is needed per market and how to format it, please go to the consumer object article.
Note: If the shipping address is not added to the session, Klarna will duplicate the billing address and use it as shipping address.
Best practice: To ensure that customers understand that some processing is going on in the background, when authorize() is called, it should be visually shown that something is happening (e.g. a spinner in the button that triggered the authorize() call).
There is no need to provide fields that have already been provided previously during the session, unless the content in those fields has changed. That said, providing the same data again will not break anything. Best practice is to call authorize using a full request (like in the example above) to be sure the most up to date content is being authorized.
Note: You can also choose not to send in any customer details except for email. In this case Klarna will collect all necessary details to complete the purchase.
When authorizing the order, Klarna conducts a full risk assessment. Therefore, from the point where you call authorize until you receive the callback you must:
The callback is typically received within seconds, but may take up to a minute or so in case a consumer sign-up is required when the user interacts with the widget.
When the widget has processed the authorization, the callback will be executed. The Javascript callback function parameter is an object containing the following properties
Below is a quick guide of how to interpret the combination of these values
| show_form | approved | Action |
|---|---|---|
| FALSE | FALSE | Disable Klarna’s widget and pre-select another payment method. |
| TRUE | FALSE | Display Klarna’s widget and show error message to customer. Let consumer change details and try again. |
| TRUE | TRUE | Create order and redirect customer |
If approved: true, then Klarna has approved the authorization of credit for this order.
{
authorization_token: "b4bd3423-24e3",
approved: true,
show_form: true
}The authorization_token allows you to complete the purchase by the server side place order call. The token is valid for 60 minutes. During this time, the authorization is guaranteed. In case the place order is performed beyond the expiry, Klarna will try to re-authorize the purchase but cannot guarantee a successful outcome.
Best practice: You may store the authorization_token in a hidden form field and submit it to the backend with the “buy” / “Place order” form submit button.
If approved: false, Klarna cannot approve the purchase. There are now two options
{
approved: false,
show_form: true,
error: {
invalid_fields: [
billing_address.street_address
billing_address.city
billing_address.given_name
billing_address.postal_code
billing_address.family_nameExample of fixable error
In the case of an adjustable error, you will receive show_form: true and a specification about what fields that are invalid, e.g. error: { invalid_fields: ["billing_address.email"] } }.
The widget will also display an error message to the consumer, asking them to correct it before you re-authorize the purchase. This error message will also clarify which specific field that is incorrect.
Best practice: You may use the error message in the callback object to highlight a particular entry field (in this case the customers email address) on your page.
It is also possible that you receive show_form: true and no error is included in the callback. If this happens, it means that the customer has aborted a required interaction in the widget. Including authentication or a potential credit signup flow. In this case you should continue to show Klarna’s options as the customer might want to make another attempt at completing the purchase with Klarna.
{
approved: false,
show_form: false
}Example purchase declined response
If show_form: false, the purchase is declined. The widget should be hidden and the user should select another payment method.
We will not share more information about why a certain purchase was rejected, as our risk and fraud policies are internal to Klarna.
In addition to the frontend Javascript callback, it is also possible to receive the authorization token as a callback to a certain URL. For more details refer to the in-depth article on server-side authorization callbacks.
Please note that this step only applies to your integration if you offer payment methods where funds are drawn from the consumers directly, such as bank transfer or Sofort, in a multi-step checkout.
Note: If you integrate a multi-step checkout, you may call authorize() with the auto_finalize: false property set in order to indicate that there is a finalization step. In this case the response may differ.
In a multi-step checkout scenario the authorize() call can be triggered when the consumer selects the payment method and then presses the “continue” button to go to the next step of the checkout. With Pay Now as payment method category however transferring the funds should only happen once the consumer has pressed the “buy” button to finalize the purchase.
To cater for such a scenario authorize() can still be called when the consumer has selected the payment method, but with the auto_finalize property set to false. authorize() example:
Klarna.Payments.authorize(
{ payment_method_category: ‘pay_now’, auto_finalize: false},
{},
function(res) {
// proceed to next checkout page. The finalize_required property in the response indicates
// if finalize is needed or not.
//
// res = {
// show_form: true,
// approved: false,Now when the consumer reached the last page in the checkout and can finalize the purchase finalize() is called. This will then trigger the transfer of funds and return the authorization token in the finalize callback. The flow is transparent to all payment method categories. That means if finalization was not needed in the authorize() call (e.g. for pay later) finalize()can be still be called and will return the authorization_token so that the implementation remains the same for all payment method categories. finalize() example:
Klarna.Payments.finalize(
{payment_method_category: ‘pay_now’},
{},
function(res) {
// res = {
// show_form: true,
// approved: true,
// authorization_token: ...
// }
})