PaymentInfoCalculator.CalculateFromCarrier causing double rows on payment info

Questions
1

Scenario:

  1. Go to checkout with one item - 123
  2. Go to PayPal
  3. Click cancel
  4. Select payment method Nets Easy
  5. Code goes to “GetWidget”
  6. Code runs : _paymentInfoCalculator.CalculateFromCarrier(orderCarrier, _securityToken);
  7. Payment info on the carrier ends up with 2 order rows with the same item, and 2 delivery rows. (Should be 1 order row, and 1 delivery row)
  8. But order total is unchanged so the widget crashes with error: {“errors”:{“amount”:[“Amount does not match sum of orderitems”]}}

Is the Payment info missing some info that gets lost when going to PayPal then cancel?
It’s working if i select Nets Easy directly without going to PayPal first.

Litium version: 7.7.1

2

Paymentinfo row before CalculateFromCarrier:
image

Paymentinfo row after CalculateFromCarrier (And the newly created):
image

3

Without looking at any code it looks like you order not are persisted after they are re-calculated. That’s the reason you have one item that is marked for deletion and one that is marked for creation.

What will happen if you persist the order after you have change the payment method?

4

Not exactly sure how to persist the order?
But yes, i guess something has to remove the rows marked for deleteing.

After some decompiling i found this, feels like it might be a bug in the addon:

Creating order lines for Klarna

  foreach (PaymentInfoRowCarrier paymentInfoRowCarrier in paymentInfoCarrier.Rows.Where<PaymentInfoRowCarrier>((Func<PaymentInfoRowCarrier, bool>) (x => !x.CarrierState.IsMarkedForDeleting)))

Creating order lines for Nets Easy

  foreach (PaymentInfoRowCarrier row in orderCarrier.PaymentInfo.FirstOrDefault<PaymentInfoCarrier>().Rows)
5

Agree, looks like a bug if the add-on not is filtering the rows based on the carrier state.

Please, create a bug on docs site about this so we can investigate more.

6

Thanks, will do that!
Is it safe that i remove all those lines myself? This has already caused faulty orders in production

orderCarrier.PaymentInfo.FirstOrDefault().Rows.RemoveAll(x => x.CarrierState.IsMarkedForDeleting);
7

No, you should not remove them by yourself, then you will get stale data in database.

Instead you need to do fetch the order and run the order.SetValuesFromCarrier where you adding the updated order carrier in, then the order will clean up the data that not should be used.

1 Like
8

You have a preRelease 6.3.103-pre01 which fixes this.

1 Like
9

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.