Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The anatomy of a credit card form

medium.com

Post reply on HN
Print view View original

51–60 of 129 posts

Re: The anatomy of a credit card form

#51

Post by kuschku »

pjc50 wrote: post #35
kuschku wrote: post #24

Earlier quoted context omitted.

Well, they actually do that – you could just pay per wire transfer (Überweisung) if you live in the SEPA, especially in DACH it’s more common. Bank-Authenticated direct-debit (like giropay.de) is also useful for this.

Interesting. I was going to say "there's no web UI for driving the SEPA system from a merchant's site", but is that what Giropay is? Bank authentication systems themselves aren't great here in the UK. I'd be much happier with a USB/Bluetooth gizmo that behaved like a chip+pin terminal+card combo: display the value on the device, confirm payment with a pin/password on the device, bypass the PC's possibly-compromised k…

That’s exactly what GiroPay is. The merchant can use it as simple as they can use PayPal, but GiroPay then redirects you to the online banking backend of your bank. Depending on bank, this can use 2-Factor authentication, SmartCards, etc. Most banks use Smart Cards and 2-Factor authentication.

Re: The anatomy of a credit card form

#52

Post by eli »

mrweasel wrote: post #49
dchest wrote: post #27

Earlier quoted context omitted.

From the article: "As an extra security measure, we have to ask customers for the ZIP code associated with their card. There is a trade-off here: adding extra inputs to the form can increase bounce rates, but by adding it, our business is more secure and less prone to fraud."

Is the zip sent to the card processing company? Do they check that the zip matches your address? What if the customer just moved? I've implemented card payments on multiple occasions, but not once have I seen a credit card processor that offered to validate the zip code. Unless the name and zip can actually be sent to the credit card processor, and they have access to that information based on the credit card number…

Yes. They are asking so that it can be sent to the credit card processing and used as part of a anti-fraud algorithm. Have you implemented credit card processing yourself or used something like Stripe? It's honestly a pretty common option. At least around me in the North Eastern US, pretty much every gas pump will refuse to sell you gas if you can't provide the billing zip for the credit card.

Re: The anatomy of a credit card form

#53

Post by yc1010 »

warbastard wrote: post #17
yc1010 wrote: post #12

