xfrocks / bdPaygates

4 stars 8 forks source link

Prevent users from buying again after chargeback #13

Open Maximvdw opened 6 years ago

Maximvdw commented 6 years ago

The add on implements a way that removes a buyer from the resource when a transaction fails.

Unfortunately I have buyers that abuse this by buying- making a cc chargeback - buying again next update - cc chargeback again.. This can lead to thousands of Euros in cc cost.

I know a solution would be to ban those users, but the platform this add on is installed on does not handle resource disputes/problems.

My proposal is to add a setting to prevent the user from buying a resource of a failed transaction again, or all resources of that author

Maximvdw commented 6 years ago

I should mention that this option is for the administrators and not the authors

Cobwebster commented 6 years ago

Highly desired request, hopefully it can be added since this is a real problem with people who like to chargeback.

daohoangson commented 6 years ago

I wonder how marketplaces deal with this kind of abuse? If we implement this block, the user can just register a new account to avoid it I think.

Legoman99573 commented 6 years ago

This has been a problem in the Spigot Community and vouch for @Maximvdw.

This was a problem for over a year reaching its 2nd year: https://www.spigotmc.org/threads/prevent-users-from-buying-again-after-chargeback.157721

I dont use xenforo myself, but the payment gateway can be abused in large communities and will spiral out of control.

daohoangson commented 6 years ago

As mentioned in the linked thread, any measures implemented from our side (e.g. IP check, account ban) can be easily bypassed if the user really wants to download your resources (and have a credit card available). For this specific issue with charge backs, probably it's better to provide better documents for PayPal's disputes, just maybe?

Cobwebster commented 6 years ago

You can win a lot of paypal disputes by providing proof the buyer and the chargebacker are the same person, aka same IP. Sadly Spigot doesn't provide you with the buyers IP and any attempt to get this changed gets shut down due to the VPN argument. Seems like even though features like the ones requested here or requesting of more information just gets denied because of the worst case scenario.

The real issue is that these suggestions get denied because it wont 100% solve the issue so it gets laughed at, despite the fact it would for sure bring down chargebacks a considerable amount. Even though users could just make a new account and buy it again under a different card, the amount of people willing to do that is a lot less than what we have right now. Typically spigot blocks temp emails (10minEmail) and people don't really wanna get banned because its a very rare case where 1 accounts sole purpose is for 1 premium resource. (they'll buy multiple per account, its not worth the risk if you get banned and you have other purchased resources)

I don't think there is 1 feature change which can solve the chargeback issue, its a lot of little changes which bring down the maliciousness of chargebacks as a whole. aka better banning, more information for disputes.. etc... The less viable it is.. the less people do it.

Legoman99573 commented 6 years ago

@daohoangson The problem is the site wont work with an investigation unless its repetitive, but even so, they still ignore it.

Maximvdw commented 6 years ago

@daohoangson PayPal does not provide ways to block a specific user - they are really good in enforcing/preventing anything that gets them in problems such as alternative accounts.

The user can indeed create a new account to avoid that, however my proposal would be to prevent/block purchases from the paypal account and user that used it.

In a big marketplace like SpigotMC there is no point for moderators to keep up with the daily chargebacks and disputes. The "remove buyer" feature in bdPaygates provides a good automation - but it opens the vulnerability for repetitive buying/chargebacks. The more automation there is for the most recurring problems the more time moderators have to do other things

Use case: User A buys resource A from author X User A chargebacks resource A User A can not buy resource A again [ Setting ] his paypal is also blocked from buying resource A (in case he creates an alt) User A can not buy any resources from A again [ Setting] User A can still buy resources from another author depending on settings

Blocking both the paypal + user prevents alts. They would have to create an alt xenforo +alt paypal but paypal is very strict on alts.

Again, this won't block everyone, but it will prevent the kids that buy things with their parents credit card

TL;DR; My request is to add a 4 settings 1) "Block users from buying a chargebacked resource" 1.1) Block both the user's paypal and account from buying 2) "Block users from buying resources from an author of a chargebacked resource" 2.1) Block both the user's paypal and account from buying

daohoangson commented 6 years ago

Technically we cannot block by PayPal account because we do not know user account until after PayPal confirms the transaction. By that time, the payment has already transferred and if we choose to NOT release the download, the logic will be quite complicated, e.g. initiating a refund automatically or requiring manual approval. Thinking about it, requiring approval will probably the best option here but it's a major feature and maybe won't be included in this version since the whole ecosystem is moving towards XenForo 2.

That leaves us with the options to block user from buying resource and/or from buying resources from the same owner.

Maximvdw commented 6 years ago

Manual approval would be bad. Seeing I get around 30 purchases a day that would mean a lot of work. Don't think authors would like that.

The user block would already be a great benefit. As for the PayPal problem in the future: It would be possible to let them log in first and handle the payment later. Like ecommerce sites where you login, you go back to the merchant site where you get a final overview, you click pay and it's done. Only after clicking that last button the payment is handled.

It is called "seamless checkout" https://developer.paypal.com/docs/integration/direct/identity/log-in-with-paypal/

Maximvdw commented 6 years ago

Experimented with the login API again (was a long time since I last did). I think the following use case would work and even allow for more features in bdPaygates in the future:

1) When you click the purchase button you go to paypal login (like you would when you buy) 2) After logging in you are redirected to the merchant side (your standard OAuth redirect) It is at this point that you have the user information of that paypal. The payment has not been made yet, you just let them log in. You can either show a "blocked purchase" message or do whatever you want. 3) Either let the users view a final overview of their purchase (maybe a TOS or some custom message I dunno) or redirect them to the 'seamless checkout' 4) They get a final overview on the paypal site where they click "pay" to complete the transaction

The changes wouldn't need to be very drastic actually. Seeing paypal only allows for 15 minute session there is no real point in keeping/storing them - the transaction itself works the same as it does now. The only difference is the three step checkout (1- login 2- confirm 3- pay) instead of (1- login 2- pay)

daohoangson commented 6 years ago

The PayPal login flow unfortunately does not align with the current system design. Basically the system was built with supporting multiple payment gateways at the same time so it cannot go out of its way to support a specific PayPal feature. I will need to discuss with md_5 to implement this for Spigot.

Maximvdw commented 6 years ago

I gave this some more thought, I understand that you want to keep support for other gateways. Lets assume we can ban users that abuse chargebacks, they could create an alt. Seeing we could potentially only prevent this by blocking the paypal I was thinking of maybe allowing 'constraints' for resource publishers?

It would use some basic things like "minimum posts", "account age", ... basically how xenforo permissions work but configurable per resource. Or things like "required resource" to let them only buy it when already owning a specific resource or having downloaded a free resource