openfoodfoundation / wishlist

This repository welcomes ideas and suggestions to improve the OFN software.
3 stars 0 forks source link

[Admin][Order] Creating a new payment makes the initial one "Invalid" and impossible to capture #385

Open audez opened 1 year ago

audez commented 1 year ago

Description

In Orders details, in the Payments tab, if you create a new payment, it makes the initial one "Payment status" switch to "Invalid" and you can't edit it anymore.

Expected Behavior

You should be warn adding a payment will invalid the previous one unless you capture it.

Actual Behaviour

In an order detail, there's an initial payment in the Payments tab table, corresponding to the initial order amount. If you click on "Create a new payment", and save a new payment, you'll see it appears in the table. But you also see that:

So there's nothing you can do on the first payment.

And this invalid payment will appear in the client invoice, which is not nice.

Steps to Reproduce

  1. Pass an order on a shop
  2. As the shop manager, go in the order details, Payment tab (admin/orders/R635250042/payments)
  3. Click "Create a new payment" and save (it's equal if you choose the same or a different payment method)
  4. See the effect on the first payment

Animated Gif/Screenshot

Before creating a new payment

Screen Shot 2022-10-21 at 20 12 07

After creating a new payment: "Payment status" is invalid and "Capture" icon has disappeared

Screen Shot 2022-10-21 at 20 12 17

Clicking on "Void" icon displays an error message: you can't cancel the payment

Screen Shot 2022-10-21 at 20 12 22

What appears on the invoice

Screen Shot 2022-10-21 at 20 22 06

Testing on another order: if you first void the payment (or capture it), and then create a new payment, it's fine

Screen Shot 2022-10-21 at 20 13 47

Workaround

First capture the first payment before adding a new one. Otherwise capture the second and re-do the first one.

Severity

bug-s3: a feature is broken but there is a workaround

RachL commented 1 year ago

@audez FYI I've changed:

You should be able to edit the first payment even after creating a new payment.

We shouldn't be able to edit a payment. That's illegal in case of an order. But I agree it's weird to consider the first payment invalid. It does not happen if you capture first, which is the workaround we need to tell users.

IMO the fix should be to warn the user they must capture first. Not capture by default.

audez commented 1 year ago

Yes by edit I mean: capture or void the payment, same way you do in reverse

audez commented 1 year ago

I dont understand but i think i dont understand/know how the payment currently works in case of adjustments

But if it's mandatory to capture/void the initial payment before creating a new payment i agree that we should warn the user and not allow them to create a new payment (deactivate the button?) until they act on the initial one

RachL commented 1 year ago

not allow them to create a new payment

Let's keep it, it's a shortcut in case you don't want to capture the first once, but cancel it (current default case).

audez commented 1 year ago

OK so then if we do that we should warn them on click on "Create a new payment" that this will invalidate the initial payment, and don't display the "Void" icon on the initial invalidated payment

Also I think there is a real problem: it's not only for the first new payment that you create, it happens each time you will create a new payment. Creating a new payment will always invalidate the previous uncaptured one. So for instance: I have a buyer that did a 50€ order. She paid me with 2 checks of 10 and 40, and I want to save it in the payment. I can't create 2 pending payments of 10 and 40 :/

RachL commented 1 year ago

Creating a new payment will always invalidate the previous uncaptured one.

yes, but this is logical.

I can't create 2 pending payments of 10 and 40 :/

Yes, theses cases exist in case of subscription. But do not fit the model of an ecommerce order. Currently our order model is not made for these cases, it's not a bug, it's something we need new feature for.

audez commented 1 year ago

yes, but this is logical.

But then I don't understand this:

I think it's very confusing for producers, because first we ask them to create the payments themselves, then to guess that they have to capture or void the initial one and only AFTER that create a new one. Although they might not have received any payment yet. How to explain that they can't create 2 payments and capture both after..which is actually the same...

Also it raises the issue discussed here by @tschumilas: from the Orders list page, the capture button is displayed next to the new price, so the producer will click on "Capture" thinking that they're capturing the amount owed, but actually they just captured the initial amount..

For instance:

RachL commented 1 year ago

if creating a new payment always invalidate the previous one, why we don't automatically invalidate the 10€ payment intent, and create a new of 12€? Instead of asking the producer to do it manually..

Because there are several use cases at play. Perhaps the edition or the order was made after the first real life payment. And the producer just forgot to capture it at that time. We don't know that.

But it actually only captured the initial payment..

Again logical from a system point of vue. The system can only capture a payment that exist.

All we can do here is add messages, we cannot force a default behavior.

tschumilas commented 1 year ago

I think we need to have the concept of a payment intent. Right now - everything is just a 'payment' - whether it is automated or cash. But when a consumer selects a cash (non-automated) payment method at checkout, they are making a payment intent - not a payment. A cash method payment intent is a payment once the cash is received. And I concur it looks very bad that 'invalid' always shows beside cash payment methods on invoices - I get customers asking me all the time what was wrong with their payment. The only option right now is for the hub/seller to go through all the orders and void all the cash payments before they begin the order management process. Its very time consuming.

audez commented 1 year ago

thanks for the input @tschumilas and I think it rings with the discussion in the other issue https://github.com/openfoodfoundation/wishlist/issues/311#issuecomment-1288794509

RachL commented 1 year ago

This need further work before it can be picked-up by a dev: moving to wishlist