I won't pay on your website(github.com)
github.com
I won't pay on your website
https://github.com/juspay/hyperswitch/wiki/Why-I-won%27t-pay-on-your-website
154 comments
I have this problem all the time.
I live in Vietnam and my address looks something like
561/34/13 Điện Biên Phủ, Phương 25, Quận Tân Bình, TP. Hồ Chí Minh
The ways this usually fails with websites:
They tell me a slash isn't allowed, like they know my address better than me.
They tell me I need a post code. There are no post codes in Vietnam.
They tell me I need a state or province. Hồ Chí Minh City is a city without a province. (There are five such cities that have the same rank as a province and thus aren't contained within one.)
They have no concept of phương ("ward") and quận ("district"), without which the rest of my address is anything from ambiguous to useless. They often have a "second address line" where I can put this in but they often have limitations that make it impossible to enter. (Like not allowing commas, or only allowing 15 characters, or not allowing periods, and I don't even remember what all problems I run into the years with it.)
And all for what?
I live in Vietnam and my address looks something like
561/34/13 Điện Biên Phủ, Phương 25, Quận Tân Bình, TP. Hồ Chí Minh
The ways this usually fails with websites:
They tell me a slash isn't allowed, like they know my address better than me.
They tell me I need a post code. There are no post codes in Vietnam.
They tell me I need a state or province. Hồ Chí Minh City is a city without a province. (There are five such cities that have the same rank as a province and thus aren't contained within one.)
They have no concept of phương ("ward") and quận ("district"), without which the rest of my address is anything from ambiguous to useless. They often have a "second address line" where I can put this in but they often have limitations that make it impossible to enter. (Like not allowing commas, or only allowing 15 characters, or not allowing periods, and I don't even remember what all problems I run into the years with it.)
And all for what?
This reminds me of forms explicitly requesting filling-in your name "exactly as written in your passport", only to directly refuse any non-ascii characters (like any accents).
They probably mean the name as written in the Machine Readable Zone (MRZ) name field of the passport. Each issuing country chooses how to transliterate names to match the MRZ encoding as needed. The MRZ allows the characters 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ< and no others. The Visual Inspection Zone (VIZ) CAN contain characters outside this set, though SEVIS recommends including a transliteration into the MRZ character set as well.
They might have meant the spelling at the bottom, the part filled with <<<<<<<<<<< there I believe that only ASCII is used.
eg: https://en.wikipedia.org/wiki/Passport#/media/File:ROC_Natio...
eg: https://en.wikipedia.org/wiki/Passport#/media/File:ROC_Natio...
Some cheat codes I use when ordering parts from overseas, in case useful:
I set postal code to 700000 for HCMC (in theory, we have postal codes defined in VN. We just don't use them).
Usually I set province = Hồ Chí Minh City and then am able to select city = Hồ Chí Minh City as well (even though this is incorrect, as you say).
The lack of slashes is still often a show-stopper for me too, as is insufficient space in the address field. I live not that far from 1806/127/2/6/15/48/2P Huỳnh Tấn Phát, which I imagine delivery drivers just love.
Even with all the tricks, I've occasionally been unable to pay for services online, and had to find alternatives. Sometimes I'll also see Vietnam, Viet Nam and Việt Nam as separate options on a country selector. When importing something expensive from overseas, this does not exactly fill me with confidence.
I set postal code to 700000 for HCMC (in theory, we have postal codes defined in VN. We just don't use them).
Usually I set province = Hồ Chí Minh City and then am able to select city = Hồ Chí Minh City as well (even though this is incorrect, as you say).
The lack of slashes is still often a show-stopper for me too, as is insufficient space in the address field. I live not that far from 1806/127/2/6/15/48/2P Huỳnh Tấn Phát, which I imagine delivery drivers just love.
Even with all the tricks, I've occasionally been unable to pay for services online, and had to find alternatives. Sometimes I'll also see Vietnam, Viet Nam and Việt Nam as separate options on a country selector. When importing something expensive from overseas, this does not exactly fill me with confidence.
Yeah I use those tricks too. As you say they work 90% of the time. Sometimes I have to write "P 25 Q Tan Binh" or even "P25QTanBinh" if the second address line has stupid restrictions.
I also use 700000 for HCMC even though that isn't actually accurate for anything except the main post office in District 1. You can actually put in any number since no website does anything with it. Which you sometimes have to do when they tell you that "700000 is too long for a post code, must be 5 digits or less".
AFAIK the "accurate" post codes for Vietnam (that no one ever uses) are:
https://phaata.com/thi-truong-logistics/zip-code-hcm-ho-chi-...
I also use 700000 for HCMC even though that isn't actually accurate for anything except the main post office in District 1. You can actually put in any number since no website does anything with it. Which you sometimes have to do when they tell you that "700000 is too long for a post code, must be 5 digits or less".
AFAIK the "accurate" post codes for Vietnam (that no one ever uses) are:
https://phaata.com/thi-truong-logistics/zip-code-hcm-ho-chi-...
> They tell me I need a state or province. Hồ Chí Minh City is a city without a province. (There are five such cities that have the same rank as a province and thus aren't contained within one.)
Common in London, too -- even on British websites. They'll require a city and a county, at which point I need to enter "London" for both. Things will still be delivered correctly, fortunately.
Common in London, too -- even on British websites. They'll require a city and a county, at which point I need to enter "London" for both. Things will still be delivered correctly, fortunately.
This is because delivery is made by people who can understand things, including limitations of software. The moment these people are replaced by robots is the moment you stop recieving mail :/
Except if you need to send something to this address, why would you care what is input?
Even when using it for shipping, what I do is to repeat information. They want a "province"? I have no idea what this is (I am French) so I repeat the name of the city, or I put a region. When the letter/package Congress to France the address won't be correctly formatted anyway so they will do a best match - and it always worked without problems.
Sale for phone numbers. I usually try 0000000000 which often get rejected, and then 010101010101 which usually is accepted (sorry for the prob who uses this number in the Paris region).
Even when using it for shipping, what I do is to repeat information. They want a "province"? I have no idea what this is (I am French) so I repeat the name of the city, or I put a region. When the letter/package Congress to France the address won't be correctly formatted anyway so they will do a best match - and it always worked without problems.
Sale for phone numbers. I usually try 0000000000 which often get rejected, and then 010101010101 which usually is accepted (sorry for the prob who uses this number in the Paris region).
Your address is now going to be one of my favourite tests for ever more, hope that's okay?
Prepare for pushback in the form of "Who the hell will be using our site from Vietnam?"
Personally, I think a correct response is "Hey man, you wanted to sell things on the World Wide Web. If you want to exclude Vietnam, Main Street has storefronts for you to rent"
Personally, I think a correct response is "Hey man, you wanted to sell things on the World Wide Web. If you want to exclude Vietnam, Main Street has storefronts for you to rent"
Happened to me yesterday I’m from New Zealand, trying to buy something from a Chinese website There was obviously some localisation code for New Zealand, but 1st it incorrecly tries to validate phone number, then 2nd it asks for address and prefills the rest of it completely wrong (Canterbury is NOT a state, and it is not a mail destination , and the abbreviation CAN is not recognised by anyone as Canterbury.
I absolutely hate it when you try to give a company some money, and they just fail to close the sale!
I absolutely hate it when you try to give a company some money, and they just fail to close the sale!
Same problem here with ordering from AliExpress to Germany.
They try to make some localization and validation and fail greatly with that.
The province doesn't matter in German addresses at all. But when entering the ZIP code it always presented me the city as the main city in the province, which is not my city. My city is 20km away.
At the end I put everything again into the second address field, which allowed some free form input.
They try to make some localization and validation and fail greatly with that.
The province doesn't matter in German addresses at all. But when entering the ZIP code it always presented me the city as the main city in the province, which is not my city. My city is 20km away.
At the end I put everything again into the second address field, which allowed some free form input.
It's surprising how many developers complain about this, here in HN and otherwise, yet STILL we have those crappy validations and autofill all over the internet.
It's worse. Few months ago we wanted to buy some specific books/toys from a local brand (we're in Poland). It was a relatively modern, small company, with appropriately modern and slick website - you'd expect everything to go smoothly, right? Unfortunately, we weren't able to complete the purchase, because whoever made their checkout page had a bright idea to integrate with...
...wait for it...
... an AI-powered address validation system, offered by some random local startup. That validation system tried to provide autocomplete and attempted to automatically segment the address in a seemingly free-form field, but something in the integration got botched, and it wasn't able to identify house numbers - and without identifying one, it would not let the check-out process to continue.
I've actually tracked down the startup making this "address validator" (who in the right mind funded them, and why companies pay for this, is beyond me); they had a demo form on the landing page, and it correctly segmented my address - which is why I know it's the integration with the particular seller that got botched. Nevertheless, I'm still in shock - why on Earth would someone do this in the first place? It's strictly worse than having multiple fields - name, street, address part 2, zip code, city, etc. Multiple fields are already bad for reasons discussed in this thread, but a single free-form field that's parsed by "AI" into colored segments as you type? What in the fuck.
...wait for it...
... an AI-powered address validation system, offered by some random local startup. That validation system tried to provide autocomplete and attempted to automatically segment the address in a seemingly free-form field, but something in the integration got botched, and it wasn't able to identify house numbers - and without identifying one, it would not let the check-out process to continue.
I've actually tracked down the startup making this "address validator" (who in the right mind funded them, and why companies pay for this, is beyond me); they had a demo form on the landing page, and it correctly segmented my address - which is why I know it's the integration with the particular seller that got botched. Nevertheless, I'm still in shock - why on Earth would someone do this in the first place? It's strictly worse than having multiple fields - name, street, address part 2, zip code, city, etc. Multiple fields are already bad for reasons discussed in this thread, but a single free-form field that's parsed by "AI" into colored segments as you type? What in the fuck.
Address validation is one of the major textbook cases of developers going out of their way to make their software worse.
And from the company owner's point of view: Imagine spending extra money on development that stops users from completing a purchase.
These cases are the perfect answer to "Why do we need senior developers on our team who have good judgment?" This is why--to prevent software like this from even being written in the first place.
And from the company owner's point of view: Imagine spending extra money on development that stops users from completing a purchase.
These cases are the perfect answer to "Why do we need senior developers on our team who have good judgment?" This is why--to prevent software like this from even being written in the first place.
Yeah, hard agree on this. Companies need to actually need to make an effort to know their audience & how things works there before even launching there. But nowadays research is secondary to most of them.
There are post codes in Vietnam, believe it or not. Though I doubt any local delivery service actually look at it.
Hanoi post code is in the 100000 range (used to be 10000), Saigon's 700000
Hanoi post code is in the 100000 range (used to be 10000), Saigon's 700000
Yeah I know that "technically" we have post codes, though I've never met anyone who knows that or knows what their post code is. And I've never received any mail that uses it (not even from the government).
Your story reminded me how Chinese students could not enroll in a well known Dutch university online, because their last name was less than4 characters long.
Also wanted to know from your exp, what are some good apps that actually considers localisation even being an international company?
Off the top of my head I can't think of any that are GOOD.
But a decent number of them appear to switch off most/all validation once you select a non-US address, which I think is a perfectly acceptable thing to do. (That's if they even support a non-US address, that is.) I've never seen any data but I wonder how much help validating addresses even is.
The "must have a postal code" is by far the biggest problem. I can't recall a website that actually can cope with not having a postal code.
In practice you can put in any number and the local postal delivery here will ignore it/figure it out since it won't be the first time a foreigner has put the wrong address on something in Vietnam.
But a decent number of them appear to switch off most/all validation once you select a non-US address, which I think is a perfectly acceptable thing to do. (That's if they even support a non-US address, that is.) I've never seen any data but I wonder how much help validating addresses even is.
The "must have a postal code" is by far the biggest problem. I can't recall a website that actually can cope with not having a postal code.
In practice you can put in any number and the local postal delivery here will ignore it/figure it out since it won't be the first time a foreigner has put the wrong address on something in Vietnam.
I've seen some sites use Google maps API to suggest your exact address, pretty cool
Oh good grief those are annoying though. "We've found a more exact version of the address you entered" no you haven't, you've randomly substituted my neighbour's house number and dropped the county name. It's even worse for my office address: it's a large building shared by many companies; without the correct company name the receptionist cannot contact the right recipient. The APIs though like to either replace the company name with a random unrelated one or drop it entirely.
Wonder how many misdeliveries these features cause? Both my and GP's annoyances can be solved simply by leaving the entered data unmangled. I've supplied precisely what needs to go on the packaging to get the item to me. All of the text is necessary, sufficient and in the correct order. Don't change those things. You don't know better.
Wonder how many misdeliveries these features cause? Both my and GP's annoyances can be solved simply by leaving the entered data unmangled. I've supplied precisely what needs to go on the packaging to get the item to me. All of the text is necessary, sufficient and in the correct order. Don't change those things. You don't know better.
When moving in, some two years ago, to an apartment located close to the very centre of Kraków - one of the biggest and well-known cities in Poland - I discovered that Google somehow got the postal code wrong for the entire street. The code they had on record actually pointed some 20-30 kilometers outside of Kraków. It took more than a year of sending corrections to Google Maps before they finally fixed the postal code... of my building alone. The rest of the street still has the wrong code.
Want to know why I bothered to try and get it fixed all this time? Because this little mistake made it nearly impossible to order food via any of the food order services. Uber Eats, Glovo, Pyszne.pl, etc., in their infinite tech startup wisdom, all integrated with Google API to fetch postal codes based on address, and use them to filter out restaurants that can deliver to the user's location. With my address mistakenly mapping to a village 20+ kilometers outside of Kraków, do you care to guess how many options I had to order from?
That, plus it also messed up ordering taxis via FreeNow and Bolt, which also integrate with Google API for stupid reasons. This also means the drivers need to use separate apps to navigate around the center, because Google doesn't have data on which roads are banned for traffic except buses and taxis, and the parent companies are too cheap to license from a provider that has this data. All while in the apps themselves, if your route starts, ends, or even crosses anywhere near the city center, the estimated time data shoots up to some ridiculous values, while the map gets entirely confused, as Google Maps integration is adamant that the route we're on is physically impossible.
Want to know why I bothered to try and get it fixed all this time? Because this little mistake made it nearly impossible to order food via any of the food order services. Uber Eats, Glovo, Pyszne.pl, etc., in their infinite tech startup wisdom, all integrated with Google API to fetch postal codes based on address, and use them to filter out restaurants that can deliver to the user's location. With my address mistakenly mapping to a village 20+ kilometers outside of Kraków, do you care to guess how many options I had to order from?
That, plus it also messed up ordering taxis via FreeNow and Bolt, which also integrate with Google API for stupid reasons. This also means the drivers need to use separate apps to navigate around the center, because Google doesn't have data on which roads are banned for traffic except buses and taxis, and the parent companies are too cheap to license from a provider that has this data. All while in the apps themselves, if your route starts, ends, or even crosses anywhere near the city center, the estimated time data shoots up to some ridiculous values, while the map gets entirely confused, as Google Maps integration is adamant that the route we're on is physically impossible.
Shopify does this to my address. I live at 106 and Shopify sites like to decide that I live at 106 bis, the next building over. That building only has a shared mailbox between three families, so packages that end up there are lost forever with no accountability.
Sadly true in every country.
Recently been to China, and now that everything requires WeChat, it's extremely convenient if you're local, but as a tourist things are very difficult when you don't have:
- a Chinese phone number;
- a WeChat account with payment activated;
- a Chinese ID card.
Wanna read the menu? Only if you have wechat and an internet connection to scan that QR code (many places have no physical menus).
Wanna pay with cash you've just exchanged at the airport? Sorry, nobody uses cash anymore (many shops won't accept cash at all).
Wanna book a train ticket online before you reach China to plan your trip? Sorry, you've got to be Chinese for that and have a local number.
Wanna pay with your credit card something in a big mall? They might accept it, but their IT system might not always manage to communicate with your bank and it may fail for no reason.
Albeit, the opposite problem is true in Germany: many places only accept cash, or only accept EC cards, aka special credit cards issued by German banks only.
Recently been to China, and now that everything requires WeChat, it's extremely convenient if you're local, but as a tourist things are very difficult when you don't have:
- a Chinese phone number;
- a WeChat account with payment activated;
- a Chinese ID card.
Wanna read the menu? Only if you have wechat and an internet connection to scan that QR code (many places have no physical menus).
Wanna pay with cash you've just exchanged at the airport? Sorry, nobody uses cash anymore (many shops won't accept cash at all).
Wanna book a train ticket online before you reach China to plan your trip? Sorry, you've got to be Chinese for that and have a local number.
Wanna pay with your credit card something in a big mall? They might accept it, but their IT system might not always manage to communicate with your bank and it may fail for no reason.
Albeit, the opposite problem is true in Germany: many places only accept cash, or only accept EC cards, aka special credit cards issued by German banks only.
> many places have no physical menus
I hate this trend so much
I hate this trend so much
My simplest solution - changing restaurants. I absolutely don't trust the security of mobile devices, won't be scanning unknown QR codes, opening websites with unknown 3rd party spying garbage nor installing spyware-infused apps in order to get a glass of wine.
I can understand why it's happening, at least:
* Don't need to purchase paper.
* Don't need to purchase or contract a printer.
* Can change the menu willy nilly.
* It's in line with the current environmentalism fad.
But that said: If the restaurant can't be arsed to provide me with requisite-free information on what god damn food they serve, I can't be arsed to provide my god damn money for their time.
* Don't need to purchase paper.
* Don't need to purchase or contract a printer.
* Can change the menu willy nilly.
* It's in line with the current environmentalism fad.
But that said: If the restaurant can't be arsed to provide me with requisite-free information on what god damn food they serve, I can't be arsed to provide my god damn money for their time.
Different eating culture. In China it's not uncommon to eat out every day whereas in the west it's usually an experience (unless you are eating out in McDonald's). Hence, cheap eats places tend to automate to save on costs.
Yeah, this is the main reason I haven't been to China in a while. It's quite nearby for me, but just too difficult. In principle, I would love to go to Chengdu or Shenzhen, but end up going to Singapore instead because I don't have the time to deal with the logistics.
On the other hand, I do glean some amusement that the region where cash was invented, no longer accepts cash.
On the other hand, I do glean some amusement that the region where cash was invented, no longer accepts cash.
Related: requiring one specify a US state. I hit this yesterday, with a modern AI SAAS!
Once I hit this with zip code validation. Knowing that the credit card processor doesn't actually check this, I found a particular state (Arkansas) that happened to include my Polish postal code. This worked and I paid my bill.
Once I hit this with zip code validation. Knowing that the credit card processor doesn't actually check this, I found a particular state (Arkansas) that happened to include my Polish postal code. This worked and I paid my bill.
A hotel in Sweden used an external booking system for breakfast slots (remnants of CoVID, I guess). To receive breakfast, I had to provide name, email address and a phone number. And read a ~15 phone-screens ToS.
Strangely, no one pointed out the obviously fake email address or phone number when I had the breakfast. Perhaps it wasn't needed after all.
Strangely, no one pointed out the obviously fake email address or phone number when I had the breakfast. Perhaps it wasn't needed after all.
Oh that crap is super common on restaurant wifi too around here.
The funny thing is that they can't actually validate the email address so most just accept whatever (sometimes with a small extra filter to avoid stuff like [email protected]).
The funny thing is that they can't actually validate the email address so most just accept whatever (sometimes with a small extra filter to avoid stuff like [email protected]).
I always use example.com, since it's reserved for examples, and guaranteed that no one is bothered by it. :)
In 8th grade, long ago, my buddy created a hotmail account: deepthroat50005.
he thought it was based on Metal Gear Solid's reference to the Watergate thing. Didn't get the other connotations -- at least not at first. He disowned it, and we laughed about it for a while.
I still use that email for anything that requires an email but I DGAF about. Hasn't been rejected yet...
he thought it was based on Metal Gear Solid's reference to the Watergate thing. Didn't get the other connotations -- at least not at first. He disowned it, and we laughed about it for a while.
I still use that email for anything that requires an email but I DGAF about. Hasn't been rejected yet...
[deleted]
Ah, the ToS. I sometimes download a game in my Xbox Series X and the TOS is crazy long. What the fck for?
> This prevents me from renting a Bixi bicycle in Montreal.
While I suspect this is a screwup on the part of Bixi, you're making the mistake of confusing bikeshare with bike rental. Don't worry though, you're in good company, including many companies that operate bikeshare.
Bikeshare is meant to be a transportation service to get people from point A to point B. More often than not tourists don't use it that way and even when they do, they would be better served using bikes that are not part of the bikeshare system so they're able to go slower than a commuter would and enjoy the sights on the way, as well as stop randomly to checkout something that might look interesting.
Tourists are almost always better off renting a bike for a day or even a few hours than using the bikeshare system.
Many bikeshare systems would in fact be better served restricting access only to long term members.
While I suspect this is a screwup on the part of Bixi, you're making the mistake of confusing bikeshare with bike rental. Don't worry though, you're in good company, including many companies that operate bikeshare.
Bikeshare is meant to be a transportation service to get people from point A to point B. More often than not tourists don't use it that way and even when they do, they would be better served using bikes that are not part of the bikeshare system so they're able to go slower than a commuter would and enjoy the sights on the way, as well as stop randomly to checkout something that might look interesting.
Tourists are almost always better off renting a bike for a day or even a few hours than using the bikeshare system.
Many bikeshare systems would in fact be better served restricting access only to long term members.
I disagree. As a tourist I would usually prefer to use bike share, similarly to the systems I'm used to at home.
Getting and returning bikes at dedicated rental shops is quite a hassel, typically much more expensive, and unnecessary if I just want a simple city bike.
In fact I suspect that it's often intentional that tourists have a hard times registering for bike share systems. They would greatly impact the business of preexisting bike rental shops.
Getting and returning bikes at dedicated rental shops is quite a hassel, typically much more expensive, and unnecessary if I just want a simple city bike.
In fact I suspect that it's often intentional that tourists have a hard times registering for bike share systems. They would greatly impact the business of preexisting bike rental shops.
While I myself am a long-term user of my local bikeshare network and more often than not see tourists renting private bikes by the day, I have to disagree with the idea of restricting access for short-term users.
It's always been super handy for when friends come to visit and we can all take the same method of transportation, and it means they can afford to park further out of town where the free car spaces are and cycle into the city centre.
It's always been super handy for when friends come to visit and we can all take the same method of transportation, and it means they can afford to park further out of town where the free car spaces are and cycle into the city centre.
Tourists also like to go from point A to point B. I use citibike in NYC when I'm a tourist for this use case.
Bike rental places were driven out of business by Bixi.
It’s worse in a lot of other places around the world. A lot of vendors in Asia won’t accept credit card payments from foreign BIN numbers. Want to buy a train or plane ticket from the local service provider? Too bad. Want to top up a SIM card? Definitely not. A lot of those places also have local payment wallets (like TNG, GoPay, GrabPay…) that are incredibly ubiquitous, and entirely inaccessible without a local bank account. In most of those places it’s the local governments fault rather than the vendors fault specifically, but still incredibly frustrating.
Dutch banks all got together some 15 years ago to devise the perfect online payment system: iDeal. Pretty much everyone uses it. Checkmate PayPal and Visa card.
But the best secondary effect was that it locks out foreign banks who can't be arsed to set up a local branch and apply for a banking license.
But the best secondary effect was that it locks out foreign banks who can't be arsed to set up a local branch and apply for a banking license.
Except that it has absolutely no protection after you've paid. You have no recourse with iDeal. The money has been sent.
How often do you read on Dutch forums [1] whether they paid with iDeal? Because if you do, your only recourse is to either sue them (which the Dutch rarely do) or open a dispute with the Thuiswinkel Waarborg [2].
For as long as I bought stuff online in The Netherlands I used a credit card. If they didn't offer it I'd find someone else.
[1] https://tweakers.net (tweaking as in tinkering, not the other kind)
[2] https://nl.wikipedia.org/wiki/Thuiswinkel_Waarborg
How often do you read on Dutch forums [1] whether they paid with iDeal? Because if you do, your only recourse is to either sue them (which the Dutch rarely do) or open a dispute with the Thuiswinkel Waarborg [2].
For as long as I bought stuff online in The Netherlands I used a credit card. If they didn't offer it I'd find someone else.
[1] https://tweakers.net (tweaking as in tinkering, not the other kind)
[2] https://nl.wikipedia.org/wiki/Thuiswinkel_Waarborg
Yeah, the same thing happened when I move to Germany, but the other way around.
Some app, don't recall which, would not accept my Argentinean phone number.
I now want to try Cargaroo or something like that, but I am not willing to give them my CC information and they don't have paypal.
Some app, don't recall which, would not accept my Argentinean phone number.
I now want to try Cargaroo or something like that, but I am not willing to give them my CC information and they don't have paypal.
I was frustrated recently trying to book an expensive flight. My card was denied, and I retried several times — had I mistyped something? Should I have written "oe" not "ø" in "København"? Did it need me to make up a "state/province"?
Eventually I gave up with that site, and tried the same booking on a different website. It immediately said "Your bank has declined the transaction. Either you have insufficient funds in your account, or the transaction is above the bank's limit for this card." Annoying, but checking on the bank's website revealed there was an unspecified limit. The first site would have got the sale (with a different card) if they'd given me a clear error message.
Eventually I gave up with that site, and tried the same booking on a different website. It immediately said "Your bank has declined the transaction. Either you have insufficient funds in your account, or the transaction is above the bank's limit for this card." Annoying, but checking on the bank's website revealed there was an unspecified limit. The first site would have got the sale (with a different card) if they'd given me a clear error message.
The generic error message is, sometimes, a strategy to hinder attacks, at the very cost of the user experience.
I think there is a strong relationship between the average ticket size and payment experience. It is almost like it is the user's problem if the ticket size is high (hence the website need not necessarily invest in creating a good payment experience). Something like insurance websites.
The ones that really seem to think about the payment experience are the ones that have low to medium average ticket size and high transaction volumes. It is in the website's best interest to ensure each and every transaction goes through
The ones that really seem to think about the payment experience are the ones that have low to medium average ticket size and high transaction volumes. It is in the website's best interest to ensure each and every transaction goes through
It may be the limit imposed by VISA/MasterCard to comply with fraud regulations. You can have the limit lifted if you call your bank, but you will be on the hook for any fraud that may occur in the next 30 days until the limit resets again. Good news though, they have changed the rolling window to 7 days now.
The comment wasn't about the card being declined, it was about how the website just said "failed" instead of saying "you're broke". Gp says if the website had informed him the card was the problem, the first website would have gotten the sale instead of the more verbose second one.
As much was clear. My comment was a possible explanation of what might have been the root cause. It was a interesting potentially relevant piece of information.
This is typically an issue with the payment gateway and/or processor rather than the site or the platform underneath it. You probably had a better error message in the second experience because the site uses a different payment gateway/processor. That's not to say the first site's experience is great, but payment processor selection has lots of competing considerations... processing fees, ability to support enterprise-grade MSA/SLA requirements, security, audit trail, etc etc. (Others are also correct in observing that more vague error messages are actually a strategy by some processors to avoid tipping off fraudsters.)
I'm guessing you have never worked in e-commerce and thus you think that the various problems, especially where credit card transactions occur, could be easily solved if the people implementing the site weren't just so darn stupid?
I also figure you haven't worked in the field because otherwise you'd know the site isn't necessarily in charge of what error codes the card handler is giving.
Although of course the site will be in charge of turning the not necessarily perfectly documented codes and which may vary based on a great number of different factors into error messages.
Which may well be the case, or it may be that whatever third party handler they are using to take care of transactions does a bad job in returning this kind of error message.
Or it may be that there is heightened security about the site right when you are using it and it turns out that in some opaque process the site has no control over the credit card handler is now returning less informative messages for that site and it is the same handler on the site where it does give a good error back.
etc. etc.
I also figure you haven't worked in the field because otherwise you'd know the site isn't necessarily in charge of what error codes the card handler is giving.
Although of course the site will be in charge of turning the not necessarily perfectly documented codes and which may vary based on a great number of different factors into error messages.
Which may well be the case, or it may be that whatever third party handler they are using to take care of transactions does a bad job in returning this kind of error message.
Or it may be that there is heightened security about the site right when you are using it and it turns out that in some opaque process the site has no control over the credit card handler is now returning less informative messages for that site and it is the same handler on the site where it does give a good error back.
etc. etc.
Well, if the other site was able to provide an actionable error message, it must be possible. It might not be in the website’s direct control, but they are in control of which payment processor to use.
that assumes that there is a clear ranking of payment processors and that the processor that is crap at one moment in time is crap at all moments in time and the processor that is good at one moment in time is good at all moments in time and that the momentary superiority of one payment processor is an absolute superiority that makes them the obvious choice and anyone not making that choice is bad.
Which is, admittedly, a very HN assumption to make on basically any subject that comes up.
Which is, admittedly, a very HN assumption to make on basically any subject that comes up.
> Which is, admittedly, a very HN assumption to make
No, it's your assumption that is wrong! You gave an explanation of several possible reasons, and you assume that people care. Actually, they don't!
The first site worked crappy and the second worked nice: the first site missed the money and the second one got it!
No, it's your assumption that is wrong! You gave an explanation of several possible reasons, and you assume that people care. Actually, they don't!
The first site worked crappy and the second worked nice: the first site missed the money and the second one got it!
No, my assumption was that the original poster hadn't ever worked e-commerce or they wouldn't have complained in a way that they thought it was inevitably due to factors within the sites' control that one worked nice and one worked crappy on this particular factor.
To an end customer, it doesn't matter if a problem is under the merchant's direct control or if it's happening upstream. He is the merchant's customer, the UX he sees is how the merchant is choosing to represent itself to their customers, and therefore the merchant, and only the merchant is accountable if that experience is crappy.
Whether OP actually worked in e-commerce is kind of irrelevant. I've never worked in e-commerce either, and if CompanyX fails to process my payment and I can't buy something from them, I'm going to rightfully blame CompanyX for that, not one of their service vendors.
Whether OP actually worked in e-commerce is kind of irrelevant. I've never worked in e-commerce either, and if CompanyX fails to process my payment and I can't buy something from them, I'm going to rightfully blame CompanyX for that, not one of their service vendors.
I think maybe you are overreacting. No one is saying they’re bad or stupid. It is understandably difficult to get right when they probably have very limited insight into why some people might abandon a payment.
But in the end, the effect is that they lost a sale to a competitor who got it right this time.
But in the end, the effect is that they lost a sale to a competitor who got it right this time.
It's all to stop bad actors.
Yeah that's basically it. Risk vs. reward, and there is probably a way to make it work, but what's the payoff?
That said, a bikeshare should be able to help tourists / be low-effort. Otherwise I'll just uber.
That said, a bikeshare should be able to help tourists / be low-effort. Otherwise I'll just uber.
The most surefire way of making me not buy something from your site is if you ask for any unnecessary details before telling me the whole price. If I have to create an account or enter an email address, or fill in any field other than my country and "state" before you tell me postage/shipping costs, I will just close the page down.
If I see anything that even feels like a dark pattern, I will just refuse out of principle.
If I see anything that even feels like a dark pattern, I will just refuse out of principle.
> But here’s how you can mess it up:
> • Not having dynamic error validations before someone goes ahead with the payment. It is as simple as using the Luhn algorithm to make some basic checks.
On the other hand, someone that does validation of their own is far more likely to accidentally filter out valid values. This used to be rather common on email addresses. (I’ve been using almost exclusively @chrismorgan.info addresses since about 2010, and had one rejected exactly once, from a regular expression that thought TLDs were only two or three characters long; I was able to use my skills to bypass the check, and the backend accepted it.) Nowadays, people normally just leave client side validation to whatever <input type="email"> does.
So, payment card numbers. I’ve only ever had a 16-digit one, but they can actually be 10–19 characters long, and some people are sure to have hard-coded maxlength=16 and/or minlength=16 (or equivalent JavaScript checks).
There are also those ridiculous things that insist on splitting the card number into multiple fields (four groups of four characters), but that’s generally just painful to work with rather than actually preventing you from using it.
> • Not having dynamic error validations before someone goes ahead with the payment. It is as simple as using the Luhn algorithm to make some basic checks.
On the other hand, someone that does validation of their own is far more likely to accidentally filter out valid values. This used to be rather common on email addresses. (I’ve been using almost exclusively @chrismorgan.info addresses since about 2010, and had one rejected exactly once, from a regular expression that thought TLDs were only two or three characters long; I was able to use my skills to bypass the check, and the backend accepted it.) Nowadays, people normally just leave client side validation to whatever <input type="email"> does.
So, payment card numbers. I’ve only ever had a 16-digit one, but they can actually be 10–19 characters long, and some people are sure to have hard-coded maxlength=16 and/or minlength=16 (or equivalent JavaScript checks).
There are also those ridiculous things that insist on splitting the card number into multiple fields (four groups of four characters), but that’s generally just painful to work with rather than actually preventing you from using it.
> Nowadays, people normally just leave client side validation to whatever <input type="email"> does.
Hah, I wish. SO MANY sites disallow the plus symbol in the email name (e.g. [email protected]).
This is a valid email. It should be accepted. Arrrgh.
Hah, I wish. SO MANY sites disallow the plus symbol in the email name (e.g. [email protected]).
This is a valid email. It should be accepted. Arrrgh.
Because Gmail treats + as an alias, they disable using + specifically so you don't use an alias, either creating multiple accounts or making them collect an easily blockable email ad target.
If you own a Google domain (not for long unfortunetaly, but I hear cloud flare has the same service) you can define *@domain for free and any email sent to the domain ends in the inbox of your choosing. Unlimited adresses.
If you own a Google domain (not for long unfortunetaly, but I hear cloud flare has the same service) you can define *@domain for free and any email sent to the domain ends in the inbox of your choosing. Unlimited adresses.
Catch-all is a pretty standard feature across email providers when you’re using your own domain.
As for +, I have no idea if it’s being blocked on purpose or by accident, but that kind of thing serves a useful purpose for the recipient, not just being able to create multiple accounts easily: automatic labelling. (And if you’re trying to create multiple accounts, plus addressing is an awfully prosaic approach, and there are plenty of other viable techniques, e.g. mail forwarding services, disposable addresses, adding random dots if you’re using Gmail—abc@, a.bc@, a.b.c@ and ab.c@ all go to the same mailbox.)
As for +, I have no idea if it’s being blocked on purpose or by accident, but that kind of thing serves a useful purpose for the recipient, not just being able to create multiple accounts easily: automatic labelling. (And if you’re trying to create multiple accounts, plus addressing is an awfully prosaic approach, and there are plenty of other viable techniques, e.g. mail forwarding services, disposable addresses, adding random dots if you’re using Gmail—abc@, a.bc@, a.b.c@ and ab.c@ all go to the same mailbox.)
I was surprised to learn the extent of what is a valid local-part (something+else in your example) of an email. Can have two dots in sequence if the local-part is quoted, and support for non alphanumeric characters like !#$%&'*+-/=?^_`{|}~; if the local-part is quoted, comments with parentheses. And it could be case sensitive.
We have the following validation:
let form_email: Option::<String> = /* ... */;
match form_email {
Some(email) if !email.is_empty() => {
// ... send email with validation link
},
_ => {
// report missing email
}
}
> (bonus points for the dropdown on expiry date)
I hate dropdowns for the expiry date. Let me just enter 01 TAB 22, I don't want to click on dropdowns then scrolldown.
I hate dropdowns for the expiry date. Let me just enter 01 TAB 22, I don't want to click on dropdowns then scrolldown.
I mean, there's no reason you can't have it both ways? So long as the dropdowns are not some broken custom widget, you can use dropdowns the same way.
Unless the form has been horribly butchered, that should still work, since the browser will select from the dropdown as you type, so long as the dropdown is focused.
1. It's not intuitive that you can type in a dropdown.
2. It's not always obvious if a dropdown is focused or not.
It's orthogonal, but focus doesn't always cycle in the obvious order of input fields with nothing in between.
As for the field, couldn't it be a text field with a small down arrow within for a dropdown option?
2. It's not always obvious if a dropdown is focused or not.
It's orthogonal, but focus doesn't always cycle in the obvious order of input fields with nothing in between.
As for the field, couldn't it be a text field with a small down arrow within for a dropdown option?
Every native dropdown in your OS supports typing to select an option. While it might be arguable if it's intuitive, it definitely is a common pattern.
For me, ideally, you don't need to TAB, because the input focus switches automatically.
If you implement this, please make sure any auto-refocus has visual clues, e.g. looking like a single input field, and behaving like a single field (a TAB moves to the next logical form field).
When inputting license keys in programs, and there were dashes in them, it was always fun encountering an auto-focus across split textfields where you didn't expect it, so you accidentally skipped a field and had to redo it.
When inputting license keys in programs, and there were dashes in them, it was always fun encountering an auto-focus across split textfields where you didn't expect it, so you accidentally skipped a field and had to redo it.
I hate the behavior you describe because my muscle memory means I always hit tab.
So now the month is 2023.
More friction.
So now the month is 2023.
More friction.
But still dropdown help users to remember the date layout (MM/YY) and also it is useful in cases where it is not intuitive that you can type.
Also, expiry date is always somewhere around 5 to 10 years so not a lot of scroll.
You have to take your hand to mouse, do 4 clicks, then go back to keyboard. Not the end of the world, but it's annoying and is bad for people with. e. g. RSI.
And to remind users about date layout, you can just put MM/YYYY or MM/YY as a placeholder. Of course, if you care about your users and want to go above and beyond, you can even support both MM/YY and MM/YYYY – it's not that hard!
And to remind users about date layout, you can just put MM/YYYY or MM/YY as a placeholder. Of course, if you care about your users and want to go above and beyond, you can even support both MM/YY and MM/YYYY – it's not that hard!
Is PayPal still a thing in the US? Only one mention in the article, none here in the comments.
I'm in Germany and order at a lot of specific sites, and while I don't like PayPal as a company or their fee structure, it's usually what keeps me sane. Most cases I don't have to enter anything, no need to create an account or even enter the delivery address. Doesn't get much more convenient than that.
I'm in Germany and order at a lot of specific sites, and while I don't like PayPal as a company or their fee structure, it's usually what keeps me sane. Most cases I don't have to enter anything, no need to create an account or even enter the delivery address. Doesn't get much more convenient than that.
Are the competitors that bad in Germany? Here in Sweden PayPal has one of the worst UIs and the buggiest sites.
This is actually true, but I still use PayPal probably 10-20 times a year and I haven't logged into their site for probably 2-3 years, at least whenever I last had to update my payment cards.
The site is suboptimal, it's probably not a great company and I have no idea if they're charging me anything - but the one-tap purchase system just works, and that's all I need. There are other great options in Klarna and similar, but even they give me too many options to coax me into paying later so I inadvertently pay fees. PayPal literally just withdraws from whichever card has sufficient funds at the time, has worked exactly as stated for over a decade, so I really have no incentive to investigate alternatives (especially for sites where my PayPal is already setup, like Steam).
The site is suboptimal, it's probably not a great company and I have no idea if they're charging me anything - but the one-tap purchase system just works, and that's all I need. There are other great options in Klarna and similar, but even they give me too many options to coax me into paying later so I inadvertently pay fees. PayPal literally just withdraws from whichever card has sufficient funds at the time, has worked exactly as stated for over a decade, so I really have no incentive to investigate alternatives (especially for sites where my PayPal is already setup, like Steam).
alternatives are standard wire-transfer, which will take a few days (wtf?) and some privately run proxy-service for wire-transfers (sofortueberweisung.de) where you login with the banking credentials on a non-bank website (yes, really) which manages to give the seller a confirmation of the transaction.
no alternative thou that manages adresses, confirmation and the actual transaction with one login/button
no alternative thou that manages adresses, confirmation and the actual transaction with one login/button
Germany, Italy, and Israel love Paypal.
Countries with low consumer trust.
Countries with low consumer trust.
Paypal has been very annoying with their login stuff since PSD2, more so than real banks. Amazon Pay is the easiest there, though SEPA payments are kinda the easiest for the consumer. However, SEPA transactions negatively impact credit score (if the merchant asks for the score, not all do). Credit cards are just a hassle online (except thru Apple Pay) and 3dsecure always feels like phishing.
Why does Germany have low consumer trust? Like, Italy I can see. And Israel has low-scale firefights happening on an irregular but non-trivial basis.
Has anyone done a scatter plot of PayPal and crypto adoption, on one axis, and estimated cash use, on the other?
I find it's a gamble for me. If paypal redirects and opens in the same browser it's happy days.
If it opens in a new window, it always seems to error out
If it opens in a new window, it always seems to error out
The whole concept of how we pay online is insane.
You put data into a form of a random website you want to pay a small amount to. Data which enables everybody who has it to cause trouble. Trouble to you, trouble to your credit card company, trouble to other websites who get scammed with it.
Websites should simply give you a string like "visa:3498734219:$12.34" where "visa" is their payment processor, 349... is the invoice nr and $12.34 is the amount invoiced. Then you copy+paste that into the website of your payment solution and let it do the transaction.
And if you don't like copy+paste, you install some app so you can just point your phone at such an invoice and click pay. Or a browser plugin which detects those invoices and asks you "Pay this?".
You put data into a form of a random website you want to pay a small amount to. Data which enables everybody who has it to cause trouble. Trouble to you, trouble to your credit card company, trouble to other websites who get scammed with it.
Websites should simply give you a string like "visa:3498734219:$12.34" where "visa" is their payment processor, 349... is the invoice nr and $12.34 is the amount invoiced. Then you copy+paste that into the website of your payment solution and let it do the transaction.
And if you don't like copy+paste, you install some app so you can just point your phone at such an invoice and click pay. Or a browser plugin which detects those invoices and asks you "Pay this?".
That's basically paying via QR code, and not an entirely new concept. Crypto works this way, and I believe WeChat or similar payment systems, too. Good idea for one-time payments, but honestly, those are no longer the norm. If you're not paying for something physical to be shipped to your home, chances are it's a subscription anyways in which case a payment flow like this would be a nightmare to both the user and the merchant alike.
The same flow would work for subscriptions.
The amount would just be a string like "whatever+whenever".
So you tell your payment provider that you authorize this merchant to pull whatever amount of money whenever they feel like.
And not give out a piece of data that authorizes anybody to pull whatever amount of money whenever they feel like.
The amount would just be a string like "whatever+whenever".
So you tell your payment provider that you authorize this merchant to pull whatever amount of money whenever they feel like.
And not give out a piece of data that authorizes anybody to pull whatever amount of money whenever they feel like.
So, PayPal, with the exception of „whatever“, as subscriptions may increase in price or you decide to upgrade without wanting to adjust your payment method. Plus, you have excellent protection as a buyer on PayPal with the option to request refunds for basically every reason.
We still have a misunderstanding.
The difference I propose is not about the modalities of the payments. Not about the merchant being able to change the price or you being able to request refunds.
It's about how the relationship between you, your payment provider and the merchant you want to buy from is initiated.
Currently you hand over some secret data to the merchant. Who then communicates with your payment provider.
Instead you should communicate directly with your payment provider. Never giving secret data to anybody.
The difference I propose is not about the modalities of the payments. Not about the merchant being able to change the price or you being able to request refunds.
It's about how the relationship between you, your payment provider and the merchant you want to buy from is initiated.
Currently you hand over some secret data to the merchant. Who then communicates with your payment provider.
Instead you should communicate directly with your payment provider. Never giving secret data to anybody.
So, PayPal. You sign in on PayPal.com, and PayPal communicates with the merchant. That’s how it works today. You never give any secret data to the merchant. You only allow the merchant to ask PayPal for your money.
That’s exactly how your proposed solution would have to work as well, if you want to support recurring payments or price adjustments. As soon as you allow the merchant to adjust pricing and/or interval, it opens the possibility for fraud. Because there is some way that the merchant needs to have to adjust these parameters. And if the merchant can do it, so can an attacker that takes over the merchants accounts. Like it would be the case with PayPal today.
(And by the way, that’s also how most of the credit card payments work today. Stripe for example does not allow the merchant to collect credit card information of the customer. Instead, the merchant embeds a Stripe web page into the checkout process which collects the credit card information. All the merchant gets is a token that allows them to collect money from the customer to their Stripe account. If an attacker were to obtain this token, all they could do would be to collect money to the merchants Stripe account. So they would have to also take over the merchants Stripe account to get paid out.
All in all, this is a quite secure system. The only problem is that people love to type in their credit card information on sketchy sites that just plain out steal them. With your suggestion, people will still send scammers money because after all, people are and will always be stupid. Just search for „crypto scam“ on Google and you’ll find plenty of examples of people actively sending money to scammers.)
That’s exactly how your proposed solution would have to work as well, if you want to support recurring payments or price adjustments. As soon as you allow the merchant to adjust pricing and/or interval, it opens the possibility for fraud. Because there is some way that the merchant needs to have to adjust these parameters. And if the merchant can do it, so can an attacker that takes over the merchants accounts. Like it would be the case with PayPal today.
(And by the way, that’s also how most of the credit card payments work today. Stripe for example does not allow the merchant to collect credit card information of the customer. Instead, the merchant embeds a Stripe web page into the checkout process which collects the credit card information. All the merchant gets is a token that allows them to collect money from the customer to their Stripe account. If an attacker were to obtain this token, all they could do would be to collect money to the merchants Stripe account. So they would have to also take over the merchants Stripe account to get paid out.
All in all, this is a quite secure system. The only problem is that people love to type in their credit card information on sketchy sites that just plain out steal them. With your suggestion, people will still send scammers money because after all, people are and will always be stupid. Just search for „crypto scam“ on Google and you’ll find plenty of examples of people actively sending money to scammers.)
If you don't offer me Apple Pay and skip the whole payment step, you better offer something I can't get anywhere else because otherwise, I'm bailing.
It’s so fast I sometimes worry I didn’t actually do the checkout.
Shop Pay on shopify is a bit like this
Is using Stripe acceptable?
Honestly, Apple has really knocked it out of the park. Stripe is okay and works well with autofill, but it's still extra friction.
Yeah, apple might be doing something a little anti-competitive here.
Yeah, apple might be doing something a little anti-competitive here.
What if some of my customers use a non-Apple OS to access my site?
That's not really at all how implementing Apple Pay works, and would not affect your non Apple customers. Also, even Apple users can opt to not use Apple Pay if it's offered on a site.
That's the wrong question to ask. Stripe supports Apple Pay but whether or not they do, Stripe is a B2B implementation detail that customers shouldn't ever know or think about. A tiny sliver of them may happen to have heard of Stripe, but your average customer hasn't read Payment Systems in the US, by Carol Coye Benson.
The point is that Strip supports more than one method of payment.
Customers would think about that if they are, for some reason, not enrolled in Apple Pay, but other methods were not supported.
Customers would think about that if they are, for some reason, not enrolled in Apple Pay, but other methods were not supported.
For parent, maybe. For me, no.
Having to give your personal details just to see that the shipping to your country isn't worth (or not available at all) and then sending me an email to say that I potentially forgot to checkout some stuff in my shopping card is the reason I don't even try to fill my details and try and find an alternative shop.
Selecting a country and entering the post code to find out the shipping cost is slightly old-fashioned but works very well.
Selecting a country and entering the post code to find out the shipping cost is slightly old-fashioned but works very well.
I think the future is to never fill-in your cards info anymore, and maybe not even have a card at all.
Once you start using something with a QR Code, it's much much better:
- WeChat Pay and co. (in China);
- PhonePe and co (in India);
You usually have 2 ways to pay with those systems (only systems I'm familiar with, others might be different):
- Merchand shows a QR Code; you scan it and enter the right amount manually. Merchand gets a confirmation.
- Merchand shows a QR Code; you scan it but the amount and details are all pre-filled and you just have to confirm.
In both cases, it's scan + click ok.
Now, if worldwide banks in the world were to have a way to send money to each other without fees and with a single standard, they could make it happen (one can hope).
Once you start using something with a QR Code, it's much much better:
- WeChat Pay and co. (in China);
- PhonePe and co (in India);
You usually have 2 ways to pay with those systems (only systems I'm familiar with, others might be different):
- Merchand shows a QR Code; you scan it and enter the right amount manually. Merchand gets a confirmation.
- Merchand shows a QR Code; you scan it but the amount and details are all pre-filled and you just have to confirm.
In both cases, it's scan + click ok.
Now, if worldwide banks in the world were to have a way to send money to each other without fees and with a single standard, they could make it happen (one can hope).
Is it possible to have recurring payments with the QR pay solutions you mentioned? There are probably a lot of use cases, for example for a gym membership, etc.
Yes. I pay for Netflix via UPI e-mandates. The best part of UPI subscriptions is that I can cancel them whenever without going to the merchant's website.
In Netherlands, iDEAL comes close to UPI as well.
In Netherlands, iDEAL comes close to UPI as well.
While this post is trying to maximise the conversion of customers, I'm always drawn to how the UK's GOV.UK Design System handles these fairly common tasks: https://design-system.service.gov.uk/patterns/payment-card-d...
If you only offer creditcard payments and want international customers, you will missing out on a lot of customers. For example in the Netherlands, iDeal is the standard of payment and many Dutch customers do not have other payment options easily available.
Trying to support international payment methods in general is a nightmare and the Dutch system is one of the most idiosyncratic. Not saying it's bad for users, but I remember integration of support across different banks being daunting (this was several years ago so things may have improved).
Does it mean that mostly, they don't have any Visa or Mastercard?
Indeed. Our debit cards are visa/mastercard, but such cards have numbers like NL01BANK012345678901 (IBAN). Credit cards have no additional benefit in day-to-day life but do have an additional cost.
Ideal is actually ideal for consumers, as the merchant doesn't ever receive personal information. For small amounts, it's only a fingerprint away.
It seems to become a European standard: https://nltimes.nl/2023/04/25/dutch-payment-processor-ideal-...
It seems to become a European standard: https://nltimes.nl/2023/04/25/dutch-payment-processor-ideal-...
Correction. Our debit cards are only mastercard maestro not visa. Maestro is depricated, and soon everyone in EU will have proper international debit cards.
Yeah, only a very low percentage of people will have a creditcard... 99% of dutch online payments will be made using IDeal, which is cheap (free for user, ~20-30ct for the seller) and instant. And works with every bank in the country (and some international ones like Revolut and N26)
There are broadly two kinds of checkout experiences for most payment methods. The SDK flow is where your payment page has the SDK of the processor embedded for a more native experience.
The redirection flow is when you break from the flow of your website and use the processor’s hosted checkout page. It is worth putting in the extra effort to blend the payment page until the end of the checkout experience to not lose your customer’s flow of attention. PayPal one-click checkout button is an example of paypal’s SDK flow.
You actually don’t need the user to reach the final checkout page with all these icons and progressive disclosures for checking out with Paypal
The redirection flow is when you break from the flow of your website and use the processor’s hosted checkout page. It is worth putting in the extra effort to blend the payment page until the end of the checkout experience to not lose your customer’s flow of attention. PayPal one-click checkout button is an example of paypal’s SDK flow.
You actually don’t need the user to reach the final checkout page with all these icons and progressive disclosures for checking out with Paypal
So this article is by one payment provider complaining about other payment providers and at the end telling their readers how wonderful their product is.
If the object is a product, then the force is advertising.
How boring.
If the object is a product, then the force is advertising.
How boring.
The underlying point being made - by the comment - is that if an author is biased because they are selling a product and complaining about their competition, how can the article or the "facts" be trusted?
The orignal article is disguised advertising, advertising in the form of a "knowledgable criticism" of existing payment services.
May the force be with you even if the object isn't.
The orignal article is disguised advertising, advertising in the form of a "knowledgable criticism" of existing payment services.
May the force be with you even if the object isn't.
We are basically an open-source payment orchestrator - we are not even competing with these guys. Haha :)
> (bonus points for the dropdown on expiry date)
I definitely prefer being able to go through inputting my card details using the numpad and the tab key. Having to switch more often between keyboard and mouse adds one more step to the nightmare that is online payment. While it is just a preference though, I wouldn't go so far as to say a date dropdown automatically means bonus points.
I definitely prefer being able to go through inputting my card details using the numpad and the tab key. Having to switch more often between keyboard and mouse adds one more step to the nightmare that is online payment. While it is just a preference though, I wouldn't go so far as to say a date dropdown automatically means bonus points.
Dropdowns are kinda better for mobile though
OG title “Why I won't pay on your website”
Emphasis: Your
Emphasis: Your
HN strips some words from titles when you first submit, I believe its to make them less click bait. The submitter can then immediately edit the title if it mucks up.
This is a rare example of the small fraction where it makes the title more click bait.
This is a rare example of the small fraction where it makes the title more click bait.
For me the benchmark is Mullvad.
The experience of throwing money at them is so satisfying, I almost want to do it just for the rare feeling of zero friction.
If I do want to pay on your website, and it is not as low friction in comparison, I will be considering how much I really want to pay or if I should just give up.
The experience of throwing money at them is so satisfying, I almost want to do it just for the rare feeling of zero friction.
If I do want to pay on your website, and it is not as low friction in comparison, I will be considering how much I really want to pay or if I should just give up.
Oh god online payment systems are the worst. And even good ones sometimes break horribly.
Once I booked a flight online by credit card and the payment timed out (or rather stopped at a late stage without an error). Afterwards the website didn't tell me if the payment went through or not. I called the airline and my bank and neither one could tell me if the payment was successful or not. Both just told me to wait a week and then check again... this was only around 5 years ago.
In the end the payment did go through, however if it didn't, I am sure I would have lost that seat/ticket. Lots of wasted time and stress for nothing.
Once I booked a flight online by credit card and the payment timed out (or rather stopped at a late stage without an error). Afterwards the website didn't tell me if the payment went through or not. I called the airline and my bank and neither one could tell me if the payment was successful or not. Both just told me to wait a week and then check again... this was only around 5 years ago.
In the end the payment did go through, however if it didn't, I am sure I would have lost that seat/ticket. Lots of wasted time and stress for nothing.
One of my undergrad professors, a Tamil from India, had a first and second name that between them totaled 36 characters. He had endless trouble with forms (even paper forms) until he eventually adopted a shortened version of his name.
My first encounter with him was when I was selecting classes and asked a friend "Hey, do you know anything about (short version of his name)?" "Yeah, he's great. That's not really his name, though. That's just all that will fit in the schedule."
My first encounter with him was when I was selecting classes and asked a friend "Hey, do you know anything about (short version of his name)?" "Yeah, he's great. That's not really his name, though. That's just all that will fit in the schedule."
For our microbiology conference event, I just programmatically created a bunch of Stripe Payment Link options for every combination, and used our site to open up the payment link. We record the event using a webhook back into our Airtable.
Though I'm not a huge fan of opening up a new window for payment, this turns out to be much easier for us, implementation-wise. Plus, the Stripe Payment Link UI is able to handle most of the errors and payment methods, add discount codes, etc.
Though I'm not a huge fan of opening up a new window for payment, this turns out to be much easier for us, implementation-wise. Plus, the Stripe Payment Link UI is able to handle most of the errors and payment methods, add discount codes, etc.
> bonus points for the dropdown on expiry date
I usually don't mind those because you can just Tab to them and start typing and it will select the item from the list (if you have guessed the format right, and the dropdowns are native or custom but properly implemented). But why would you ever want that instead of simple MM / YYYY field (or two fields, if you don't want to add masking)?
I usually don't mind those because you can just Tab to them and start typing and it will select the item from the list (if you have guessed the format right, and the dropdowns are native or custom but properly implemented). But why would you ever want that instead of simple MM / YYYY field (or two fields, if you don't want to add masking)?
This would benefit from some examples of perceived "good" user experiences in this space.
Also it's a bit lacking on the stateful side of things. For example, a lot of Amazon customers hit "save card details" and then bam, one click checkout forever; making optimisation in this area highly diminished. Similar story and even more true for vendors that support Apple Pay.
Also it's a bit lacking on the stateful side of things. For example, a lot of Amazon customers hit "save card details" and then bam, one click checkout forever; making optimisation in this area highly diminished. Similar story and even more true for vendors that support Apple Pay.
Slightly OT question: I need to integrate payments on a new service I created[+], and for now I need to use a "merchant of record" approach. Currently I'm choosing between Paddle and FastSpring; any suggestions why should I choose one over the other?
[+] https://chess.braimax.com
[+] https://chess.braimax.com
One thing I've been encountering recently is being required to enter a bunch of info before telling me the postage cost, I think it's a shopify thing. Most of the time I just go somewhere else.
Did anyone experience the Palm payment method introduced by Tencent?
If a website doesn’t offer me the ability to pay without running javascript this is a red flag and i’ll bounce.
The amount of spying in the payments industry is vile enough.
The amount of spying in the payments industry is vile enough.
Is there any valid use case at all for people to progressively disclose card details? There's got to be a reason
It is with the risk rules. If a transaction is considered risky due to amount, location, customer pattern etc, Stripe/ issuer would need more details to lower the riak during Authorization
[deleted]
Does the vagueness of the error message have something to do with reducing frauds?
Surely that's what 3D secure is for. I don't see how blocking error messages reduces the fraud.
All of my accounts come with that enabled by default and will ping my phone app, so stealing my card number isn't enough.
Card details + something I know + something I have.
All of my accounts come with that enabled by default and will ping my phone app, so stealing my card number isn't enough.
Card details + something I know + something I have.
Usually yes. And there can be alot going on: https://stripe.com/docs/error-codes
I guess it's the same intention, why to not tell the user an email is already registered on your site. Could be used for personalized scam/fraud. However often you trade security for comfort.
I guess it's the same intention, why to not tell the user an email is already registered on your site. Could be used for personalized scam/fraud. However often you trade security for comfort.
Yeah it does not make sense to pass on every error message to the customer but don't these error codes get logged on the console anyways?
Is there some way to understand if the payment page is a phishing attack?
[deleted]
> making payments online should have been solved for well beyond doubt in 2023 but
Apple Pay in browser checkout is pretty great
Apple Pay in browser checkout is pretty great
would you pay on checkout.stripe.com?
Stripe checkout is pretty clean and straightforward it's just not blended with the brand of the website (because it is hosted by stripe) which is fine mostly.
The HN algorithm strikes again, and makes it look like a anti-capitalistic rant whereas it’s really about the failure modes of payment pages.
I thought it was going to be a security rant. I was expecting the author to say that he was hesitant to trust an unknown site with their debit card information, and was arguing for using something like the Stripe payment gateway.
My phone number starts with +49 and is longer than a North American phone number. This prevents me from renting a Bixi bicycle in Montreal. You know who likes to rent bicycles? Tourists like me.
In any case my card failed with a generic error, both at the payment booth, and in the mobile app (after working one time).
Another one was a stand up paddling booking website. I shouldn’t need a Canadian postal code to rent something (especially 10km from the border) yet here we are. In any case it was impossible to select the field on my phone, so I dropped out. I wonder how much business they lost to this single bug.
This sort of stuff happens when you ask for data that you don’t need, and validate it beyond your needs. I fight tooth and nail with colleagues to reduce the size of forms to avoid this sort of friction and bugs.
EDIT: oh and IBAN discrimination, which is illegal but happens even on government websites