[Nextgrid]

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-limited tokens the user generates with their bank (or the merchant redirects them there). This would address a lot of the issues - the tokens are useless when leaked (as they only work against the merchant's own account) and can't be misused even by the merchant to go beyond the agreed amount or time limit.

This means with such a system you’d immediately eliminate a whole category of fraud, with the only thing remaining being merchant-level disputes like goods not as described/etc, which can easily be made optional and the user can choose to opt-in for the extra fee. Then you would actually have a good case for lower/no mandatory fees at all.

One problem you need to keep in mind is that fraud mitigation is a big industry in an of itself (some of it is real, some complete snake oil but relies on the underlying problem being real to sell itself) and wouldn't be in favor of a system that is inherently immune to (at least some types of) fraud.

[hyperman1]

You've described Bancontact, the standard Belgian payment system since the 1980's or so. I suspect most EU countries have similar stories.

Paypal etc basically exist to deal with the backward underinvested USA payment systems.

[erichocean]

But @oldprogrammer2 claimed it was just "innovation" and not create-a-problem, rent-capture-the-solution.

Now I'm confused. There's a better way, and other 1st world countries have already adopted it?

[sidewndr46]

From a merchant perspective, there is a significant group that view this as a feature. Not a bug. Once a merchant gathers you credit card info, they can submit basically any transaction they want at any time. Yes, if you do this enough your payment processor will cut you off. But for businesses like gym membership, NYTimes subscription, car rentals, etc. it's a core feature.

The product in that case is not "payments as a service" to the consumer but in fact "payer as a service" to the business. If consumers didn't represent an unbounded ability to generate recurring revenue there are lots of profitable businesses that would go under overnight.

[Nextgrid]

> they can submit basically any transaction they want at any time

This can be generally be accommodated in my suggested model, they just have to specify upfront how much & how often they'd want to charge. If the gym membership is 50 bucks a month, then the token has a monthly limit of 50 (or maybe a bit more, to account for potential extras). The token lifetime could be set for the membership duration.

> car rentals

Get 1 token with your rental fee + a separate token (scoped until car return date + some time to inspect/discover any damage) for the deposit amount?

[sidewndr46]

You're thinking technical solutions to a sociological problem. Businesses like this are built on the fact that they can charge you an unspecified amount for an indefinite amount of time. Any attempt at a technical solution means those businesses refuse to adopt that solution.

[mnky9800n]

I suppose in this system you could white list such things. It would be a box to click when it directs you through the Auth process. I guess you could directly implement this in stuff like Norway's bank id system.

[martinald]

This is already happening, 16 digit PANs are due to be phased out https://developer.visa.com/capabilities/vts

[Nextgrid]

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.

[martinald]

In a word yes.

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).

[peteforde]

The alarming rise in the incident rate of inappropriate chargebacks ("my fries were cold") really pisses me off as a sane user of contemporary credit card infrastructure. That is, I think of chargebacks as an absolute last resort; essentially a bulwark/ombudsman to protect me from bad actors. It should be used incredibly conservatively, and it should have significant reprocussions if it is used inappropriately; sort of like steep fines for hitting the emergency strip on a subway because someone wont move their backpack.

If chargebacks go away and aren't replaced by something at least as effective, that means that we're losing one of the most significant advantages intrinsic to the payment mechanism: peace of mind.

[hakfoo]

Chargebacks are in many cases the outsourcing of proper consumer-protection regulation and everyday customer service.

When the merchant fails to deliver or underdelivers -- "my fries were cold" -- appropriate customer service should be meeting the customer at that point and addressing it directly.

Modern systems of unempowered on-the-ground employees and endless loop self-service support stand in the way of that. Consumers naturally respond by pulling the levers that remain, which is invoking the wrath of American Express.

[alex_lazarin]

Reasonable people can disagree. What is a customer to do if they think a merchant is not a bad actor, but mistakenly refuses to refund their purchase? A chargeback seems like the fastest and cheapest option to resolve the dispute.

[peteforde]

Only if you approach the domain with ignorance. It's very, very clear that chargebacks are not the play in most cases.

[rightbyte]

> peace of mind

Pay with cash. No risk of recurring charges, charging more than what you hand over, etc.

[kweingar]

This doesn't seem relevant to a discussion about chargebacks, a feature that cash famously does not have.

[Nextgrid]

Thing is, if you eliminate the risk of unauthorized transactions, you can then reasonably discontinue the concept of chargebacks as a whole, replacing it with a mediation/arbitration service that consumers can opt-in for an additional fee.

This would open the door to cheap or even completely fee-free transactions if the user doesn't want to opt-in to additional protection, which they reasonably may not want when the stakes are low enough (you weren't gonna chargeback a lunch anyway).

But for this to be viable, the risk of unauthorized transactions/origination fraud needs to be eliminated completely at a technical level, something I believe an oAuth-style system would do, and currently none of the many of hacks on top of the legacy system address. Otherwise, you'd still need to take some fees to refund unauthorized transactions, separate of customer-merchant conflicts.

[jkaplowitz]

How do you handle the part of chargebacks that currently validly apply to authorized non-fraudulent transactions, like services/product not delivered or not as described, or accidental double charges from vendors like random taxi drivers with whom you don't have a way to arrange a refund?

[anonzzzies]

mediation/arbitration

