4 ms·
I always thought a sensible approach would have been a sort of "payment tag" that browsers could render directly. Something like <payment name="transactionId">
by hakfoo 6y ago
I always thought a sensible approach would have been a sort of "payment tag" that browsers could render directly.
Something like
<payment name="transactionId">
<amount>30.00</amount>
<currency>USD</currency>
<ordernumber>123456</ordernumber>
<method name="WireTransfer" account="234567" routing="3040567" />
<method name="PayPal" destination="company@company.com" />
<method name="CreditCard" url="https://secure.gateway.com" https://secure.gateway.com" merchantid="123456" />
<method name="Dogecoin" walletid="D0304050600405kgjfd" amount="2600" />
</payment>
This would render as a group of buttons representing the payment choices. The browser would pop up an appropriate form-- potentially in an isolated context where the fields can't be sniffed by on-page scripts, perform the remittance, and submit a structure of verifiable confirmation details in the field transactionId when the form was submitted. Since the flow is steered entirely by the user's browser, there's a stronger degree of trust and control; I could imagine, for example, bank-provided plugins that required a seperate authentication before relaying the card details, or more sophisticated 3-D Secure style checking and fingerprinting. The entire PCI compliance and trusting merchants with the card number problems would never have come into play.
There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000.
- cheph 6y ago> There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000. If it is so simple, why was it not? Are you suggesting it was purely incompetence of the people who standardized the web back then?
- hakfoo 6y agoWhile this is a bit of an after-the-fact view, it seems like there was a moment where they basically said "we've got enough tags." Richer and special-case capabilities tended to move into (first) applet platforms like Java and Flash, and later JavaScript and CSS enhancements atop a fairly thin platform. I feel like this was the same stall-out that created "it took until HTML5 before we had a more or less universal slider form control" and "there's still nothing resembling a OS-native dropdown menu or rich-text widget in pure HTML." That time period sort of coincided with the window of a couple years-- when we still had to think about 40-bit and 128-bit crypto offerings, you had to explicitly navigate to a SSL domain to check out, and things like Flooz were still considered a viable idea. Nobody really knew how to take a payment online, so we ended up basically copying the payment from from a mail-order catalog in HTML. A strong "this is the secure and easy way with big clicky buttons" proposal, supported by the leading browsers, would have steered the nascent market effectively.