Think standard oAuth. Github has multiple flows that should cover most purposes here: https://docs.github.com/en/apps/oauth-apps/building-oauth-ap.... The key is that payment data is encoded in oAuth-like scopes, so all authorizations are scoped by amount and lifetime, and are implicitly merchant-specific.
Browser-based flow, where you're already logged into the bank in an existing browser tab:
* Amazon redirects you to oauth-proxy.visa.com where you select your bank (if you've done it already once, it remembers and redirects straight to your bank)
* Visa redirects you to your bank - if you're not logged in, you do a login - this is up to your bank on how to do that - authorize with an existing phone, WebAuthn, etc. On OSes supporting it, this URL can be hooked and handled directly by a native app which may use the device's secure element to store its auth credentials for the bank
* Bank displays you the payment request details (which include your Amazon account email, order ID, etc - all info you need to confirm it's indeed your payment request and not someone else's) and allows you to change them (maybe you want to authorize more or less, or make it one-time/recurring with a daily/weekly/monthly/yearly cap, or set an expiry after which the authorization is no longer valid)
* In the background, Amazon gets a success webhook from Visa (or their processor) saying that this authorization request has been granted, or they can poll an endpoint - this eliminates the need for a final redirect back to them like in normal oAuth
* If this is a recurring charge scenario, Amazon can store this payment request token against your account and use it multiple times, as long as the charges fall within the policy set during initial payment request establishment (if you set a max of $20, they can do as many transactions as they want up to a total of $20).
Device-based flow, where you aren't/don't want to login in to the bank the same browser:
* Amazon redirects to oauth.visa.com as above
* Instead of clicking on your bank directly, you say "authorize via phone", it just encodes the URL of the current page in a QR code so you can scan it on the phone - you then do the above flow there. Because the success/failure of a payment request is already communicated directly between the merchant and Visa, there is no need for your phone to pass any data back to the browser, so no need for a "reverse channel" to be set up.
* On your phone, you may have your banking app installed, so it takes over the domain name of your bank and automatically opens the payment request authorization there, using your existing session within the app.
Point is, not only is there no longer a concept of a card number that can be copied, stolen, or leaked, but the user also remains in control - they can control whether the payment is one-time or recurring, set limits on recurring payments, and be able to cancel these authorizations at any time, after which they're guaranteed that nobody can take more money without going through this auth process again. This eliminates many reasons for chargebacks, and reduces fraud risks for merchants too (merchants are no longer vulnerable since the auth to authorize a new payment request is between the user and their bank directly), so things like behavioral fraud detection or captchas on payment pages are no longer needed.
Downside (for scammers): business models based on a free trial that rely on the user forgetting to cancel, or those who intentionally make cancellation annoying or impossible wouldn't work, because payment requests should list upfront the max amount they can take, and the user can adjust that and make sure the unwanted charge just won't go through even if they tried.
This is no different than chip+pin for physical purchases. There are still other major areas of fraud that has to be addressed.
It doesn’t cover credit risk-even on a debit card, there can be a “hold” period of an arbitrary amount before the final transaction clears. When you swipe a card at a gas station, they often run a $50 authorization hold on your account.
It also doesn’t cover merchant fraud—- Visa/MC covers you if the merchant doesn’t ship the product because they’re a fake company.
Then there are value-added warranty services that higher end cards offer. These are easily worth the 1%+ fee.
> When you swipe a card at a gas station, they often run a $50 authorization hold on your account.
Safeway gas stations upgraded their pumps to have tap-to-pay.
But with increasing gas prices (and not getting into that), they upped the auth hold to up to $125.
Except many card issuers limit contactless payments to $100... rendering tap to pay useless on the pump because it'll deny the preauth and require chip insertion.
> Except many card issuers limit contactless payments to $100... rendering tap to pay useless on the pump because it'll deny the preauth and require chip insertion.
I’ve noticed lately that contactless payments that go over the limit don’t require chip insertion, the reader just asks for the PIN to proceed. Maybe there’s been some updates to the standards?
Hmmm, not all credit cards have a PIN. Debit card, I could see that. I don't know if the data on the card indicates if there is a PIN attached to the card (i.e. ask for it if there is, don't ask if there's not).
The card and terminal communicate on which CVMs (cardholder verification method) they support, and they agree on one. If they can't agree the transaction is either cancelled or processed as "no CVM" (like normal contactless tap & pay with a card) depending on the terminal's and card's risk profile.
We had a similar issue with ATM in Austria where they are all set to max give you 400 EUR. Which was a sensible idea in 2001 but pays for much less in 2024. Somehow the banks have never heard of inflation or really don’t want you to use cash
So, this tickles an idea in my head. Under EU / UK regulations one can “overlay” a users bank account. I had always thought that was useful only as a Mint style approach but this seems feasible
This is a technical solution to a non-technical problem.
My risk to my credit number being stolen is honestly low. The risk is the merchant providing a substandard service 99% of the time, and an OAuth style payment flow does nothing for that.
Someone like Amazon who is a trusted merchant already negotiates fees with their banks and they likely already have an extremely low fee rate.
What Stripe, Square and PayPal provide is a service for integrators who don’t want to
spend money talking to a bank, negotiating a rate, and then implementing the required security to execute their own transactions.
Walmart, Amazon, and the other big companies are not interchange exempt. They are not able to get a significant discount below interchange, hence why they keep financing lawsuits against Visa, MasterCard and such over the bundling of all Visa or MasterCard branded low-cost (non-rewards) and high-cost rewards cards under one banner that they are forced to accept as a bundle.
Merchants would love to reject all cards that are a Visa Signature and above, leaving only the very low cost cards as accepted. The Card Networks have engineered via branding and contracts that this does not occur though.
Browser-based flow, where you're already logged into the bank in an existing browser tab:
* Amazon redirects you to oauth-proxy.visa.com where you select your bank (if you've done it already once, it remembers and redirects straight to your bank)
* Visa redirects you to your bank - if you're not logged in, you do a login - this is up to your bank on how to do that - authorize with an existing phone, WebAuthn, etc. On OSes supporting it, this URL can be hooked and handled directly by a native app which may use the device's secure element to store its auth credentials for the bank
* Bank displays you the payment request details (which include your Amazon account email, order ID, etc - all info you need to confirm it's indeed your payment request and not someone else's) and allows you to change them (maybe you want to authorize more or less, or make it one-time/recurring with a daily/weekly/monthly/yearly cap, or set an expiry after which the authorization is no longer valid)
* In the background, Amazon gets a success webhook from Visa (or their processor) saying that this authorization request has been granted, or they can poll an endpoint - this eliminates the need for a final redirect back to them like in normal oAuth
* If this is a recurring charge scenario, Amazon can store this payment request token against your account and use it multiple times, as long as the charges fall within the policy set during initial payment request establishment (if you set a max of $20, they can do as many transactions as they want up to a total of $20).
Device-based flow, where you aren't/don't want to login in to the bank the same browser:
* Amazon redirects to oauth.visa.com as above
* Instead of clicking on your bank directly, you say "authorize via phone", it just encodes the URL of the current page in a QR code so you can scan it on the phone - you then do the above flow there. Because the success/failure of a payment request is already communicated directly between the merchant and Visa, there is no need for your phone to pass any data back to the browser, so no need for a "reverse channel" to be set up.
* On your phone, you may have your banking app installed, so it takes over the domain name of your bank and automatically opens the payment request authorization there, using your existing session within the app.
Point is, not only is there no longer a concept of a card number that can be copied, stolen, or leaked, but the user also remains in control - they can control whether the payment is one-time or recurring, set limits on recurring payments, and be able to cancel these authorizations at any time, after which they're guaranteed that nobody can take more money without going through this auth process again. This eliminates many reasons for chargebacks, and reduces fraud risks for merchants too (merchants are no longer vulnerable since the auth to authorize a new payment request is between the user and their bank directly), so things like behavioral fraud detection or captchas on payment pages are no longer needed.
Downside (for scammers): business models based on a free trial that rely on the user forgetting to cancel, or those who intentionally make cancellation annoying or impossible wouldn't work, because payment requests should list upfront the max amount they can take, and the user can adjust that and make sure the unwanted charge just won't go through even if they tried.