I upgraded to 2.1.3 less than a week ago and since then I’ve realized I have several transactions that failed due to a ‘duplicate’ error.
I’m using Payflow Pro. On the store side I only see a ‘failed’ order and the reason is Result: 12; Declined; Duplicate: true;
On the payflow side I see one or more transactions seconds or minutes apart. The first transaction(s) are approved but not classified as a sale. The last transaction is classified as a sale, but it’s declined.
I only had one customer complain and then I noticed I’ve had at least one or more of these every day since upgrading to 2.1.3. I went back several days before the upgrade and didn’t see any issues at all.
I’m thinking this is a bug, but I’m not sure how to report it. It’s not like it’s something I even know how to duplicate.
Anyone else seeing issues? Or would it be only people using Payflow Pro?
Hello Ogia,
This one may very well be an actual bug (not one of them self inficted type of bugs)! 
I believe Johnbol1 is experiencing something very similar using PayPal Standard Payments as posted in one of his recent threads.
Here is the thread link: [url]http://forum.cs-cart.com/showthread.php?t=23182[/url]
My business uses Paypal Pro along with Express Payments and we have not been affected by this.
Thanks for the link, Struck… seems like I remember having an issue with certain characters in a product name before, but I can’t remember if it was cs-cart. I’ll check the orders that were declined and see if they all have something like that in common… 
Shoot - there’s nothing special about the product names, and products that are in one failed order are also in orders that go through successfully.
I guess I will report this as a bug and hope that they can figure it out. In the mean time, I lose lots of $.
I know most people use Authorize.net… any talk of issues with it? I might switch.
ARRGH!!! This sounds like the same issue reported in December and it’s not fixed yet!
[url]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=2319[/url]
:o
[QUOTE]I know most people use Authorize.net… any talk of issues with it? I might switch.[/QUOTE]
From past experiences, they would always be either Number 1 or Number 2 on my list of payment processor choices!
I have never read of a bad experience with them here in the forums either. 
It sounds like it will happen no matter what payment processor I use. I opened a support ticket and I’m waiting for a recommendation.
Yes, will be interesting to see what the cause of this problem turns out to be!
The fix is here:
[URL=“http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=2319”]http://forum.cs-cart.com/vbugs.php?do=view&vbug_id=2319[/URL]
I use the fix in 2.1.2, but the change occurs in the authorize.net payment file so it should work in 2.1.3 as well. The fix adds a tail end to the order number at authorize.net’s end (not seen by customer) that changes with the date and time it was placed. Therefore as fare as authnet is concerned, it is a new order number, but not as far as the customer is concerned.
The fix works perfectly
Prior to 2.1.3, I would see a _1, _2, etc. appended to an order number at Payflow Pro if a payment had been re-attempted.
Now, I’m not seeing that. However, looking over transactions today, there was ONE that had 3 attempts out of 7 that had the number appended to the order number. I don’t know why it would work correctly for a few attempts.
I’ve attached a .gif showing part of today’s transactions. There are three different orders on here that failed for the ‘duplicate’ reason. The one outlined in blue was successful, although I’m not sure what the customer saw since she attempted it 7 times.
I added this to my ticket with cs-cart.
Now I’m really confused… I tested this and it worked as expected. At Payflow I saw the two attempts as 226948_1 and 226948_2 - the first one was declined due to incorrect info and the second was approved because I fixed it.
If I go back through all the transactions since the upgrade I do not see any order numbers with _1, _2, etc. at all. Today is the first day I see it - the one outlined in blue on my screen shot and my test transaction.
Since you reported your issue in an Anet thread, you might be better served by submitting a new bug related to your specific processor. Once a bug is marked closed, I don’t think any comments are ever read again…
I got a reply back to my support ticket and this is the fix I was given in case anyone else is using payflow pro:
payments/payflow_pro.php
In order to fix the problem, please try to replace this part of the code:
$payflow_order_id = $processor_data['params']['order_prefix'].(($order_info['repaid']) ? ($order_id .'_'. $order_info['repaid']) : $order_id);
with this one:
/*[nastena]*/
$payflow_order_id = $processor_data['params']['order_prefix'] . $order_id . (($order_info['repaid']) ? "_$order_info[repaid]" : '') . '_' . fn_date_format(time(), '%H_%M_%S');
/*[/nastena]*/
Hopefully this will resolve the issue.
EDITED: After implementing the fix, the problem has stopped. 
is this going to be patched in a official release?