How to handle when customer cancels credit card charge

[DaveM]

Re: How to handle when customer cancels credit card charge

I can turn that into a perpetual subscription model, forcing the owner to make a new payment each period to update the Key.

Mine does that and by causing them to call me, I get to speak with them and make sure they are for real. I think there is a legality in that somewhere, but I am not a barrister.

[jkwrpc]

Re: How to handle when customer cancels credit card charge

I can turn that into a perpetual subscription model, forcing the owner to make a new payment each period to update the Key.

Hmmm ... this sounds familiar :)

[Steve Wood]

Re: How to handle when customer cancels credit card charge

Although I touched on this in the first post, mine is same as Dave, different algorithm to create the long string of course. But it differs in that there is a license number included in the algorithm. The license number is generated when they purchase the item and included in the order confirmation. The other difference is that I have an actual Registration Server at www.alphatogo.com. They enter the license number in my application on their machine, it sends the string to my Registration Server and looks up the License. If found and not already assigned, it shoots back the long string (called a Key). The Key gets saved to the database and removes nag messages from the application. It is machine name dependent, so if they move the app to some other server the nag message reappears. It crosses my mind that with a few small tweaks, I can turn that into a perpetual subscription model, forcing the owner to make a new payment each period to update the Key.

[Paullm]

Re: How to handle when customer cancels credit card charge

"Close-enough" is what I meant!

Got it! ... and thanks!

[DaveM]

Re: How to handle when customer cancels credit card charge

No, but I will tell how I made it. Close enough?

Have registration table(encrypted)
holds id , internal reg, date of reg, what the new reg should be and what he enters

I get the machine name, hd number if it has one, date, I turn all that into a large number that is divisable by "say" 8 and the when the client calls with his number, I dived it by 8. now if I put a 3 on the end - he has 30 days - a 5 is 60 days and a 1 is forever.

Make sense? there is a password protected script, a form and each time the autoexec starts, it checks the 2 numbers in the table to see they match, if not the it goes to the registration form.

[Paullm]

Re: How to handle when customer cancels credit card charge

Dave,

I almost hate to ask, but ... would you share your algorithm?

[DaveM]

Re: How to handle when customer cancels credit card charge

Keith,

See post 7

That is almost what I do.

Customer opens app and is face with a registration code. He has to call me to get a run code. It is a simple math process for me that will never work but one time.

I can give whatever type code I wish to extend for preset dates or forever. If it is all paid, he gets forever.

[Keith Hubert]

Re: How to handle when customer cancels credit card charge

Steve,

This is a nasty thing to have happened and I feel for you. Nobody like to be cheated, in particular when it comes to money.

One idea I had was to make use of the users machine name couple with say the date to make it unique, in an encrypted format which they send to you by email and you send back an unlock key which is good for a set period. Then send a second unlock key after that set period. That should prevent any unauthorised persons from using the app on another machine.

[Ted Giles]

Re: How to handle when customer cancels credit card charge

Steve, I think you commented on one of my posts regarding licensing.
I have an automated system - like you had- which sends a secure key to the user.
This sounds like a pure and simple scam and it should be possible to put a 3 month block on the software if payment is withdrawn.
The world is full of crapola.

[Paullm]

Re: How to handle when customer cancels credit card charge

And even if you would find your customer as genuine customer from the USA, then still you would probably not want to pursue this further since any legal action could cost you even more as it brings you.

Legal recourse is rarely the best solution, simply because of time, aggravation and cost. You have to play at their level! You have to hit them where it will hurt them most ... either in the operation of their enterprise [i.e. where they are using your application to administer part of their business] or in the pocket book [e.g. if they are reselling your software]. The only way to do this is a delayed time bomb that will cause them maximum grief, somewhere down the road.

Also, the incidental "theft" of your product might not even be the greatest problem but you could also be at risk for unlawful copying of your product or your serial numbers if they can crack them.

The solution here is to design your application so that it is "branded" with the company/entity name of the authorized user ... and this name then appears on all screens and reports. This will alert any unsuspecting third-party buyer that all is not "kosher" when they install your software. (By all means show your company contact information somewhere in the application).

You do this by storing an encrypted version of the authorized user name in the software; either as a global variable or hidden in a table. By using an encrypted user name, hackers will not be able to use an hexadecimal editor to find and replace the authorized name with something of their choosing! (To further tighten the screws, store the encrypted authorized name in several places and have your software compare the values ... and simply abort if the values do not match).

Although something I would not bother with, if you really wanted to sock it to the miscreants, have your software subtly corrupt their data ... simply by changing random information in their tables, without being too obvious. (Changes to amounts and dates are usually much harder to spot than changes to [e.g.] names, cities and descriptions).

For instance, you might want to consider not to allow customers to purchase using an anonymous email address like [email protected] or similar. Also, you might want to restrict the area where the customer is geographically based.

