Home » Projects » Ubercart Contributed Modules » Ubercart Contributions » Issues

Updating order that awaits payment may lead to data inconsistency

Submitted by SiliconMind on Mon, 08/31/2009 - 12:43
Project:Ubercart Contributions
Component:Code
Category:
Priority:critical
Assigned:Unassigned
Status:active
Description
Project: 
Ubercart

Recently I've been coding new payment methods for Ubercart (Polish gateway) and I've hit a serious design flaw.
Consider this scenario:

  1. Customer submits an order.
  2. Payment method has been selected and customer went through payment process.
  3. Payment verification takes some time - eg. two days for standard money transfers during weekends.
  4. Before payment arrives admin is able to edit order which is fine if he changes only billing or delivery address. But what if he'll add or remove order items? Or change their price?
  5. Order total price changes! But customer has already paid!

The problem:
There is no way for payment module to prevent from changing order price when order awaits payment.
But! There is more!
Even if payment module would like to cancel old and create new transaction with accurate price after order price changes - it can not! Why? Because when Ubercart invokes payment callback (defined in hook_payment_method) it passes order object with old total price (that is the price that was BEFORE admin changed it).

The conclusion:
Current design that does not allow payment modules to react on order price change is wired and counter intuitive. Especially if you look at hook_order which allows anyone to refuse order status change or order deletion, BUT NOT saving order changes. This may lead to serious data inconsistency.

Suggested solution:
Allow blocking of order editing by payment modules through callback defined in hook_payment_method. Modules can block order submission ($op = 'order-submit') so I don't see why it couldn't be done for order editing ($op = 'edit-process').
OR
Allow blocking of order saving by modules through hook_order function the same way it is done for $op = 'can_update' and $op = 'can_delete'.

Version: 
Ubercart 2.0-beta6
Mon, 10/05/2009 - 05:41
#1 View page
xibun
xibun's picture
Offline
Joined: 05/13/2009
Juice: 105
Re: Updating order that awaits payment may lead to data inconsis

I suggest you change the store admin instead.

Top
Mon, 10/05/2009 - 09:19
#2 View page
Lyle
Lyle's picture
Offline
AdministratoreLiTe!
Joined: 08/07/2007
Juice: 6854
Re: Updating order that awaits payment may lead to data inconsis
Assigned to:xibun» Lyle

I don't really think Ubercart should prevent the store administrator from changing the order at any point. I believe it's fairly common for a customer to at least ask to change their order even after they have paid. They may want to add another item and try to get it put on their first shipment to save money. They may not realize they mistakenly ordered too many things until after they have paid.

For the window of time between the customer paying the money and the vendor actually receiving it, I think it is the payment gateway's responsibility to know the amount of the payment, independent of the order total. This may mean that the current modules need to be reviewed and patched if needed. But I don't think the solution is to prevent the order total from changing.

Top
Tue, 10/06/2009 - 06:02
#3 View page
SiliconMind
SiliconMind's picture
Offline
Joined: 08/31/2009
Juice: 24
Re: Re: Updating order that awaits payment may lead to data inco
Assigned to:Lyle» SiliconMind

That's a good point. But for now ubercart does not provide any means of tracking multiple payments. There are also other issues.
I was fixed on blocking because it seemed the simplest solution. You made a good point on multiple payments for one order and order correction but this, as I understand, needs far more work inside ubercart core.

Top