Refund Allocation

Correct refund allocation ensures clarity for your customers. When you deliver orders in multiple shipments (i.e., when you part-capture orders) and your customers return some of the goods, it’s important to correctly allocate the refund amount to the customer’s payment instruction (e.g., invoice) for the respective shipment/capture.

To fully understand the concept of refund allocation, you should be acquainted with the definitions of part-captures, refunds and order lines.

The challenge

When you deliver a customer’s order in multiple shipments, i.e., when you capture the order in parts (“part-capture”), Klarna creates separate payment instructions per shipment for your customer. For example, instead of receiving one invoice for all ordered goods at once, the customer gets individual invoices with each partial delivery.

When the customer returns some goods from such a partially delivered order, they naturally expect the refund amount to be allocated to the respective payment instruction (e.g., invoice), accordingly.

However, due to the lack of identifier between the specific refund and the respective capture (shipment), the refund is reflected on a general order and not on a specific capture level. As a result, the refund is allocated to any payment instruction (e.g., any invoice) from that order, causing confusion for your customers.

The solution

We at Klarna don’t want you to bother with keeping track of our capture-IDs in order to correctly allocate refunds. We want you to continue doing the refunds on an order level. At the same time, we want to ensure the correct refund allocation through the use of order lines.

By keeping the order lines consistent between the specific capture and the refund you are making, you will help us understand which payment instruction to allocate the refund to. More specifically, you should keep the order line attribute “reference” exactly the same in both capture and refund, so that we at Klarna can correctly allocate the refund to the right payment instruction.

Let’s look at an example

Let’s say you have received a customer’s order for a T-shirt, a pair of jeans and a pair of sneakers. You decide to deliver this order in two separate shipments and capture the order in two separate parts, accordingly:

  • Capture A. Two order lines: a T-shirt (reference A12345) and a pair of jeans (reference A98765)
  • Capture B. One order line: a pair of sneakers (reference B24680)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
HTTP/1.1 200 OK
Content-Type: application/json

{
  "captured_amount": 10000,
  "description": "Capture A, shipping part of the order",
  "order_lines": [
  {
    "reference": "A12345",
    "name": "T-shirt",
    "type": "physical",
    "quantity": 1,
    "total_amount": 3000,
    "unit_price": 3000
  },
  {
    "reference": "A98765",
    "name": "Jeans",
    "type": "physical",
    "quantity": 1,
    "total_amount": 7000,
    "unit_price": 7000
  }
  ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
HTTP/1.1 200 OK
Content-Type: application/json

{
  "captured_amount": 10000,
  "description": "Capture B, shipping the rest of the order",
  "order_lines": [
  {
    "reference": "B24680",
    "name": "Sneakers",
    "type": "physical",
    "quantity": 1,
    "total_amount": 10000,
    "unit_price": 10000
  },
  ]
}

Your customer wants to return the sneakers. All you have to do now is to make a refund call with the order line from Capture B. Make sure the reference attribute is consistent. And that’s it!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
HTTP/1.1 200 OK
Content-Type: application/json

{
  "refunded_amount": 10000,
  "description": "Returning the sneakers",
  "order_lines": [
  {
    "reference": "B24680",
    "name": "Sneakers",
    "type": "physical",
    "quantity": 1,
    "total_amount": 10000,
    "unit_price": 10000
  },
  ]
}

Other things to consider

There are a few important prerequisites for this method to work properly. First of all, the order you are refunding cannot have any previous refunds with failed allocation. Additionally, you need to make sure that the refund call you make:

  • Has consistent amounts, i.e. the sum of all order lines must match the total refunded amount in the root level of the event.
  • Will not refund a bigger amount than what was captured in the part-captured you are refunding. In the example above, that would mean that when you refund the sneakers, the refunded amount cannot be more than the captured amount in Capture B.

If the refund call you make does not meet all of the above requirements, we will still accept the refund but the allocation might not work properly.