It's not the $7, but the principle | Hacker News Reader

It's not the $7, but the principle

antti.vilpponen.net

84 pointsvilpponen64 comments

From the article: " I entered my credit card number with spacing like 1234 1234 1234 1234 and all the other information as necessary. After I clicked “Submit your order”, the form returned an error and asked me to fix the credit card number so that there are no spaces ..."

Why do so many web developers insist on forcing me to enter a 16 digit number _without_ spaces when a computer is excellent (and fast) at removal of spaces and I am not so good at validating I've typed a 16 digit number correctly when that number lacks the spaces?

A lot of programmers are terrible at their craft.

And "programmer" means many things, even once hired and working.

And/or management that doesn't allow devs to spend time on user-friendly features.

Really? You think management is standing over the programmer's shoulder going "Whoa whoa whoa... the length validation was acceptable, but removing spaces for them? Simply indulgence. Just throw an error."

In any case I can imagine it would take less or equivalent code and time to do a string replacement than handle generating and reporting the error. In my experience, it's primarily been inexperienced programmers.

Not exactly. Typically it would be to keep them so busy as to never have time to get to it. If you don't actually use the feature it's not gonna be a priority.

Also, in some places you are not allowed to check in code without a ticket or req number. When you check in on your own you commit qa and others to support it, and other devs to maintain it. Big bureaucracy sucks but exists and sometimes even has good reasons.

This is a trivial example though, but you get my drift. I agree it sucks, just trying to explain how it happens.

Maybe they had more pressing concerns? Perhaps they believe their time is better spent improving their product (providing more value) rather than automatically removing spaces in a credit card form? Maybe the OP was the first to find it particularly vexing / frustrating?

All of these things are tradeoffs. Especially in small, young organizations... it's not reasonable or realistic to polish every single thing. In fact, not focusing on this particular element probably aligns with pg's #1 "hardest lesson for startups to learn": http://paulgraham.com/startuplessons.html

EDIT: In this case... it's talking about FastCompany, so "startup" probably doesn't apply. But most journalism companies are really hurting right now, so allocating resources is still probably problematic. The shady customer service is the more damning thing.

"We have more pressing concerns than calling string.replace()" -- ? I don't think this particular case quite rises to the level of a "tradeoff." It's a single function built into just about every high-level language.

