Advise needed to change the format of INVNUM, to fight duplicated orders?

Zen cart 1.57d, php7.4

one-page checkout 2.4.5. Paypal express & paypal payment pro

We received intermittent duplicated orders when customer paid by credit card/paypal payment pro, like once per week. And it seems getting worse and worse. One pattern I noticed that, in the paypal log files of those duplicated orders, the INVNUM or order number are very close to each others (1s difference or so). PayPal has a function to auto-deny the transaction if both transactions have the same INVNUM numbers.

Here is the github link for paypalwpp.php I'm currently using:

https://github.com/zencart/zencart/b.../paypalwpp.php

I did some search and INVNUM is related to line 396 as the following:

$options['PAYMENTREQUEST_0_INVNUM'] = (int)$_SESSION['customer_id'] . '-' . time() . '-[' . substr(preg_replace('/[^a-zA-Z0-9_]/', '', STORE_NAME), 0, 30) . ']'; // (cannot send actual invoice number because it's not assigned until after payment is completed)

In the log file I received, INVNUM is like 1095xx-167700xxxx-[webstore] So the 10-digit middle section of the current INVNUM is generated via time().

I changed this line to the following code and I expected the new INVNUM format is like 1095xx-167700xx-[webstore]. So the middle section will be 8 digit only.

$options['PAYMENTREQUEST_0_INVNUM'] = (int)$_SESSION['customer_id'] . '-' . (floor(time()/60)) . '-[' . substr(preg_replace('/[^a-zA-Z0-9_]/', '', STORE_NAME), 0, 30) . ']'; // (cannot send actual invoice number because it's not assigned until after payment is completed)

However, it doesn't work. By my new test, INVNUM format is unchanged (verified in paypal side and the log files).

So what is the proper way to change the format of INVNUM value? Any suggestions are appreciated.

I think I found out the reason.

paypalwpp.php => paypal express checkout
paypaldp.php => paypal payment pro.

In a word, I changed the wrong file... I will report later.

It works in paypaldp.php.

https://github.com/zencart/zencart/b...t/paypaldp.php

I changed line 803 to the following

$optionsAll['INVNUM'] = (int)$_SESSION['customer_id'] . '-' . (floor(time()/60)) . '-[' . substr(preg_replace('/[^a-zA-Z0-9_]/', '', STORE_NAME), 0, 30) . ']'; // (cannot send actual invoice number because it's not assigned until after payment is completed)

then INVNUM is updated correctly (verified in paypal.com). I tried it and no warning/log was generated. Let's wait and see if it will help for the duplicated orders.

Theoretically, even the zen cart generates duplicated orders when one customer tries to checkout for some reasons. All those transactions will have the exact same INVNUM number. So paypal.com will deny all the duplicated transactions. It will change the time resolution from 1sec to 1min in the INVNUM number.

Update: After two weeks impatient waiting, our live site just received a duplicated order! This time, paypal denied the duplicated transactions because they all have the same INVNUM number! Our site only received one order and our paypal only received one payment. Yeah!!!!

It looks like there might be some bugs inside of the complicated paypaldp.php which may cause intermittent duplicated submissions. If you have the same issue as mine, you can try the trick in this post.

Lots of PayPal was touched in 1.5.8 and probably more to come in 1.5.8a

@njcyx would you be willing to submit a PR?

Quote:

---

Originally Posted by dbltoe

Lots of PayPal was touched in 1.5.8 and probably more to come in 1.5.8a

---

Hi @dbltoe, thanks for your info. I haven't tried 1.5.8 in my live site yet and I will probably update my site to 1.5.8a directly later. Hopefully it will solve the root issue which cause the duplicated orders.

Quote:

---

Originally Posted by swguy

@njcyx would you be willing to submit a PR?

---

Done. Here is the link for my PR. Actually it is my first time to submit a PR...lol.

https://github.com/zencart/zencart/pull/5650

Update. Our site just received another duplicated order. The reason is, the interval between the duplicated submission is over 60s. Not sure why but our site tried to submit a total of 6 times for this order.

I will update my interval in my code from 60s to 150s (2.5 mins) and see if it helps.

Also, I'm not sure if it is normal that paypal will take about 3s to process each payment submission?

Timestamp by the paypaldp log files:

2023-03-18 10:18:03 success INVNUM 27985818
DoDirectPayment, Elapsed: 3047ms -- Success

2023-03-18 10:18:04 Failure INVNUM 27985818 Paypal auto denied
DoDirectPayment, Elapsed: 2508ms -- Failure

2023-03-18 10:18:04 Failure INVNUM 27985818 Paypal auto denied
DoDirectPayment, Elapsed: 2509ms -- Failure

2023-03-18 10:19:11 success INVNUM 27985819
DoDirectPayment, Elapsed: 3119ms -- Success

2023-03-18 10:19:12 Failure INVNUM 27985819 Paypal auto denied
DoDirectPayment, Elapsed: 2926ms -- Failure

2023-03-18 10:19:12 Failure INVNUM 27985819 Paypal auto denied
DoDirectPayment, Elapsed: 3107ms -- Failure

Update. Our site just received another 10536 error for the duplicated payment. I checked the log files and I have some found.

There are two customers: A and B.

A submit the order on 20:12:07 and went through. B submit a different order on 20:12:09 with the same INVNUM number, and it was denied.

The payment of B was resent on 20:15:49 and it went through (different INVNUM number). I'm not sure if the customer resent the payment or zen cart did.

According to the post before, the format of INVNUM is like xxxxxx-xxxxxxxx-[webstore]. If you are using one page checkout module like I did, the first section will be exact the same (unchanged) for the customer id.

So in a word, by the mod, two customers cannot place the different orders at the same time during this preset interval. It is less likely but it could be a little bit annoying.

Update. I received two duplicated submission cases over the weekend. Both are intercepted by this mod in this thread properly. No duplicated payments are received. Now I'm using 120s (2m) delay time.

Case #1
2023-04-29 12:15:34 INVNUM 14023207
DoDirectPayment, Elapsed: 3159ms -- Success

2023-04-29 12:15:34 INVNUM 14023207
DoDirectPayment, Elapsed: 3640ms -- Failure

2023-04-29 12:15:35 INVNUM 14023207
DoDirectPayment, Elapsed: 3832ms -- Failure

Case #2
2023-05-01 08:12:26 INVNUM 14024526
DoDirectPayment, Elapsed: 3060ms -- Success

2023-05-01 08:12:28 INVNUM 14024526
DoDirectPayment, Elapsed: 2460ms -- Failure

2023-05-01 08:12:28 INVNUM 14024526
DoDirectPayment, Elapsed: 2777ms -- Failure

2023-05-01 08:13:43 INVNUM 14024526
DoDirectPayment, Elapsed: 2512ms -- Failure

Quote:

---

Originally Posted by njcyx

Done. Here is the link for my PR. Actually it is my first time to submit a PR...lol.

---

Thanks for doing this - hopefully we'll see more PRs from you in the future!

Update again: I just changed the INVNUM interval back to 60s. I used the 120s interval in the past two months. I haven't received any duplicated orders and this trick didn't trigger as designed. But I received two "Friendly Fire" in this period: two customers tried to checkout with credit card (OPC) in two minutes, so later transaction was blocked.

I started to think, this issue may be due to the ISP/server, since I didn't change paypal code other than INVNUM. Not sure.

60 might be the right balance of risk and reward.

Possibly yes. I used 60s in my PR.

As it is said, "The first draft is always perfect"...lol.