Intermittent Orders Overwriting 4.4.2

Store Builder Questions
1

Hi,

We're running 4.4.2 and we seem to have an intermittent error.

When an order has failed the customer has the ability to pay again,

Rather than creating a new order, the store tries to over write the open / failed order.

I have checked the status settings and the store admin settings and this is not how it should act.

I have created the error in my test environment and turned on the error code and pasted the results below.

An order should never be overwritten,

We need a list of all failed orders, (this would also help battle fraud)

The other issue we have is if someone uses the back button on the browser after placing and order successfully, they can go back select an item they forgot and place a new order.

This then over writes the existing placed order,

Needless to say this has played havoc with the warehouse, the stock level, and items not delivered despite being payed for and also for tax when we import / export all orders.

Has anyone else come across this issue?

PHP Notice

Message

Undefined variable: opt_info

Error at

app/functions/fn.cart.php, line: 2298

Backtrace

			File:
		
			app/functions/fn.cart.php
	
			Line:
		
			2298
	
			Function:
		
			<b>{closure}</b>
	
			File:
		
			app/functions/fn.cart.php
	
			Line:
		
			8211
	
			Function:
		
			<b>fn_delete_order</b>
	
			File:
		
			app/controllers/frontend/checkout.php
	
			Line:
		
			380
	
			Function:
		
			<b>fn_checkout_place_order</b>
	
			File:
		
			app/functions/fn.control.php
	
			Line:
		
			700
	
			Function:
		
			<b>include</b>
	
			File:
		
			app/functions/fn.control.php
	
			Line:
		
			456
	
			Function:
		
			<b>fn_run_controller</b>
	
			File:
		
			index.php
	
			Line:
		
			25
	
			Function:
		
			<b>fn_dispatch</b>
	</div>

Tygh\Exceptions\AException

Message

Duplicate entry '350770' for key 'PRIMARY' (1062)

INSERT INTO cscart_orders (`discount`, `total`, `subtotal`, `shipping_cost`, `promotions`, `subtotal_discount`, `payment_id`, `payment_surcharge`, `profile_id`, `parent_order_id`, `user_id`, `tax_exempt`, `issuer_id`, `b_state`, `s_state`, `email`, `firstname`, `lastname`, `b_firstname`, `b_lastname`, `b_address`, `b_address_2`, `s_firstname`, `s_lastname`, `s_address`, `s_address_2`, `b_country`, `s_country`, `phone`, `shipping_ids`, `ip_address`, `timestamp`, `lang_code`, `company_id`, `status`, `is_parent_order`, `order_id`) VALUES (0, 2500, 2500, 0, 'a:0:{}', 0, 2, 0, 1, 0, 1, 'N', NULL, '----- PERSONAL DATA REMOVED FOR PUBLIC FORUM PURPOSES ------, 'en', 1, 'N', 'N', 350770)

Error at

app/Tygh/Database/Connection.php, line: 1114

Backtrace

			File:
		
			app/Tygh/Database/Connection.php
	
			Line:
		
			488
	
			Function:
		
			<b>throwError</b>
	
			File:
		
			app/functions/fn.database.php
	
			Line:
		
			129
	
			Function:
		
			<b>query</b>
	
			File:
		
			app/functions/fn.cart.php
	
			Line:
		
			941
	
			Function:
		
			<b>db_query</b>
	
			File:
		
			app/functions/fn.cart.php
	
			Line:
		
			1275
	
			Function:
		
			<b>fn_update_order</b>
	
			File:
		
			app/functions/fn.cart.php
	
			Line:
		
			8265
	
			Function:
		
			<b>fn_place_order</b>
	
			File:
		
			app/controllers/frontend/checkout.php
	
			Line:
		
			380
	
			Function:
		
			<b>fn_checkout_place_order</b>
	
			File:
		
			app/functions/fn.control.php
	
			Line:
		
			700
	
			Function:
		
			<b>include</b>
	
			File:
		
			app/functions/fn.control.php
	
			Line:
		
			456
	
			Function:
		
			<b>fn_run_controller</b>
	
			File:
		
			index.php
	
			Line:
		
			25
	
			Function:
		
			<b>fn_dispatch</b>
	</div>

2

I think the difference is philosophy. Like cs-cart, I believe that a FAILED order should be updated so that it becomes successful. This actually avoids a lot of additional administration. One could argue over whether an incomplete order should be created, but because it's usually a communication failure with a payment processor, 95% of the time it is probably the right thing to do.

There are some precautions made for hitting the back button and trying to resubmit. In your case above, they are trying to resubmit from an order that was already placed (and possibly FAILED) by hitting the back button. This will cause the Duplicate ID failure that is shown in your log.

There are 3 different order statuses that are important and often confused. 2 of them can be controlled by the customer and one usually can't be. These are:

Incomplete - The order was created but the payment process failed for an unknown reason (not DECLINED or FAILED). Usually a communication problem.

Failed - The payment processor rejected the request itself (authentication, format, control structures, etc.)

Declined - The payment processor can't fulfill the request (insufficient funds, closed account, etc.)