181–190 of 377 posts
Just imagine how different the Internet would look like today if receiving payments would’ve been as easy as receiving email from the beginning. That it is not trivial for a single person on the Internet to receive payments without a third-party involved, in my mind, leads directly to an Internet that is based on ads and on monopolies: You can’t make a living posting stuff online on your own private website. Because…
I wonder what EU will come up with in the future, some kind of digital cash? Private transactions that must work instantly with all banks doing business in the EU? Several countries here have their own solution, but none of them are compatible with each other. (Please correct me)
Just imagine how different the Internet would look like today if receiving payments would’ve been as easy as receiving email from the beginning. That it is not trivial for a single person on the Internet to receive payments without a third-party involved, in my mind, leads directly to an Internet that is based on ads and on monopolies: You can’t make a living posting stuff online on your own private website. Because…
Just imagine how different the Internet would look like today if receiving payments would’ve been as easy as receiving email from the beginning. That it is not trivial for a single person on the Internet to receive payments without a third-party involved, in my mind, leads directly to an Internet that is based on ads and on monopolies: You can’t make a living posting stuff online on your own private website. Because…
Earlier quoted context omitted.
A lot of the fraud hinges on the fact that all you need to drain an account is a static card number. A lot of hacks are subsequently piled on top of that to try and make it harder (SCA/3D Secure, captchas, etc), and a lot of busywork is spent tidying up the consequences of that (chargeback handling, etc). You could eliminate a lot of the fraud by moving off a mostly-static identifier to merchant, amount and time-limi…
I often make medium-to-large purchases using SEPA bank transfer. The merchant gives me a bank account number, a random or serialized reference code, and a week to make payment. I go to my bank, and send the money to the bank account, inputting the same reference code. Once it arrives (usually within the day or the next morning) the thing is paid. This works for most online purchases that are not urgent and support th…
- SEPA instant transfers (exist, but cost extra)
- A consistent (across all banks) API to poll for received payments for the merchant
- A consistent API (e.g. an URL schema that browsers do support) to quickly fill in payment details with your bank's transfer form.
Earlier quoted context omitted.
This is already happening, 16 digit PANs are due to be phased out https://developer.visa.com/capabilities/vts
The page is light on details, but is it scoped and merchant/amount/time limited? Because if not, it’s yet another “hack” that merely reduces one specific type of fraud (when a card number is leaked) without fully addressing the problem, so the need for chargeback arbitration (and thus associated costs) persists.
You'll still get a lot of chargebacks by the way. With a lot of ecomm I've been involved with the fraud you are talking about is actually a small part of chargeback volume. Most is unhappy or demanding customers, or another type of low level fraud, claiming goods didn't arrive despite a photo of the person literally accepting them from the delivery company. This is absolutely rampant in b2c with smaller merchants (I am aware you mentioned this but not sure if you are aware of the scale of it).
Earlier quoted context omitted.
A lot of the fraud hinges on the fact that all you need to drain an account is a static card number. A lot of hacks are subsequently piled on top of that to try and make it harder (SCA/3D Secure, captchas, etc), and a lot of busywork is spent tidying up the consequences of that (chargeback handling, etc). You could eliminate a lot of the fraud by moving off a mostly-static identifier to merchant, amount and time-limi…
Can I understand this flow? I want to buy a CD from Amazon for 19.99. I click on my bank application (or maybe some QR code on Amazons site) And that tells my bank app on my phone to authenticate my phone agains the bank And ask for a 16 digit number that is solely for amazon, 19.99 and 20240812
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.
Just imagine how different the Internet would look like today if receiving payments would’ve been as easy as receiving email from the beginning. That it is not trivial for a single person on the Internet to receive payments without a third-party involved, in my mind, leads directly to an Internet that is based on ads and on monopolies: You can’t make a living posting stuff online on your own private website. Because…
I agree. These middlemen take our work and monetize it never cutting us in (Google, Facebook, X, etc…)
Stripe, Block, and PayPal each solved a massive pain point. PayPal provided a way to pay people and vendors without giving away your credit card number. Square made it easy to accept payment in person on a phone, without an extensive upfront underwriting experience and without expensive fixed monthly fees. Stripe did the same as Square, but for accepting online payments. Fraud and Risk come in many forms, and these p…
Earlier quoted context omitted.
> For a 3% discount, It is fantasy to think they'd get a 3% discount. The goods in stores that take only cash do not tend to be cheaper than those that do. They know what people are willing to pay and will charge the price. If they see people are willing to pay $99 with a credit card, then they'll be willing to pay that with cash.
In Poland, the default way for computer shops in 2000-2010s was to offer 2% discount when paying in cash. (The prices displayed were assuming cash, so if you paid by card, you'd pay more.) I didn't see this anywhere else though. It probably made sense for computer shops because most transactions one would do there would be sporadic, big, and planned. (Since then, the Mastercard/Visa fees went down to 0.2-0.3% due to…
In the US offering different prices when paying by cash vs card was a violation of the agreement with Visa, as is putting a minimum price threshold for card usage.
It's still fairly widespread though, and occasionally makes the news. Might explain why you didn't see it often.