- This topic has 9 replies, 3 voices, and was last updated 14 years, 2 months ago by
.
-
Posts
-
I think the stats are a little broken when a fraudulent purchase comes back and doesn’t validate. Let me explain:
I have a product in my eStore that sells for $39.99. It doesn’t sell very often but when it does, it’s easy to calculate the average price on it, because there’s very few of them. This month, I’ve had one legit sale so far.
In addition to the legit sale, I also had one guy from Romania try to game the system and pay $0.01 for everything. eStore denied him the download links, of course (woot!). This $39.99 product was one of the ones he tried to get. So for this month’s tally, that’s one valid purchase of this product, with two purchase attempts.
However, it seems to have counted (incorrectly) them somewhere, because now my Stats page shows this:
Product: Ave Price Sales Total
Google Checkout Module 19.99 1 19.99
The product page price clearly shows $39.99, so that’s not the issue.
That would only be the case if the avg price somehow counted the fraudulent transaction. The Avg price should be closer to 39.99 (discounting fees from PP of course).
I’m on 4.0.6 of eStore. Is this fixed in a new version? If not, can it be?
Fraudulent sale attempts do not get counted for sure (the stats are only updated after the payment is cleared and passes the fraud checks).
I have a feeling you may have done a test transaction with $0.01 before going live to see how everything goes? Is this a possibility?
Hi amin,
Nope, this is on a live site. And it clearly counted, otherwise I wouldn’t see it in the stats. The math doesn’t lie.
The only reason I was able to notice it was the fact that it was a product that rarely sells. 39.99/2 = 19.98, so assuming the .01 is a rounding issue or something, it makes sense that the sale was counted (2) but the actual revenue was not ($39.99 instead of $79.98).
Can you try simulating this in your sandbox to see? Or would you prefer to login and verify in my site?
@awpcp — By any chance, are you able to examine the wp_eStore_sales_tbl in the MySql database? If so, look for the transaction that matches the product ID in question. The customer e-mail address, to whom that sale is credited should be there.
Actually, the problem is much more severe than I originally described, based on what I just saw in that table, comparing it with actual sales data:
So, here I have one customer who bought 4 items from me on 9/1/10:
Email Sale Date Time Prod ID Amount NOTES (mine)
customer@customer.com 2010-09-01 14:48:13 1 19.99 <—- Should be $10.99!
customer@customer.com 2010-09-01 14:48:13 3 19.99 <—- Should be $39.99!
customer@customer.com 2010-09-01 14:48:13 5 19.99 <—- Should be $5.00
customer@customer.com 2010-09-01 14:48:13 8 19.99 <—- This is Correct (only one)
Those sales figures are just plain wrong! My prices for the individual items are different than those prices. The PayPal email has the correct data:
Product Title 1
Item #: 1
$10.99 USD 1 $10.99 USD
Product Title 2
Item #: 3
$39.99 USD 1 $39.99 USD
Product Title 3
Item #: 5
$5.00 USD 1 $5.00 USD
Product Title 4
Item #: 8
$19.99 USD 1 $19.99 USD
And now I suddenly see the source of the 19.99 for the 39.99 product! Product ID 3 was purchased once, but erroneously recorded in the database as $19.99, not $39.99. Looks like there’s some bug in the tracking of the data, where only the last price of the list of items purchased is inserted into the database.
I see this with every multi-item purchase made this month. And in previous months.
HELP!
Here’s more sale data from that estore_sales_tbl in case you’re not convinced:
Customer 1 2010-09-05 17:46:08 4 21.99
Customer 2 2010-09-06 10:42:13 5 21.99
Customer 2 2010-09-06 10:42:13 4 21.99
Customer 3 2010-09-06 15:37:11 2 19.99
Customer 3 2010-09-06 15:37:11 5 19.99
Customer 3 2010-09-06 15:37:11 8 19.99
Customer 4 2010-09-07 16:53:08 2 25.00
Customer 4 2010-09-07 16:53:08 7 25.00
Notice that in every multi-module sale, no matter the product IDs (which are always different when a customer buys a set of items), the amounts are always the same. It just *happens* to work when there’s only one item in the basket.
Okay, so let’s try to confirm something… is the actual amount of monies in your PayPal account, for each transaction correct? Not from the PayPal e-mails, but from logging into PayPal and looking at your transaction history. If so, Amin can focus on any eStore bugs; instead of possible fraud exploits.
Discovered the bug. It wasn’t entering the correct product price in the sales data table for multiple item checkout. Fraud attempts won’t pass eStore’s verification and won’t come to the stage where it updates the stats database.
I have sent you a new build. You can manually alter the values from PHPMyAdmin fro your existing sales or start fresh by deleting them.
Thanks for the update. I’ve installed it, but is there any way you can send me a query to fix all the bad data in the database? This bug essentially means my sales reports for the trailing months are all junk right now.
All your sales data is in your PayPal account so you just need to look at them and modify the database value from PHPMyAdmin. Remember how you looked up the values in the database before? There is an option to edit the columns from that same view. I don’t have those data to write a query for you. Why not just delete these values and the future ones will be captured correctly? It doesn’t affect your customer or any other process in the business. The stats data is there for you to take a look and see how sales are going without having to log into your PayPal account all the time. So for the current month you will have some inconvenience but from the next month you will have fresh data.
- You must be logged in to reply to this topic.