5 ms·

> Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frust

> Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frustration and lost time due to so many of those having problems)? I agree with your premise, but this is a bad example. Universal payment systems are not a simple task. Even remotely. Go out to any American city, for instance, and as you walk through the stores, catalog the various credit card terminals you see. Not even the PoS system as a whole, but just the credit card interface. You will see dozens of different designs and play on designs by dozens of different manufacturers. If it's hard to do in the physical world, what makes you think it'd be easy in a browser? Everyone wants a share of the pie and that means fragmentation all the way down.

yamtaddle 4y ago
There are enough common elements that it's absolutely do-able. There's no reason the payment methods would have to be hardcoded or anything, they could easily be dynamic but still let the browser supply the UI for greater security, accessibility, and user confidence. Covering 99% of use-cases is far from intractable.
- mattnewton 4y ago
  But until most of my users update I’m stuck with still maintaining the old implementation anyways. Moving these libraries into the on-demand userspace was done intentionally for a long list of reasons, but by far the biggest advantage to me as a developer is control over the updates.
criddell 4y ago
My credit card is stored somewhere on my iPad and the browser fills out payment forms correctly almost all the time. If you have a store and discover people are aborting the purchasing process because your UI is unique, you're going to fix it.
- mynameisvlad 4y ago
  What does this have to do with standardized payment systems?
  - carlosjobim 4y ago
    There are standardized HTML elements for autocomplete forms, including attributes for credit cards. If you follow these on your website, it will be easier for the customer to make their purchase. Combine with Apple Pay / Google Pay and something that used to be an annoying chore is just a couple of clicks.
joshu 4y ago
the credit card shape, mag stripe, number, and security code ARE standardized. but every website wants you to enter that separately into a different form that autocompletes some fields but not others, etc etc. your objection is short-sighted; there are steps.
- mynameisvlad 4y ago
  > Payment card numbers are composed of 8 to 19 digits https://en.m.wikipedia.org/wiki/Payment_card_number https://en.m.wikipedia.org/wiki/Payment_card_number They are usually 16 digits. Except when they're 15 like Amex. Security codes are 3 digits... Except when they're 4 digits like Amex. Magnetic stripes have two separate tracks with two different encoding schemes developed by different organizations, and some point of sale readers will read one, the other, or both. But yes, tell me more about how all these things are standardized. > your objection is short-sighted; there are steps. My point was that everyone wants a piece of the action, meaning standardized interfaces are disincentivized. This is true in the real world and is true in browsers. Do you have any actual rebuttal to that?

yamtaddle 4y ago

There are enough common elements that it's absolutely do-able. There's no reason the payment methods would have to be hardcoded or anything, they could easily be dynamic but still let the browser supply the UI for greater security, accessibility, and user confidence. Covering 99% of use-cases is far from intractable.

mattnewton 4y ago
But until most of my users update I’m stuck with still maintaining the old implementation anyways. Moving these libraries into the on-demand userspace was done intentionally for a long list of reasons, but by far the biggest advantage to me as a developer is control over the updates.

criddell 4y ago

My credit card is stored somewhere on my iPad and the browser fills out payment forms correctly almost all the time. If you have a store and discover people are aborting the purchasing process because your UI is unique, you're going to fix it.

mynameisvlad 4y ago
What does this have to do with standardized payment systems?
- carlosjobim 4y ago
  There are standardized HTML elements for autocomplete forms, including attributes for credit cards. If you follow these on your website, it will be easier for the customer to make their purchase. Combine with Apple Pay / Google Pay and something that used to be an annoying chore is just a couple of clicks.

joshu 4y ago

the credit card shape, mag stripe, number, and security code ARE standardized. but every website wants you to enter that separately into a different form that autocompletes some fields but not others, etc etc. your objection is short-sighted; there are steps.

mynameisvlad 4y ago
> Payment card numbers are composed of 8 to 19 digits https://en.m.wikipedia.org/wiki/Payment_card_number https://en.m.wikipedia.org/wiki/Payment_card_number They are usually 16 digits. Except when they're 15 like Amex. Security codes are 3 digits... Except when they're 4 digits like Amex. Magnetic stripes have two separate tracks with two different encoding schemes developed by different organizations, and some point of sale readers will read one, the other, or both. But yes, tell me more about how all these things are standardized. > your objection is short-sighted; there are steps. My point was that everyone wants a piece of the action, meaning standardized interfaces are disincentivized. This is true in the real world and is true in browsers. Do you have any actual rebuttal to that?