[Admin][Orders] Payment amount not updated after adjusting order

[audez]

Description

The payment amount owed by client is not updated after adjusting products. This is fine in the case of payments that have already been captured (=when the shop manager has clicked the "capture" icon in the orders list page). But this is problematic in the case of payments that have not been captured.

We have hubs that don't understand why the change is not impacted on the price amount. There has also been this discussion on the topic on Slack.

Expected Behavior

If the initial payment has not been captured, and there is an adjustment made on the order, the payment amount should be updated to match the new order amount.

Actual Behaviour

If a shop manager adjust products in an order, and it changes the order amount, in the order details, the "balance due" and "Total" are correct, as well as the totals that the client can see in their account, but the “amount” column in the order detail table still shows the initial price. If the manager wants to capture the correct amount, he’ll either have:

• to delete the first payment, and create a new one
• to create an additional payment This is painful and cumbersome, particularly for producers who regularly use bulk order management (to adjust meat weight for instance).

It will also appear on the client invoice, which is not pretty.

Animated Gif/Screenshot

In the following example, the initial order was 6€, then the shop manager added 1kg of potato, so the final order is 9€.

What the clients see in their account: 👍

What the shop manager sees in the order detail

The balance due and Total shown are correct 👍 but the “amount” in the table still shows 6€, which is the initial price 👎

Steps to Reproduce

1. Pass an order as a client on a shop
2. As the shop manager, edit this order (by adjusting a product)
3. See in the order detail, in the "Payment" tab (admin/orders/XXXXXX/payments) that the amount shown in the table is the initial amount and not the updated one

Severity

bug-s4: it's annoying, but you can use it

[RachL]

I'm not sure we can do that. Payments are showing action from users, as in actual payments. So the software cannot pretend you intended to pay 9 euros when you agreed to 6.

Perhaps if one day we create a preorder form instead of an actual order this could be done. Anyway it needs a serious inception and cannot be done with a bug fix. Moving to wishlist :+1:

[audez]

What bothers me though is the following:

• there's no trace for the buyer or the seller of the changes that have been made to the order: but I just read it's the topic of #189
• It's not real payments, it's payment intents. If a buyer agreed that the order could be adjusted by the seller, then it seems logic to me that when the buyer creates an adjustment, it triggers the creation of a payment intent. It's an equivalent of the seller creating a new order for someone. It doesn't imply that the client will pay, but it just avoids a manual creation of the payment intent by the seller. I mean if a producer has 100 orders, it seems impossible that they will correct all the payment intents manually 😱

IMO: when an order is passed, a payment intent is created with the initial price. Then the seller do adjustments:

• if the buyer did already pay (online or the initial payment was captured by the seller) : a new payment intent is automatically created - its amount is the difference between the initial and the new price
• if the initial payment intent wasn't captured: the initial payment is invalidated and a new payment intent is created with the new price, with an history of the changes (or the initial payment intent is edited and an history of the changes displayed)

But yeah if payment intents should only follow an action from the buyer, then there must be another way to ease the process for producers and avoid to give them such a workload.. Like creating a second type of payment intent, which would not be linked to the buyer until it is captured?

[audez]

We had this request from one of our hub: "If an order is modified, the invoice displays the previous amounts, which is incomprehensible for the client and the volunteer. Need to delete this trace and show only one amount."