Read more in the API documentation

• Out of stock validation - For high turnaround businesses, this functionality enables you to verify that an item added to the cart is still in stock before the consumer completes the purchase.
• Delivery limitations - Verify that the product can be shipped to the address the consumer has provided.
• Order number generation - Certain systems have flows that require the creation of an internal order ID when order has been created, such as for tracking purposes.
• Blacklisted consumer - You might not want to sell to a specific consumer or address and can prevent the purchase from going through.
• Discount coupon validation - If a discount coupon is added to the order you can verify it here to prevent multiple usages of the same code.
• Cart validation - Prevent fraud committed by having multiple tabs open. Compare your internal order with the KCO order so there is no mismatch between cart items before letting the purchase through.

*See Cards and 3D Secure

Make sure to include the optional property merchant_urls.validation. when you configure the checkout order.

Note: All communication with the validation URI will be encrypted. For that reason you must use the HTTPS protocol for this URI.

    "merchant_urls": {
      "terms": "https://toc",
      "checkout": "https://checkout?klarna_order_id={checkout.order.id}",
      "confirmation": "https://confirmation?klarna_order_id={checkout.order.id}",
      "push": "https://push?klarna_order_id={checkout.order.id}",
      "validation": "https://validation?klarna_order_id={checkout.order.id}"
    }

When the consumer clicks “buy now” a POST request will be sent to the merchant_urls.validation. The body of the request will contain the current order information. The structure of the order information is identical to the result of fetching the order, as you saw in render the checkout.

Note: There is no need to fetch the order from KCO since all the order information is included in the POST request body.

Once you receive the POST request, our system will expect a response within 3 seconds. If KCO does not receive a response and the order is created without require_validate_callback_success: true, we will approve the purchase. If the order is created with require_validate_callback_success: true and KCO does not receive a response within 10 seconds the order approval fails. The response you provide KCO will determine whether or not the purchase will be completed:

• To approve the purchase, reply with a HTTP status 200 OK. The consumer will then be redirected as normal to the checkout confirmation page.
• To deny the purchase, reply with a HTTP status 303 See Other. This needs to include a Location header pointing to a page which informs the consumer why the purchase was not completed. The consumer will be redirected to this page.

Note: The rejection page needs to be hosted by you, and we highly recommend that you give the consumer detailed information as to why you rejected the order.

Responding to the validation callback with HTTP status 200 OK will not always guarantee that the order is completed, for example if the consumer is paying using card and triggering 3D Secure authentication. When authentication is completed then a reservation is made on the customer’s card, in case a validation callback is fired after the authentication event and is responded to with an HTTP 303 (in this context: deny purchase) response status, Klarna will still retain the reservation on the customer’s card.

Hence, whenever Klarna reserves money this happens as the last part of the purchase flow. Therefore an HTTP 200 OK response status followed by failed 3D Secure authentication does not allow for completing the order and does not redirect the customer to the confirmation page.