3 ways Amazon fails to fight scammers. Years old scam is on the rise, now worse than ever

So last day I also run into one of the many scams out there, this time on Amazon. Things felt off from the beginning but as I’m not an experienced user of Amazon’s webshop it took some time to verify it. Unfortunately what used to be riddled with typos and strange sings is now a new industry perfecting their product just like everyone else. And it’s good. I mean bad.

I thought ‘hey, since this bullshit took some time already maybe I can turn it into something useful’. So I started looking into it more deeply and anything I found just pissed me off even more. Just by looking at the sheer amount of unashamed scams I thought this is somewhat new and by bringing attention to it things can change for the better. Well, it turns out I was wrong. This has been out there for a long while and now it’s more dangerous than ever! With that in mind I did something Amazon have yet to do in this case. I adapted to the situation. Let me assure you now, this will not be one of those story telling posts. Instead I will categorically point out what Amazon fails to do or fails to do correctly to stop these scammers.

With this essay I hope to bring light to not only the problem but the (missing) solution.

#1 their game, their rules. bad ones.

First off, lets’s start with that this scam takes place (or at least starts) on the site. I understand that other scams over the phone or via mail are harder to keep in control, but that is not the case here. As explained in this post from early 2015 there are used items listed in the shop usually around half the normal price from brand new sellers asking to contact them via email before making a purchase on the site. What I came across was old accounts sometimes even with good rating selling fraudulently several thousand new items below price with the same condition (pictures #1 and #2).

Regardless whether these are new accounts, old ones or hacked ones, whether they slipped through the review, there’s a clear pattern of selling cheap stuff and giving instructions to email them in a very specific location in every case that I saw.

Remember, this is their house. They may impose any criteria or supervision. The rightful question arises: are they even trying hard enough? And let’s not forget that we’re talking about Amazon, the company famous and proud of their solutions to automate otherwise manual tasks.

#2 scammers are not followed through

Remember that I mentioned thousand of listed fraudulent items? I’ll add that since the one day I’ve been paying attention I’ve seen several of these companies come and go. This lets me conclude that it’s a systematic, automated process. It’s more than likely that the people operating these shops don’t even care if one goes down. It probably takes only a couple minutes to set up a new one.

There are however resources that are limited. One of those is a legit-looking email address. I’ve been blessed with outstanding ones like ‘payment@orders-amazon.co.uk’ or ‘amazon@confirmation-amazon.co.uk’ which align with the company and the email content perfectly. Seriously, even anticipating spam I thought that it’s legit for a second. Sure, confirmation@amazon.co.uk or something like that, looks OK.

And speaking of spam here’s the big issue: non of the 4 email addresses they used were flagged as spam (by google at least).

This gives me the feeling that finding and removing such a company is the end of the story. It’s obvious that in order to prevent future scams Amazon should follow-up on these issues, message the seller, find out as much as they can and shut down as much as they can. Instead these shops actually don’t disappear but only their products are removed. Afterwards I wasn’t notified (as someone who had one of their items in my basket therefore likely sent an email to them), even though it might be not too late to save me from giving my money away to criminals.

Keeping that in mind I’ll go one step further in guessing… If I were the seller being able to set up shop by a click of a button I wouldn’t even wait for Amazon to find me. I’d just go online, gather a few candidates who email me and then remove the shop before anyone could even report it and put it up under a different name the next day. This would allow to preserve my scheme and valuable resources (like email addresses) longer. From the looks of it I can very well imagine that this is the case.

#3 community efforts not supported

The above points may require Amazon to introduce changes and invest efforts. Here’s something on the other hand that would have minimal cost and would significantly improve the situation: give means to the community to take action.

But that is not the case, instead even if you successfully identified a scam you have to go through ridiculous efforts to even try to take action – no results guaranteed. Let me walk you trough it step-by-step:

  1. Go to the ‘Seller Profile’ / ‘Detailed Seller Information’ / ‘Seller Storefront’ pages and look for a possibility to report. None found. The story should really end here. Three clicks at most (report seller -> choose scammer option -> send).
  2. Google ‘amazon report scam‘ to find
    • their support page about scams and phishing. Here you can find no mention of this common scamming practice, but information that is outdated (like weak email address example: ‘amazon-fraud@msn.com’) or just simply useless (like a link at the bottom ‘reporting a phishing or spoofed email’ pointing to the home of the help page where there’s no mention about any of those).
    • page about reporting emails or violation report page where again you can only report emails or a violation on existing order.
    • that it seems Amazon doesn’t even acknowledge the problem. To be able to create a proper report you have to be directly involved with the scammers (via a purchase or email), which is exactly what we all want to avoid.
  3. Finally if you search and read relentlessly you will find articles and forum discussions (#1, #2, #3, #4,  #5, and many more, lots of them on Amazon buyer & seller forums actually). There you will find a possible solution: make a phone call. Yeah, we all love customer service. This is most definitely not what you had in mind when you wanted to help (at this point likely a couple hours ago). And then we have testimonials where people are being sent off with lines like: “All of our Amazon marketplace sellers are genuine so you don’t have anything to worry about”.

so what can i do?

Well, if you have the time you can call them every time. That’s good but it’s no long-term solution. What you should do is raise attention to this issue so that Amazon might actually start to care.

Share this post, share others’ posts, comment on Amazon forums, create new ones, create tickets. Let them know that this is an issue you care about as well – even if you’re not a victim.

And as always, educate your family and friends. Encourage them to shop online but tell them what to do and what not to do.

As a proactive measure unfortunately there’s not much you can do. One possibility would be to keep the scammer occupied: engage in discussion and ask lots of questions. This is what members of the 419 Eater community do. The idea is that the scammers do not prey on other victims for the time being. But maybe they even mess up. I made them click on a redirect link that was recording data of visitors. Got an IP and an approximate location that may or may not belong to my scammer. Other than that you could only do the same as they’re doing: scam the scammer.


[Update 1 Dec 2016]

I was told to point out specifically that all ‘@xxxxxx-amazon.co.uk’ email addresses are fake. Here’s a picture of the very deceptive mail I’ve received from ‘payment@orders-amazon.co.uk’ and a more transparent one from ‘amazon@confirmation-amazon.co.uk’.

Also another testimonial on Amazon’s stand: “Last time I asked Amazon to check the seller because they were selling a product at 40% of the next lowest price, the rep told me that I would be protected by Amazon’s purchase protection, but refused to make a statement about or look into the seller.” Which means you are protected as long as you’re paying through Amazon and you’re willing to go through the hassle to recover your money of course. But if you happen to contact them via email or vice versa and get scammed that way you’re on your own. It also calls into question whether Amazon actually follows up on these issues.

JPA – the uniqueness dilemma & solution

The dilemma

JPA does not support non-primary (often referred to as business) keys. In simple words if you want your entity to have an Id (as you normally do) and an additional composite key – you’re on your own. There are numerous articles and discussions on the subject worth checking out (yep, each word is a different link).

Let’s see if we can find a solution…

Solution #1 – Drop the Id and use a composite key

To have an Id is standard for many reasons. Even if you think you don’t need the Id (yes you do) you’re being forced to deviate from the standard just because of the lack of a better solution – no way.

Solution #2 – Keep the Id as your primary key and define unique constraints

It will be hard to read (as you’ll have to annotate the entity class instead of the fields) but it doesn’t sound that bad. Until.. welcome to EDD, exception driven development. – Not as good as TDD. The JPA has no intelligent way of letting you know whether the object already exists (often referred to as mergeOrCreate) instead it just occasionally throws a ConstraintViolationException in your face.

Meaning your implementation will look something like:

  • Try persisting
  • Got an exception? It’s already in the DB, go and fetch it..
  • No exception? Good.

Don’t you dare calling this a solution user453265436 on StackOverflow!

Solution #3 – Keep the Id, keep the constraints and make your own mergeOrCreate

The idea is to check if the object with the given unique fields already exists before trying to insert it into the DB. Luckily for us the good people of the internet offer some pseudo and actual implementations. Now all you have to do is write hashCode and equals functions for all your entities to be able to compare with tarnsient objects. And write equal criteria as well to be able to compare with persisted ones.

Do I seriously have to code this?! I fill sick already. Best part of my day.

Oh and make sure you can test is somehow. Don’t forget to keep hashCode and equals in sync. Also never misuse hashCode as key. Keep in mind what happens with your hash code if you update a collection.

Best part of my week. And we’re nowhere near multithreading yet – oh man, we’re gonna have such a great time!

Do yourself a favour and do it in a genral way as much as posibble. You might want to think about an Interface for your entities to provide their uniqueness criteria and a common EntityFactory or superclass. For some more detailed insight I recommend reading this post in particular from the above ones.

The solution I came up with is available on GitHub.

Below are some additional issues worth addressing. In some cases they’re part of the implementation, in others I’ll explain why they’re not.

Entity relationships

Pssst.. hey! Listen, don’t even bother just put everything in one entity.

If somehow by the grace of the ORM god you didn’t face the issue of uniquness yet, chances are you’re about to when normalizing your schema. Think about building up your entity in-memory that has a ManyToOne connection (Person and City in my example). When persisting it (besides checking the uniqueness of the entity itself) you need to check whether any connected entities already exist.


You’ll have to implement DAOs for every entity with ManyToOne connection. You’ll need to query that One for each of your Many.

Thought I was exaggerating? Best week ever!

On a sidenote here’s one reason why I prefer Hibernate’s Session API over JPA’s EntityManager API: it updates your object to the persisted state (i.e. assings Id when persisted). It makes synchronizing objects easier.

Those who say the both APIs are the same are dirty liars. They also tend to prefer EM. Don’t listen to them!


Aka. just when you thought it shouldn’t get any worse. I don’t even say “it can’t get worse” anymore.

We have to stop here and clarify how the Persistence Context cache works before we make more harm than good. Despite the many articles and examples that indicate otherwise JPA’s EntityManager and Hibernate’s Session offer an extended Persistence Context which means the cache is not bound to transaction but lives across transactions made from the same EntityManager/Session.

This is where Session’s getCurrentSession() comes into play. Another huge advantage of the Session API over EntityManager is that this method allows the threadsafe use of the API.

All you need to do is set ‘hibernate.current_session_context_class’ in your persistence config to ‘thread’. If you forget about it though you’ll get a nice exception during runtime which is, well, not so very nice…

Aaaaand that’s all for the good news. As for the bad news…

As mentioned before when using constraints you will get an ConstraintViolationException when trying to insert an entry that already exists in the DB. This may very well happen when multithreading even if you check whether the objects exists before inserting via mergeOrCreate because another thread may have created it in the meantime.

This might sound unlikely but when working with big amount of data it will happen – and this is exactly the case when you’re relying on your cache the most.

Why is this a problem? The Session / EntityManager object will be invalidated upon an expection and therefore the cache is lost. Meaning parallel execution will likely make your application slower.


You can avoid the Session invalidation by using nested transactions, however netiher of the mentioned APIs support it. Some others do though (e.g. Spring). If single threading is not an option (e.g. you’re developing a distributed app) you can still use locks.

Batch processing

In some cases this is something that could give you the performance boost you need. It’s not that simple here.

Persisting bigger chunks of data in one Transaction will leave you with probably even more ConstraintViolationExceptions – invalidating the whole Transaction. So instead of persisting multiple entities at once you’ll lose even those that we already persisted within the Transaction and have to start over.

In a single threaded environment that is only the case if the same entries are present within the same chunk. We can actually eliminate this possibility so this might be a possible improvement.

THE final solution?

It’s simple. We kill the batman.

We need support for business keys across application and DB layers. We need a persistence provider that can handle if a business key already exists in the persistence context or the DB.

It’s that simple.