This would be difficult to police/implement and frankly, with safeguards like the above in place, I would not care where in the world my application was being purchased!

[DaveM]

Re: How to handle when customer cancels credit card charge

Years ago, we had a system where all monies going into an account at our bank(itwas a credit card only acct) was immediately drawn out to another bank account at another bank. At the time, it worked very well and put the onous on the card holder to show why he should get the money back. His credit card company could NOT just yank the funds. We never used paypal because something like paypal holds the money for a short period and can have money from several sales in your pp account at any given time. That puts pp in a position to go the easy route.

I am not sure the above can be done today, but may be worth looking into.

I am not against or for pp, just thinking of alternatives.

I do use pp for ebay sales and purchases, but that is about it. It is the buyers friend more than the seller and it is not their fault.

[mronck]

Re: How to handle when customer cancels credit card charge

This is a problem that has been around very long already. Generally, these things happen under the anonymity of the internet. I have had to deal with these kind of problems a great deal.
Most of the possible "solutions" mean that you would restrict the customer.
For instance, you might want to consider not to allow customers to purchase using an anonymous email address like [email protected] or similar. Also, you might want to restrict the area where the customer is geographically based. Typically, orders from countries with certain domains are more at risk then orders from your own country.

Typically, your credit card provider will always side up with the customer. And that customer may even be right since the credit card might have been stolen and abused. Most credit card companies do a lousy job in providing you the evidence you need to recognize this as being the truth. So you will question that as well.

Also, the incidental "theft" of your product might not even be the greatest problem but you could also be at risk for unlawful copying of your product or your serial numbers if they can crack them.

And even if you would find your customer as genuine customer from the USA, then still you would probably not want to pursue this further since any legal action could cost you even more as it brings you.
If the customer is outside the USA you can forget that all together, not to speak of your Russian customer, or customer based in Bolivia or such.

Internet fraud is growing, in all types and varieties. Hence personally I would not hesitate to implement a system that would require a second registration number AFTER the rollback period of the credit card company has expired......

[DaveM]

Re: How to handle when customer cancels credit card charge

I do sell online. I do not use stores as such. No paypal at all.

All the software will run between 30 and 90 days before needing to be paid for. When the time comes, they pay and get registered. I give them a 30 or 60 day further so if payment messes up, it stops. It has really only happened a couple times to me, but that second time for the registration worked in both cases.

Yes, time bomb!

If it helps, when they call for a registration or demo extension, I can give them a 15, 30, 60 extension or a forever registration number. That number is based on a lot of things including the date. It cannot be duplicated on another machine or in any other way. call me later and the number has changed. Call me for a different machine and the number is all different.

[Paullm]

Re: How to handle when customer cancels credit card charge

This scenario is always a possibility with online sales/downloaded software transactions.

You really need to incorporate some kind of secondary activation protocol, whereby the software has to be re-registered/re-activated, x no. of days after the initial install. (The number of days might be several months, even a year out ... your choice!)

You could display some kind of interval warning dialog to alert the user and if you are afraid of calling it re-activation, just call it a required "update".

Personally, if I sold software via online download, I would create as much havoc as possible for "customers" that were out to defraud me.

By allowing several months, the software presumably would have become fairly entrenched into the operation of where it was being used ... ILLEGALLY! Or, if it was being resold, this would create some major problems for the miscreant who resold YOUR software!

Reminder: this is software that they have not paid for, so they have no legal recourse when YOUR software suddenly fails to function!

[bea2701]

Re: How to handle when customer cancels credit card charge

The prospects are better if the item ordered was a physical object that was shipped. In that case, there are 3rd party carriers that delivered the item, got confirmation and you can submit this as proof of delivery. For electronic download items, PayPal is clear, there is not much they can do. They agree to go to bat for me with the credit card company if I show "proof", but that is a couple automatic emails going back and forth. Looking at the order now, clues - buyer name is different than on the order, email address doesn't really match up to either name.

Besides losing the cash, I don't like that the claim by the buyer is "Unauthorized payment Chargeback" which suggests I am a fraudulent vendor who simply ran their credit card without permission.

Use Sticky Bone concept for Paypal!

I guess the worst case (other than the lost revenue) is that they buyer's purpose is to take my product download and description and re-sell the items on some other website. I am sure that is a very common practice.

As mentioned below, after this chargeback I altered my product download process to disable_download so I can stop additional download of the product. I also just altered my Framework license process to prohibit registration if the disable_download is True. But the Framework is a special case, pretty hard to do that on small utilities.

I think I will try to improve and automate the "proof" side of things. Not just my Transaction Log but some secondary process whereby the buyer 'registers' upon first use after the product is on their desktop.

Use Stickey Bone Concept for PayPal!