Not completing payment causes confusing user experience and database bloat

[pignion]

Is your feature request related to a problem? Please describe.

We are encountering a workflow issue with payment methods that place orders before payment has actually been completed. This has been observed especially with the Klarna method, but also includes credit card payments with 3Ds challenges, Apple Pay, and likely others. These issues include creation of canceled orders that are never actually placed, which is confusing to the customer and adds an excessive amount of information to the database.

Cancelling payment partway through order placement causes the following issues:

• Customer sees canceled orders in my account. For example, every time a customer selects Klarna payment then closes the Klarna payment UI, a new canceled order appears in the customers' "My Account" page.
• Canceled orders add an excessive amount of records to the database. For example, every time a customer selects Klarna payment then closes the Klarna payment UI, new records are added the following tables (and probably more that aren't listed) for the never-completed order:
  • sales_order_payment
  • sales_order
  • sales_order_item
  • sales_order_address
  • sales_order_status_history
• Customer is re-directed back to the cart. For example, every time a customer selects Klarna payment then closes the Klarna payment UI, they are re-directed to the cart rather than the page they were previously on (the payment step of checkout). Furthermore they are shown a confusing and inaccurate error message "Your payment failed, Please try again later"

Describe the solution you'd like
Do not place the the order until a payment has successfully been made. This is the approach we've seen with other payment provider implementations, including for Klarna and other methods that interact with third party services.

[candemiralp]

Hello @pignion,

Thank you for creating this issue. Indeed, it's a known situation resulting from an inevitable design choice. Let me explain the order creation flow.

• For any payment method which DOES NOT require an additional action (resultCode: Authorised immediately after /payments call.), order is created after the successful authorisation of the payment. (Ex: NON-3DS card payments.). If payment is refused, there won't be an order.
• For any payment method which DOES require an additional action (resultCode: [IdentifyShopper, ChallengeShopper, PresentToShopper, Pending, Received] after /payments call.), order is created before the payment is authorised. Because, payment will be authorised after the secondary payment action. (Ex: 3DS card, Klarna, iDeal and 99% of alternative PMs). During this time, order is already created and have pending or pending_payment status depending on the action type. Requires OFFER_CLOSED webhook to clean-up abandoned orders.
• For POS, there are two alternatives.
  • if order is selected on the configuration, order will be created first then payment will be initiated.
  • if authorize is selected on the configuration, order will be created after successful authorisation of the payment.

We decided to follow this approach to be on the safe side if something goes wrong while the shopper is on the external payment page (like Klarna). If the connection is lost or shopper abandons the payment, the application will not be aware of the broken flow. Therefore, our webhooks will not be able to update as there will not be an order. Another edge case that we observed is that payment is completed but the network connection is broken before the shopper returns to the shop. Again in this case, even though Adyen gets the payment and sends Authorisation webhook, it will not be processed as there is no order.

The plugin can not create an order during this edge cases (convert quote into order) so we decided to follow this approach.

We would like to hear more why you are trying to avoid having cancelled orders and what the current measured impact is on the performance of your system.

Best Regards,
Can