Improve Order Confirmation

[solverat]

Q	A
Bug report?	no
Feature request?	sort of
BC Break report?	no
RFC?	yes

Introduction

Within some projects, we struggle with order confirmation state / notification. Per default, there is this condition within the notification to trigger the order confirmation message:

The order state "confirmed" will be applied, when a payment changed to one of these states:

• completed
• authorized
• processing

Most of the time, this is fine (especially when using credit card gateways).

---

Issue

Some of our projects are using a lot of different gateways:

• Credit Card
• Invoice (mostly offline)
• Invoice Installment with external processor (with credit checks)

All of them are coming with their own "state logic" and we cannot rely on the order state "confirmed" only.

Examples:

• Credit Cart is usually fine with the order state "confirmed" but that's not always true (Some gateways switches directly to "processing" ⇾ order confirmation dispatched) but then the 3d secure check returns an error ⇾ payment canceled ⇾ user shouldn't have received the order confirmation message
• Invoice installment gateway triggers "processing" ⇾ order confirmation dispatched. But after that (1-2sek later, after the credit check), the payment still can be canceled ⇾ user shouldn't have received the order confirmation message
• Invoice is fine with order state "confirmed"

Possible Solution

It's quite obvious, we cannot rely on the order state "confirmed". But what shall we do?

Notification Rules

Currently, we cannot switch to different notification rules, because some conditions are missing:

• payment gateway
• nested or negative compare container (to achieve "payment gateway is not XY")

These must be available on rule type "order"

---

Of course, happy to hear better / other ideas regarding the "order confirmation dilemma" :)

[dpfaffenbauer]

@solverat it seems to me, and we experienced this as well, that the Processing state should never confirm the order, completed or authorized should. You introduced this change last year: https://github.com/coreshop/CoreShop/pull/2481. I guess we revert that then? Processing does not mean it is paid. completed or authorized does.

[solverat]

Thanks for the quick feedback. I'm not sure about that. I guess we're dealing with a logical issue here:

These states (complete, authorized, processing) "only" confirm the order (So a user is able to see the "thank you" page), but it does not necessarily mean, that the order has been confirmed from payment side.

In #2481, I've added the "processing" part, because some payment gateways only changes to "processing" and 20 min later, they're sending "paid" by server API. If we're removing the "processing", the user never reaches the "thank you" page.

References:

• https://github.com/coreshop/CoreShop/issues/2478
• https://github.com/coreshop/PayumStripeBundle/issues/10

However, we could remove the PaymentInterface::STATE_PROCESSING from these classes:

• CoreShop\Bundle\PayumBundle\Extension\UpdateOrderStateExtension
• CoreShop\Bundle\PayumBundle\Action\ConfirmOrderAction

Everything else should be fine.

[dpfaffenbauer]

@solverat No, Order Confirmation means what it says, it confirms the order to send out the confirmation email. If you have a special payment provider where "processing" means it's fine, then you can create your own Extension that then confirms the order. So I'd say we remove the processing from the confirmation again.

[solverat]

Yes, that's why I've suggested removing the PaymentInterface::STATE_PROCESSING from these classes:

• CoreShop\Bundle\PayumBundle\Extension\UpdateOrderStateExtension
• CoreShop\Bundle\PayumBundle\Action\ConfirmOrderAction