6 ms·

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

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.

martinald 2y ago
This is already happening, 16 digit PANs are due to be phased out https://developer.visa.com/capabilities/vts https://developer.visa.com/capabilities/vts
- Nextgrid 2y ago
  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 2y ago
    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).
    - Nextgrid 2y ago
      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 2y ago
        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 2y ago
        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.
immibis 2y ago
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.
- holowoodman 2y ago
  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 2y ago
    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 2y ago
      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.
- l3x4ur1n 2y ago
  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.
lifeisstillgood 2y ago
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 2y ago
  Think standard oAuth. Github has multiple flows that should cover most purposes here: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps 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.
hugs 2y ago
> 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.
- egypturnash 2y ago
  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.
- quohort 2y ago
  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.
- kinakomochidayo 2y ago
  Lightning Network will never get widespread adoption because the UX is horrible.
  - hugs 2y ago
    That hasn't been my experience using Alby and Primal's Nostr client. It's been as easy as Venmo.
- EasyMark 2y ago
  I would never recommend anything as volatile as crypto for a payment system.
throwway_278314 2y ago
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.
EVa5I7bHFq9mnYK 2y ago
You seem to have described Google pay and its tokenization scheme.
hyperman1 2y ago
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 2y ago
  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?
azthecx 2y ago
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 2y ago
  We have had this in the US too for at least a decade, people just don't use them, probably because of convenience.
  - Nextgrid 2y ago
    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 2y ago
      With citi bank I can cap the amount and set the expiration.
sidewndr46 2y ago
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.
- mnky9800n 2y ago
  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.
- Nextgrid 2y ago
  > 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 2y ago
    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.

martinald 2y ago

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

Nextgrid 2y ago
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 2y ago
  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).
  - Nextgrid 2y ago
    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 2y ago
      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 2y ago
        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.

immibis 2y ago

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.

holowoodman 2y ago
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 2y ago
  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 2y ago
    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.
l3x4ur1n 2y ago
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.

lifeisstillgood 2y ago

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 2y ago
Think standard oAuth. Github has multiple flows that should cover most purposes here: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps 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.

hugs 2y ago

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

egypturnash 2y ago
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.
quohort 2y ago
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.
kinakomochidayo 2y ago
Lightning Network will never get widespread adoption because the UX is horrible.
- hugs 2y ago
  That hasn't been my experience using Alby and Primal's Nostr client. It's been as easy as Venmo.
EasyMark 2y ago
I would never recommend anything as volatile as crypto for a payment system.

throwway_278314 2y ago

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.

EVa5I7bHFq9mnYK 2y ago

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

hyperman1 2y ago

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 2y ago
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?

azthecx 2y ago

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 2y ago
We have had this in the US too for at least a decade, people just don't use them, probably because of convenience.
- Nextgrid 2y ago
  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 2y ago
    With citi bank I can cap the amount and set the expiration.

sidewndr46 2y ago

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.

mnky9800n 2y ago
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.
Nextgrid 2y ago
> 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 2y ago
  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.