Last time I implemented a CC regex, it was a little more involved than just removing empty spaces. So you see... Your trite example fails to pass muster just as well. (Anymore, I'd just use one of many Stripe libraries... no fuss, no muss.)

really though, it's not that hard to write a simple regex or few line replace command to make the form dead simple to use. creditCardString.replace(" ", "").replace("-","").replace(etc...)

or, if you can use a regex in a sane language replace("[^0-9]", "") then check for the length of the credit cards that you are using. shouldn't take a dev more than 5 min to code and test. Your argument is not really all that valid.

That's exactly what I do whenever I expect a number like this. For instance, phone numbers... Normalize them by replacing all non-numeric characters /then/ validate them. I can't imagine trying to validate the hundred different formatting variations for phone numbers.

I completely agree that the user's experience of using a form should be well thought out, and that error messages like "please remove spaces" shouldn't be part of any well thought out form, but suggest that anything is free of trade-offs is absolute nonsense. That `string.replace()`, along with all the others for all the other things your well thought out form does the thought-at-the-time-to-be-right thing with open the door to both bugs and user confusion. It's worth it, but it isn't free.

Does seem like an 'honest' bug. I did what the OP did (except I checked the middle option), and when you then look at the source of the page, it includes

  <div style="margin:20px 10px 32px 0px;padding:0;background-color:#eeeeee;border-bottom:#cccccc 1px solid; width:220px; height:300px; background:url(images/print-int-2013.png) no-repeat; float:left;"><input name="cds_term_value" type="radio" id="radio" value="1"  style="margin-top:138px;margin-left:10px;" /></div>
  <div style="margin:20px 10px 32px 0px;padding:0;background-color:#eeeeee;border-bottom:#cccccc 1px solid; width:220px; height:300px; background:url(images/digital-int-2013-v2.png) no-repeat; float:left;"><input name="cds_term_value" type="radio" id="radio" value="2" CHECKED style="margin-top:138px;margin-left:10px;" /></div>
  <div style="margin:20px 10px 32px 0px;padding:0;background-color:#eeeeee;border-bottom:#cccccc 1px solid; width:220px; height:300px; background:url(images/bundle-int-2013.png) no-repeat; float:left;"><input name="cds_term_value" type="radio" id="radio" value="3"  style="margin-top:138px;margin-left:10px;" checked="" /></div>

The 'div' that you had checked earliers has an empty 'CHECKED' attribute, while the third one has the 'checked=""' that firefox apparently picks up.

I mean, if they're going to do everything in ugly inline CSS, it doesn't surprise me that they didn't check to see whether or not the user selection of the subscription reset upon reload.

Agree. The author is jumping to conclusions her. Remind me of this great quote:

"Never ascribe to malice that which can adequately be explained by incompetence" - Napoleon Bonaparte

Beat me to the quote. But this is even worse for FC - they are pissing off a customer for $7 by accident, not on purpose.

Nope. They make $$$$ by having the option checked by default, and every now and then a customer fails to check their order before submitting it.

Probably not a Bonaparte quote. The below is an interesting history of how that quote got into the hacker consciousness. Mostly from the Jargon file.

http://en.wikipedia.org/wiki/Hanlon's_razor

I had never read that! Charming. The punchline is, it's actually Heinlein's razor. Which makes perfect sense.

(yes the wiki refers to a Robert Hanlon of Scranton, PA. This is probably only amusing if you're from America and know that Scranton is the archetypal funny place to be from)

> Scranton is the archetypal funny place to be from

Up there with Walla Walla, Washington and Sheboygan, Wisconsin.

Oh my god, how I hate forms that reset themselves over an error! It's newsletter subscriptions... or the misc textarea... or something... that gets lost when I enter a Canadian post code with the space in the middle. Or without the space in the middle. Both have triggered errors :(

Why can't you people just use Drupal which has a forms system that I have contributed to a lot and it handles rebuilds like this with ease :) ?

Because drupal does a lot of other things "interestingly", for example account name and email-validation?

What's so bad about account name an email validation in Drupal? It's one of the few apps/CMS/frameworks that get it right and allow people to use their real name instead of forcing them to come up with some poor ASCII-only string to represent them.

I was with you, and was about to upvote, until I saw your "solution" to forms resetting themselves on error was to use Drupal....

There's no evidence to suggest that this was malicious in any way, nor anything to suggest that FC intended to "trick" him. Plenty of service implement these types of defaults, and bugs occasionally happen.

He's taking a presumptuous "principled" stand against something that is not necessarily an ethical issue. Sometimes shit just breaks. He has no idea whether there was any malicious intent, nor has he even finished dealing with FC customer service. (I bet they'll give him a refund.)

He is writing a screed based on an unproven assumption about an incident that will probably be amended by FC. This seems like linkbait.

The company's web page is their agent to the web world. No matter why that agent cheated this guy; its the companies fault. That's how agency works.

Sure we as engineers can diagnose what web error caused the issue. But we can also surely imagine its not the first time tech support has handled the matter, and its still a problem.

At this point there is plenty to blame the company for, even with a liberal tolerance for incompetence. Why not fix the bug? Its easy to not fix a bug that's raking in money.

To be called a responsible company, they have to fix those bugs FIRST.

Could be something to report to submissions@darkpatterns.org

  http://darkpatterns.org/submit_a_pattern/

This might be subject to a chargeback. After all, they "sold", and charged, you something without your consent, didn't they?

I'm not sure how it is in Finland but here in France it's very difficult to do a chargeback... I tried once for something that was never delivered and my bank blew me off. It's nowhere as easy as in the US.

It's not even that that I lost the chargeback, it's that they didn't even let me initiate it.

I use AmEx in the US and I have never lost a chargeback once. But then again, I don't abuse it..

You'll need to jump through some hoops for that. Here in India, the bank's credit card department head didn't even know about chargebacks, and didn't believe me even after I showed him the Visa Regulations on Visa's website. I had to call customer care over 10 times and talk to the supervisors nearly every time before I found a person who was able to send me the chargeback form. Hell, the bank's local branch didn't believe me even after seeing the chargeback form.

After I got the chargeback form though, dealing with the Chargeback Department was a breeze.

Very interesting. I remember back in the late 60s and 70s when credit card adoption raised in the US, charge back was a key selling feature. Customers refused to use cards that didn't offer it.

Makes me wonder how the world is going to change when BRIC economies get bigger than the current "developed" ones (if ever). Banks and other oligopolies may get away with far lower customer, privacy, heath, etc. protection.

Your bank has nothing to do with it. You need to contact your credit card company.

(Chargebacks are a credit card thing, the CC company is an intermediary, so you can complain to them about poor service. If you use your bank card to buy things online, then you've paid - and it's between you and the vendor. That's why you should always use a credit card to make online purchases.)

I don't know about the parent, but where I live, credit cards are most commonly issued by banks.

Afaik, credit cards are always issued by a bank.

To be fair the OP hit submit on a form that clearly showed what was going to be purchased. It was a shitty bug that reset an option after he incorrectly entered data, but the OP certainly had a chance to see what was being ordered. The right move would be for FC to just refund the $7 and fix the template.

Why is this on the front page? It sounds like a bug with a web form and a problem with non-responsive customer service, neither of which are uncommon.

Because people would rather believe a provocative falsehood than accept a benign truth.

This one's going in the quote bank. So, so true.

convienient bug, I wonder how motivated they will be to fix it.

Because the periodical is one of 'ours' - a tech industry rag. Its possible we hold them to a higher standard, and rightly so.

It's not like they intentionally "tricked you" into buying something, it was just a bug in a web form. Bugs happen.

But you're responsible for your bugs, so it's their job to offer easy refunds in that case.

Indeed, but the article doesn't say they refused a refund. The bug seems deeper than just their front end, their back-end is showing the "wrong" (actually right) subscription selected, but their payment provider clearly charged for the wrong one.

So I guess they now need to consolidate their payments received (likely via a payment provider) with their own system to see if this or any other orders are inconsistent.

They should refund the OP, and I suspect we'll see them do just that. But they also need to both fix their front end but also add automated systems to consolidate payments with orders to see if they match.

OP here. They haven't refused of a refund per se, but since I am unable to reach them with the second request - it is comparable to "let's leave this be and maybe it will go away".

If it's really just a front-end bug, chances are they're getting lots of calls just like yours. You may just be part of a pile of callback tickets once the bug is fixed and all the refunds are processed. Or, they could still be trying to track down the root cause of the bug in the first place.

There is also a branch of optimization aimed to produce "bugs" like this. I wouldn't be too surprised if they knew about this and just don't want to fix it as it produces orders.

http://searchengineland.com/evil-conversion-when-optimizatio...

Perhaps. But if they are aware that their system has a bug, and that bug results in them getting extra money from customers without the customer's consent, then you're entering into a lot of tricky waters. The clock has started ticking for them before they enter "fraud" category.

Seems like a clear case for Hanlon's Razor:

Never attribute to malice that which is adequately explained by stupidity

It might be a bug, but the networksolutions.com checkout process also acts opportunistically when you add a domain to a new account. It will ask if you want to 'auto-renew the purchased domains AND all others you previously purchased'. If you change the setting to 'don't auto-renew' and then make a validation error (miss the terms of service checkbox), it will keep state for all other fields, but magically the auto-renew value switches back to the default.

Both parties are clearly in the wrong here.

Fast Company should ensure the product selection doesn't reset to default when the form is submitted and returns an error.

The customer should double-check their order before hitting submit. Like it or not, they had the more expensive product selected when they submitted their order. How are Fast Company supposed to know the product you had selected is not the product you wanted?

Naturally the user is always responsible for the purchase he/she makes. However, if I (OP) make my selections and need to re-enter some information based on their request - I don't think that allows them to change my decisions from what I have chosen earlier, especially if you get an error message similar to "please check your credit card number".

It is also a de facto standard in general that sites do not change once set selections when fixing errors in the original form and once you differ from this you're bound to increase burden on your customer support.

Precisely. It's bad practice on the part of the retailer, and if I were in their shoes I'd refund the customer immediately as a gesture of goodwill.

That said, it does not appear to be malicious, and ultimately the customer bears some responsibility for submitting their order without checking it.

Here's a gold mine that will pay out for years, perhaps decades. Let's nuke the mine and get an extra 1/5th on the first payout, sacrificing all future gains. Real smart there boys.

Someone downvoted me. Probably didn't get the analogy, so I'll spell it out. The gold mine = a subscriber. The nuking of said mine = fleecing the subscriber on his/her first payment and thus losing the subscription.

Well, "tricked"... sounds more like a silly bug to me. Stuff like this is easy to miss during testing, because you test these things in isolation.

It's very unlikely that this is a bug.

There is no reason that that a failed form validation would save the states of all the input fields EXCEPT the bundle selector.

Radio buttons are more prone to logical errors than normal fields, just due to the way they work. They're not rocket scientist hard, but they're totally "I didn't have enough coffee and screwed up the logic" hard.

Whenever anyone says "It's not x, it's the principle", it's x, it's always x.

Not really. I had a similar issues a while ago. Paid $5 for a test account (vps), customer rep lied to me about some issues then refused to refund. The $5 really wasn't worth my time, but I don't appreciate being lied to and having my time wasted, so I made sure make some public complaints on Twitter (after no response through their ticketing service).

So yes, it can be about the principle.

Chargeback time. That action on their part might be viewed as fraud.

Actually it would be fraudulent to not charge what was selected to be ordered. It was a bug that didn't save the selection properly (possibly just in Firefox too, the template didn't look that bad), but it was perfectly visible what was selected when the OP made the order.

IANAL, but this gets complicated. It all depends on whether a reasonable person, when seeing the error page with "no spaces in credit card field", would presume that nothing else in the form changed. If so, and the merchant is aware that most people presume that, then it could be fraud.

They are making a financial gain, by being aware that the terms have changed, and by misleading the customer into thinking that nothing has changed, they could be committing fraud.

The customer choose the original selection, and the merchant's systems swapped in a different, more expensive, version without telling the customer at the last moment, knowing that most people don't re-read everything again, then yes, that's fraud.

In addition, they claim that he purchased the 32.99 subscription. That step is unethical plain and simple. If you take 20 dollars from me and then claim I only paid 10, you bet it's going to look bad.

Reply on news.ycombinator.com