Has anyone actually stepped back and looked at the larger picture, what a buyer wants to do is pay X (credit card is only one of them payment methods available and not really popular in some countries) they do not want to be entering long strings of numbers (whether its a credit card number, bank IBAN number, prepaid card #, or a bitcoin address) into forms they just want to pay

Yes, PayPal and other similar services were invented.

Problem with PayPal is that they ban people (I lost my account years back, still do not know why) and also of course not available in all countries.

I was thinking something along the lines of some sort of new HTML "payment" tag so it could signal to the browser things such as "product details, price, available/preferred merchant payment method"

and then the browser would pay from an in browser wallet containing stored credit card numbers, or bitcoins or prepaid/voucher codes, or bank account information

Some browsers could outsource this by starting a separate wallet program altogether, sort of how some links on mobiles open up other apps like maps

Someone above mentioned bitcoin links, that be a very good example of how to do UI payment flow nicely, especially nowadays that

Eitherway I think credit card forms are anything but user friendly, even the cleanest of forms such as Stripe would dumbfound new internet users such as my mother who rightly asked before "is it safe for me to be entering my cardcode on the internet"

Re: The anatomy of a credit card form

#54

Post by jimktrains2 »

mrweasel wrote: post #11
NolF wrote: post #5

> ZIP code: Length must be minimum 5 characters, maximum 10 characters There goes Australia and their 4 digit zip codes...

I don't get the name and zip code requirements, is that standard in some countries? I only ever encounter the "Name on card" when shopping on US and UK sites. Danish online stores don't care. Is the name and zip actually used as part of a validation process? If not it should just be left out.

http://jimkeener.com/posts/everyday-numbers-1

Zip codes are used for avs checks, along with house number, not the street.

Re: The anatomy of a credit card form

#55

Post by mseebach »

eli wrote: post #50
gingerlime wrote: post #21

Earlier quoted context omitted.

jquery.payment from stripe[0] helps with formatting and automatically adjusts it to the card type as you type in the numbers. It does seem to ignore spaces though, but it adds them for you as you type. If you type in a VISA number it will format it as XXXX XXXX XXXX XXXX, but if you type in AMEX, it will format it as XXXX XXXXXX XXXXX. Pretty neat if you ask me. You can try it here http://codepen.io/anon/pen/WvygyO V…

The automatic formatting seems more "cool" then actually useful. I'd much prefer that it show characters as I type them, like pretty much every other text input field.

As opposed to most other text input fields you encounter in the wild, credit cards (and phone numbers) have a singular canonical format. As long as you don't limit HOW it's entered (or pasted), it makes a lot of sense to coerce the input into the canonical format.

Re: The anatomy of a credit card form

#56

Post by jordigh »

pjc50 wrote: post #39
jordigh wrote: post #23

Ever since we've had cryptography, money on the internet has always seemed unnecessarily clunky to me. Everyone should have a password, then it's just a matter of encrypting who has how much money. While people make fun of how "fake" bitcoins are (as if any other money were not just a slightly more consensual mass hallucination), I really do like how they have demonstrated that internet money can be a lot more conven…

Bitcoin has shown how critical the fraud problem is. Between wallet loss and exit fraud by bitcoin companies, bitcoin users have lost vast amounts.

Do we have a comparison of how much is lost to fraud otherwise, without bitcoins?

Anecdotally, the only time I have ever been defrauded of money was when my debit card was skimmed. The fraudsters kept trying to withdraw money, which I didn't keep in that account as I immediately took it elsewhere. It was the account in which I received my paycheque. The fraudsters were able to steal one of my paycheques, and the bank was completely ineffective in protecting me. I got no warnings of unusual activity, and I got no money back. I should have gotten some sort of warning, since someone was repeatedly trying to withdraw money from unusual locations from my empty account. Even my account history showed nothing. Not until I asked the bank after the money was already gone did I learn that the fraudsters had been attempting every day to withdraw the money.

How many stories like mine are there compared to bitcoin stories?

Re: The anatomy of a credit card form

#57

Post by mrweasel »

eli wrote: post #52
mrweasel wrote: post #49

Earlier quoted context omitted.

Is the zip sent to the card processing company? Do they check that the zip matches your address? What if the customer just moved? I've implemented card payments on multiple occasions, but not once have I seen a credit card processor that offered to validate the zip code. Unless the name and zip can actually be sent to the credit card processor, and they have access to that information based on the credit card number…

Yes. They are asking so that it can be sent to the credit card processing and used as part of a anti-fraud algorithm. Have you implemented credit card processing yourself or used something like Stripe? It's honestly a pretty common option. At least around me in the North Eastern US, pretty much every gas pump will refuse to sell you gas if you can't provide the billing zip for the credit card.

We use multiple companies, all of which are "something like Stripe", to avoid dealing with PCI requirements. I've never seen any of them check zip or name, if you want added security you ask for 3D Secure/Verified by VISA. That will either require the customer to login via their online banking solution of enter the code sent to them via SMS.

On of our payment providers just told us today that by August 1st. 3D Secure will be required for all online transaction in the EU. It might be later, less than one month doesn't seem like a reasonable notice.

Honestly name and zip seems like something that's easily obtained by a scammer.

Re: The anatomy of a credit card form

#58

Post by jameshart »

tomp wrote: post #2

> “My card number has spaces. Do I enter my card number with spaces, or without?” To solve for this, we limit the input values to numbers only, so 0–9. So if a user types a space, it does not register and it does not affect the number format. They failed, at the most important part of the form. The correct, i.e. the most user friendly solution is, obviously, to allow spaces (and optionally other characters, like "-,.…

For postal codes, they're even doing the right thing for the wrong reason. They believe they're only going to encounter US or Canadian postal codes. Billing addresses can be anywhere, of course.

Re: The anatomy of a credit card form

#59

Post by haser_au »

TheOtherHobbes wrote: post #20

UK banks sometime sends payments to a separate verification page which either returns automatically or asks further security questions. I don't think this form is going to work with those banks. A couple of takeaways: 1. This has been a standard problem for twenty years now. Why are designers and developers still having to reinvent the wheel? 2. Reinventing the wheel is really hard. If you want to support internation…

It's in their interests to make it inefficient. Payment gateways are a large source of revenue for banks. An efficient, friction-free payment system would likely make these payment gateways redundant, and hence, remove a revenue stream for banks.

Re: The anatomy of a credit card form

#60

Post by keeperofdakeys »

sfilipov wrote: post #7
tomp wrote: post #2

> “My card number has spaces. Do I enter my card number with spaces, or without?” To solve for this, we limit the input values to numbers only, so 0–9. So if a user types a space, it does not register and it does not affect the number format. They failed, at the most important part of the form. The correct, i.e. the most user friendly solution is, obviously, to allow spaces (and optionally other characters, like "-,.…

I personally like it when the form inserts a space for me after every 4 digits and has a maximum length of the field set to (number of digits + spaces between). For some reason I rarely see websites that have such forms. Maybe it is actually confusing for the majority of users.

I know a banking site that inserts dashes. However, if you type too fast, then it inserts them into the wrong places :/
Post reply on HN