Klarna Docs - Authorize the purchase

Authorize the purchase

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 order. If successful, you will receive an authorization token in return which gives you the ability to place an order towards Klarna. During the authorize 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.

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, whenauthorize()is called, it should be visually shown that something is happening (e.g. a spinner in the button that triggered theauthorize()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 callauthorizeusing 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 note 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:

  1. Avoid sending another authorize call (e.g. disable the buy button from being clicked again)
  2. Show to the consumer that the order is being processed (e.g. by showing a loading spinner)
  3. Prevent consumer from changing order or billing details (e.g. lock the input fields on your page)

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 callback function parameter is an object containing the following properties

  • approved (true/false) - the authorization result, approved or denied
  • show_form (true/false) - whether the Klarna Widget should be displayed or hidden
  • authorization_token - a token which allows you to place the order via a server side call, only returned if the authorization was approved
  • error - contains details of potential error messages

Below is a quick guide of how to interpret the combination of these values

show_formapprovedAction
FALSEFALSEDisable Klarna’s widget and pre-select another payment method.
TRUEFALSEDisplay Klarna’s widget and show error message to customer. Let consumer change details and try again.
TRUETRUECreate order and redirect customer

If approved: true, then Klarna has approved the authorization of credit for this order.

JSON
{
authorization_token: "b4bd3423-24e3",
approved: true,
show_form: true
}

The authorization_token allows you to complete the order 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 order 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

Option 1 - Fixable error

JSON
{
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_name

Example 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 order. 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.

JSON
{
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.

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:

JAVASCRIPT
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:

JAVASCRIPT
Klarna.Payments.finalize(
{payment_method_category: ‘pay_now’},
{},
function(res) {
// res = {
//   show_form: true,
//   approved: true,
//   authorization_token: ...
// }
})