​At any point in the payment transaction lifecycle you can use the Klarna Transactions API to retrieve detailed information about a payment transaction. You are also able to use the API to update the transaction with additional details such as payment amount, Partner references and shipping addresses, as long as the payment transaction is not expired, completed or closed.

This request returns essential transaction details such as the payment amount, currency, line items, customer, shipping, pricing information and the state of the Payment Transaction. Read the payment transaction directly by sending a GET request to /v2/accounts/{account_id}/payment/transactions/{payment_transaction_id .

Additional information on API requests and responses are available within the API specifications.

The majority of payment solutions presented by Klarna are “guaranteed”, meaning Klarna ensures payment will be made to Klarna Partner regardless of the customer's actions provided the Klarna Partner adheres to Klarna’s terms and conditions. Klarna assumes much of the customer risk inherent in the transaction.

Non-guaranteed payments are transactions where the risk if the customer fails to pay falls to the Partner. Klarna does not cover the Partner for any losses due to non-payment by the customer. These are indicated in the parameter payment_funding.type. For transactions where the returned type is NON_GUARANTEED, the object payment_funding in response to the Confirm Payment Request along with the details of the Payment transaction becomes relevant.

"payment_funding": {
  "type": "GUARANTEED | NON_GUARANTEED"
  "state": "PENDING | FUNDED | EXPIRED"
}

This object helps to communicate the status of payment for those transactions where the risk profile falls outside of Klarna’s guaranteed payment.

Details of the possible payment_funding.states and expected action are outlined below:

The Klarna Partner will be informed about the transition from "PENDING" to "FUNDED" as well as the transition from PENDING to EXPIRED with a payment.funding.state-change webhook.

Sample payload for payment.funding.state-change event

{
  "metadata": {
    ...
  },
 "payload": {
"payment_transaction_id": "krn:payment:us1:transaction:4b8b6350-6b72-42c5-b946-f088adcdc216",
    "payment_transaction_reference": "payment-transaction-reference-1234",
    "payment_funding": {
      "type": "NON_GUARANTEED"
      "state": "FUNDED"

Consult the API reference for a complete description of the response body parameters.

The operation should be performed to retrieve the details of a payment chargeback. A payment chargeback encapsulates crucial details, such as the chargeback amount and the chargeback reason which explains why Klarna decided to reverse the transaction.

The possible value for chargeback reason are the following:

• DISPUTE_MERCHANT_LOSS: The payment dispute has been finalized in favor of the customer, resulting in a payment chargeback being initiated.
• CUSTOMER_PAYMENT_DEFAULT: For non-guaranteed offerings, if Klarna is unable to retrieve funds from the customer and if there were any prior captures performed by the partner, Klarna will register a chargeback for the capture total that will be reflected in your settlement balance. To avoid chargebacks, Klarna suggests capturing transactions only when payment is funded by the consumer.

Additional details and examples available within API specifications.

This operation should be performed when there is a need to change either the payment_transaction_reference or the purchase_reference. The purchase_reference stores the customer-facing transaction identifier, displayed on the Klarna app and other customer touchpoints. The payment_transaction_reference references the payment or equivalent resource created on your side and is exposed in Payment transaction webhooks for correlating your resource with the Klarna Payment transaction. These fields are essential for aligning your internal records with Klarna’s transaction records and ensuring accurate tracking and reconciliation.

Consult the API reference for a complete description of the response body parameters.

This operation should be performed when the payment_amount or line_items are changed.

This operation may only be performed:

• Before the payment transaction expires.
• If the payment transaction has expired but is still within the 7-day grace period, you can extend the authorization period to reauthorize with a new payment amount.
• Before the payment transaction is fully captured.

This operation should be performed when the shipping information is changed. Reauthorizing with updated shipping details is essential due to the following reasons:

• Fraud Assessment: Performing a second risk evaluation with the new shipping information helps to identify and mitigate potential fraudulent activities, thereby securing the transaction.
• Disputes: Maintaining accurate and updated shipping information supports dispute resolution by providing clear and documented proof of the shipping details, which can be referenced to customers to resolve any issues.

For more information on reauthorizing a payment transaction, refer to the API reference.

Whenever there is an update related to changes such as quantity adjustment or address modification, Klarna will trigger a payment transaction updated webhook to which you can subscribe to:

This action should be taken when the existing authorization is nearing expiration and the payment cannot be completed within the current period. This approach ensures there is enough time to finalize the payment transaction without complications. Be aware that a payment transaction is considered CLOSED 7 days after its expiration and cannot be updated thereafter.

When extending the authorization period, specify the number of days using the extension_days parameter, with a maximum extension of 180 days. It is crucial to remember that the total authorization period for a payment transaction cannot exceed 360 days from its creation date. Any attempt to extend beyond this limit will result in rejection.

Consult the API reference for a complete description of the response body parameters.