It already works like that here (eu) for debit cards (which most people have; very few have credit cards although they don't know the difference). Double charges from taxi drivers is not possible as it's tapping or dipping your card and you are there for that (we are assuming some system that prevents someone stealing your card like biometrics or whatnot); products not as delivered is responsibility for the seller to refund/replace and in other cases you go through a process of mediation. I had it once in my life, which is now 50 years. It sounds like Americans willy-nilly chargeback whatever because they can (fries were not hot or cold enough): seems not very good for the fees. Most people who travel have creditcards here and the most ones I know have no idea they can chargeback or ever needed it.

[Nextgrid]

My point is that this would become optional and the cardholder chooses whether to opt-in (and pay an extra fee) at the time of payment.

If the cardholder doesn't opt-in then the payment is as good as cash (with the same recourse available as if you paid cash).

This could allow low/no-fee transactions for low-stakes situations where the chargeback protection wasn't going to be used anyway.

[ADent]

Zelle did that, but then the news had stories about Granny sent money to a scammer and the bank won’t give back her money.

[hugs]

> You could eliminate a lot of the fraud by moving off a mostly-static identifier to merchant, amount and time-limited tokens the user generates with their bank (or the merchant redirects them there). This would address a lot of the issues - the tokens are useless when leaked...

This almost sounds like a subtle recommendation for the Lightning Network. It's based on single-use invoices that are locked to a specific recipient and is usually limited to specific amounts.

[quohort]

It's pretty much how every cryptocurrency works, with separation of public (receive) and private (send) keys.

The fact that invoices are temporary in LN is a weakness of the design, not an intentional choice. The lightning network represents a regression from the typical use-case of cryptocurrency because both sender and receiver need to be online to make a payment.

[egypturnash]

There's a lot of interesting ideas around cryptocurrency but they all kind of have the problem that they're associated with cryptocurrency, which is now strongly associated with absurdly high transaction fees, get-rich-quick scams, and wasting colossal amounts of energy for a pathetically-low transaction throughput.

Good luck convincing J. Random User that your cryptocurrency is none of these things.

[EasyMark]

I would never recommend anything as volatile as crypto for a payment system.

[kinakomochidayo]

Lightning Network will never get widespread adoption because the UX is horrible.

[hugs]

That hasn't been my experience using Alby and Primal's Nostr client. It's been as easy as Venmo.

[azthecx]

Portugal like many European banks already has a working solution to this for 20 years where you can create temporary card numbers and use that instead or, as of late, pay directly through an app that enables this same behaviour.

The Netherlands had a similar system where they used physical totp (I believe) terminals which generated them from your bank card + pin, completely offline. Nowadays everyone uses iDEAL identically to what you describe.

[Workaccount2]

We have had this in the US too for at least a decade, people just don't use them, probably because of convenience.

[Nextgrid]

Unless you can cap the amount it’s indeed pretty useless. Most systems like this that I’ve heard of do not allow you to do that.

[Workaccount2]

With citi bank I can cap the amount and set the expiration.

[EVa5I7bHFq9mnYK]

You seem to have described Google pay and its tokenization scheme.

[immibis]

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 the payment type.

[rafram]

That’s fair, but paying by credit card lets you:

- Keep the money in the bank (and earn interest on it) for another month or so

- Contest fraudulent charges or payments for goods or services that are never delivered

- Earn travel rewards (I know, those have systemic downsides)

- Pay any business in essentially any country in any currency with no fee for you and a low fee for the business

[Muromec]

SEPA has no fees and doesn’t care about currencies either. It’s EU only however.

[snotrockets]

You're wrong on all accounts here:

1. Banks are also allowed to charge fees for SEPA transfers, with some limitations.

2. It does care about currencies, in that it only supports one: the E stands for Euro, and all SEPA transfers, in the four rails it provides, are in Euros, including transfers from and to countries that are not in the euro zone.

3. And SEPA isn't limited to the European Union, as it has 36 states participating in the scheme, more than the EU's 27.

[l3x4ur1n]

I don't know from where you are, but in my country this is considered generally a bad or not safe idea. When you send money directly to someone, if they are fraudsters, it is very hard to get that money back. On the other hand, it's generally easier when you paid with your debit card. And even easier and safer if it was a credit card.

[immibis]

The victim is identifiable by their bank and therefore traceable by the law enforcement agencies. If they're fraudulent, men with uniforms and guns come to their house and put them in jail. It's a clever system, really.

[immibis]

I meant to say the recipient, obviously.

[holowoodman]

The things that are still missing to make this perfect:

- 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.

[Muromec]

Dutch iDeal will be rolled out continent wide pretty soon ( soon in bank time ), which is what you want.

Last time I checked instant sepa (which was today) it was free as in zero commissions on either side and was actually instant.

[jkaplowitz]

Depends on the bank. In Germany, N26's free account charges 0.49€ per instant SEPA transfer, and sometimes it's unavailable because the other bank (e.g. one used by many German doctors) only supports non-instant SEPA.

But yes, instant SEPA is often free and often available and very nice when both of those are true.

[lifeisstillgood]

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

[Nextgrid]

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.

[CyanLite4]

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.

[FireBeyond]

> 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.

[_w1tm]

> 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?

[FireBeyond]

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).

[nasmorn]

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

[lifeisstillgood]

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

[treflop]

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.

[simfree]

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.

[throwway_278314]

I'm not sure you can eliminate fraud. You can shift it around, but not eliminate it.

Sweden thought going cashless would reduce crime. Nope, crime increased.