Hacker News Reader

Comment by eduction | Hacker News Reader

You can blame the evil competitor but the real problem is that credit cards are not the right tool for payments to strangers over the internet.

Every time I do a CC transaction I’m giving a stranger exactly the information they need to do an entirely different, arbitrarily large CC transaction in my name with any merchant. That’s bonkers.

I’ve recently seen more use of Apple Pay via websites. Assuming it works as Apple Pay usually does, this at least is technically more secure (though I don’t like giving Apple more power) since it’s basically an exchange of cryptographically secure/verifiable one time tokens.

PayPal is no one’s favorite but at least if you use that you’re not handing over your CC number. (And yet they seem to lock out tons of merchants, hmm)

Why are we still using credit cards? It’s not great as a consumer either - I have had my card locked for traveling within the same city and spending maybe $20 at a merchant I don’t usually visit. I had it locked because of a $5 web service monthly charge - and I had verified the same charge the two prior months.

View on HN

> Every time I do a CC transaction I’m giving a stranger exactly the information they need to do an entirely different, arbitrarily large CC transaction in my name with any merchant. That’s bonkers.

You may be surprised to know that, when doing a "conventional" CC transaction, you are most certainly not giving any stranger information that would allow them to perform a transaction in your name on another merchant. What you are doing is providing your card information to a PSP (payment service provider) that has been contracted by the merchant and will provide the merchant with a token with which the merchant can trigger a charge request to your card but only to their own pre-approved acquirer account. The merchant can do nothing else with these tokens.

A breach of the merchant's token database would be embarrassing but harmless. A breach of the PSP's database of card numbers would be bad and inconvenient for the cardholders, sure, but it would be a business-terminating event for the PSP as its PCI DSS [0] compliance would be shattered and it would be unable to operate again.

In summary, ordinary card payments are essentially as secure as Apple Pay. The only difference is that in one case you are trusting a gigatech brand which is very saliently involved in the process but whose side-business in payments has only operated since 2014, while in the other case you are trusting businesses that you may or may not have ever heard of —Adyen? Braintree? WePay? Worldline?— but that have probably been dealing with secure payment processing as their primary or only business for much longer.

[0] https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...

I think you missed the “over the internet” part. When you do a CC transaction over the internet, you give the merchant your CC number and all the other information needed to make a transaction happen. A legitimate merchant may pass that information directly to a PSP, but you can’t deny you’ve given the merchant the information. Surely you’ve filled out a CC form in a website before?

Yes, I have filled out a CC form on a website uncountably many times. I can also deny that I have ever given any merchant my card information (at most, if the merchant was utterly massive, I may have given my information to their own fully-owned subsidiary PSP).

My source is that I work in a payments backend software engineering team at a large company (FTSE 100) that provides an ecommerce platform for multiple medium-to-huge retailers worldwide. And yet, even at such a massive scale, neither our software nor let alone our partnered retailers ever even see the customer credit card number. It's not that we pass it directly to the many PSPs that we integrate with. Rather, only the PSPs' own systems actually see it. And yet, if you were to shop online on any of our retailer partners, as a customer you would still have the illusion that you are giving the actual merchant your number.

Could a non-PCI-compliant merchant ask you for your credit card number and store it themselves? Well, technically yes. But then they would not be able to do any legitimate transaction using it, as they have no way to use card numbers to get money into their bank account without a PCI-compliant PSP performing the transaction.

Could a non-PCI-compliant merchant integrate with a PSP in such a way that they send the inputted card number to the PSP [0] rather than the PSP receiving it directly? No, the PSP would laugh in their faces at the suggestion.

Could a non-PCI-compliant merchant ask you for your credit card number and details and then use them to buy stuff in your name for themselves? Yes, but "non-PCI-compliant merchant" is a very bad euphemism for "online scammer".

    [0] One exception being MOTO (Mail Order/Telephone Order) transactions, but they are a specifically regulated case which, by its very name, is by definition not applicable to online card input.

I think you’re confusing what you’re supposed to do (according to PCI) vs. what you’re technically capable of doing. Look at the Stripe’s documentation for creating a payment method [0]. The parameters it takes are card number, expiration, and CVC. Any merchant using this API could trivially save the information for future, malicious use.

0: https://stripe.com/docs/api/payment_methods/create

Please refer to the section just above, in the "Tokens" section. Emphasis is mine:

> Tokenization is the process Stripe uses to collect sensitive card or bank account details, or personally identifiable information (PII), directly from your customers in a secure manner. A token representing this information is returned to your server to use. You should use our recommended payments integrations to perform this process client-side. This ensures that no sensitive card data touches your server, and allows your integration to operate in a PCI-compliant way.

> If you cannot use client-side tokenization, you can also create tokens using the API with either your publishable or secret API key. Keep in mind that if your integration uses this method, you are responsible for any PCI compliance that may be required, and you must keep your secret API key safe. Unlike with client-side tokenization, your customer's information is not sent directly to Stripe, so we cannot determine how it is handled or stored.

So in summary, yes, you can integrate with Stripe in such a way that you send them the card details... but then your business will need to be PCI compliant to the level of a PSP which, believe me, is damn hard. If you suspect that a merchant may go through the trouble of becoming PCI compliant only for the sake of being able to get customers card numbers for possible future malicious use, or do it in such a shoddy way that a malicious employee will be able to steal card numbers, you might as well just stop trusting online card payments in absolutely all cases, including Apple Pay.

You are insistently missing the point, and overlooking a series of security flaws just by reasoning that people aren't authorized to exploit them.

I really hope that your job at that security provider is on marketing, because this is a hell of a bad mindset to work with security.

This conversation is really crazy to me. I’m going to assume these people really do work in payment processing and it explains a lot. Apparently they can’t even properly recognize a potential attack vector let alone mitigate it. If this mindset is common in the payments industry, then it explains why payments are still so insecure.

"But, but, it's illegal". But nonetheless it was a illuminating debate.

I don't think you have paid enough attention to detail when reading my comments to have an informed opinion as to whether I am "missing the point" or whether I am instead talking from in-depth practical experience on the subject.

New user joining the fray here. I worked in cybersecurity at a bank for many years. I haven't read all of what you said, because I agree that you're missing the point that someone was making. Right now, I could throw up some kind of merchant page for some homebrew service, and have an HTML form that asks for a credit card number a CVV and an expiration date. That would be illegal or otherwise non-compliant with PCI, absolutely but it's technically doable. Every time that someone types in a credit card number into a website, they have to trust that the merchant they are doing business with is handling that data in a secure and compliant manner. That is the point of the OP.

Their point extends to the fact that there are other ways of exchanging payment data that would not allow a malicious recipient to reuse that data illegally.

You’re arguing that using a PCI compliant PSP solves the problem of credit card number harvesting, but that’s not correct unless the entire transaction takes place on the psp (like PayPal). Once the payment details are collected in environments outside the psp’s control, it’s not protected. For example, payment info could be skimmed by devs with access to payment pages using js like in the NewEgg Magecart attack

No, that is not what I am arguing. Please reread the thread.

Here is a summary of your argument in your own words:

> So in summary, yes, you can integrate with Stripe in such a way that you send them the card details... but then your business will need to be PCI compliant to the level of a PSP which, believe me, is damn hard.

What others in this thread are arguing is that sharing CC details with anyone is a stupid way of doing payments. It doesn't matter if you're interacting with a PSP or otherwise. You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.

As another person that's worked in payment (specifically aquiring) for 6 years: PCI compliance is not a trivial matter as you seem to believe.

It involves recurring audits of all systems in contact with cc information.

While I've never used stripe, i doubt they'd let you use that API without the certificate, as they wouldn't be able to do the aquiring for illegitimate transactions such as that. They could lose their status as an aquirer if they did that knowingly, and that would make it impossible to process any visa/Mastercard transactions.

You're more likely to encounter a simple scam/phishing site then a legitimate shop that let's cc information onto their servers. And that's honestly the only danger apple pay protects you from.

I’m not sure what you’re replying to?

He says:

> You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.

He’s advocating for a more secure one-time way of making a payment.

It would be more secure since it’s one-time and could not be reused even if the merchant didn’t use a pci compliant design

What PCI says is irrelevant. The argument being made is that when you enter your CC number into a website you have no idea if the receiving party is PCI compliant or not. There are ways to design a payment systems that reduces this counter party risk.

You:

> You may be surprised to know that, when doing a "conventional" CC transaction, you are most certainly not giving any stranger information that would allow them to perform a transaction in your name on another merchant.

How do you know as a client the merchant doesn’t have a skimmer embedded in their payment page? Or that they don’t post directly to their servers (whether accidentally or not)? Are the PCI police going to catch them? Maybe they want to store cards to process later and don’t know or care about pci.

The problem is using the same details for every transaction in a loosely authorized way.

In a perfect world the merchant won’t have access to the card details (like with one-time payments) and everything would go thru a provider with a preauthorized payment. But we don’t live in that world right now.

What point are you even making?

Are you talking about trivial e-commerce transactions that you could make with Shopify? Yes, you could embed a payment gateway here. However, this is hardly universal or the norm.

In an actual application, you're going to have some API layer over the processor you use. You don't store these credentials, but you do pass them over your API layer and could easily intercept them.

I'm making the point that I work in a department that develops a payment platform for a variety of retailers and has to perform non-trivial integrations with a broad range of PSPs worldwide, covering all sorts of payment flows, including cases in which the PSP itself has had to do new development on their end to cover use cases that they had never come across before. And yet, we do not at any point pass the card details through the API to the PSP.

The input of all payment method data by the customer takes place either in PSP-hosted fields, on an iframe of the PSP front-end, or via a PSP-provided SDK or drop-in UI, in such a way that our software never sees the introduced data. All we see are the sanitised details (card type, BIN, and last 4 digits) that the PSP then sends to us.

That's actually not how most of e-commerce payment works nowadays. If you use Shopify, merchant doesn't see your credit card. Same for SquareSpace. Same for Salesforce Commerce Cloud / Demandware, where everything is more often integrated with Stripe/Paypal directly and merchant never even see it. Very rare the merchants that will actually "see" your credit card.

Merchant doesn't pass your information to the PSP, you are actually talking to the PSP directly.

You don't send anything to the merchant. The information goes directly to the PSP and the PSP sends a token to the merchant.

This usually works by the PSP embedding iframes for the CC fields on the merchants site (so you're inputting directly to e.g. stripe.com)

People use Stripe’s forms because they’re convenient. It’s not a requirement in any way. Stripe provides APIs to build everything in their provided forms so you can build the functionality into your own site easily.

You are apparently not working in eCommerce and don't seem to know how 99% of merchants work nowadays. Merchants don't integrate by calling the Stripe API. They use a platform and those integrations are built-in. The amount of merchants that are actually building their own integration to Stripe API is a very small %, and majority of them would be very large retailers that have the staff to create their own ecom platform and are PCI compliant. Small/medium retailers for the most part are not working that way.

Again, merchants don’t integrate by calling Stripe APIs directly out of convenience. It’s more convenient to use an out of the box solution. But from a technical perspective, nothing is stopping a merchant from accepting your CC details directly.

> But from a technical perspective, nothing is stopping a merchant from accepting your CC details directly.

From a technical perspective, no, nothing is stopping the merchant from asking you for a string of numbers and a month/year date, storing it, and believing that "technically" they can send it to the Stripe API to charge you.

That's when they will realise that, from a business perspective, there absolutely is something stopping them: that they literally cannot do any business whatsoever with your CC details directly, unless they are fully PCI compliant to the same level as an actual PSP.

I had a job waiting tables when I was a teenager when my co-worker got busted for writing down credit card numbers and info when she took the tables' cards to charge them. Apparently she had racked up over 100 thousand in fraud over time.

What stops a business from doing the same thing?

That's like saying you can't steal from the grocery store because 99% of people don't steal from the grocery store.

You’re usually prohibited by the PSP from gathering or storing the CC details directly. You’ll notice you often don’t give the merchant the details directly.

Some large merchants do take the details directly, but they typically have to go through all the PCI compliance hoops and maintain that.

There are exceptions, but most of the time the merchant does not see your credit card details.

What prevents me from cloning some product's website and changing the payment form to send me the details instead, which I then submit somewhere else to purchase something online for myself? Not sure why Stripe or PCI is even important here.

(IMO) what GP was arguing for is that we should have a fundamentally asymmetrical form of payment, viz. the information I give for one purchase should not be able to be reused for another purchase, like a one-time token. Imagine if you had to send your private key every time you wanted to purchase something in crypto, for example.

This is correct and the GP is (confidently) talking nonsense.

However the big issue is most normal users would not have the ability to see if they're using an embedded iframe or cross origin JS from Stripe, Braintree, etc.

He is not talking no-sense. He is talking what he perceives as a user.

the same way that when you get a refund, you dont see the money back immediately. What the user doesn't know is that when you pay a business, the same thing happens, and the business don't get the money immediately.

And to pay by credit card feels much more insecure than using paypal or amazon pay, even if it isn't.

No. In best case, you’re giving your payment details to a PSP. A couple years ago NewEgg had a javascript skimmer on their checkout page that harvested all their customers payment details for months. Obviously anyone with access and intent could do the same for any payment page.

I've used plumbers and dentists where, over the phone, they collect your CC information, sometimes as a deposit before doing work.

Always made me nervous... are they writing it down? Typing it into their home-made software?

Those are MOTO (Mail Order/Telephone Order) transactions, and follow a different regulation than online card transactions. See here: https://docs.adyen.com/point-of-sale/mail-and-telephone-orde...

> I have had my card locked for traveling within the same city and spending maybe $20 at a merchant I don’t usually visit. I had it locked because of a $5 web service monthly charge - and I had verified the same charge the two prior months.

This happens to me almost every time Skype bills me, and I've been a customer for probably 10+ years with both my bank and Skype, and the billing is regular as clockwork. For at least of half of that time, I've complained about it vocally and customer service can't do anything. Now I think about this every single time I hear "AI-assisted fraud detection", and by extension, "AI-assisted security" and really "AI-assisted XYZ". Without another credit card, I guess I'd simply live in constant fear of being embarrassingly declined totally at random on any/every transaction. It's not like I* know the billing cadence, even though my bank has a decade of history.

Clearly they are simply selling my history to the highest bidder, because they certainly aren't using it to help me. On a related note, ever notice that vanilla "exact substring match" search even in gmail is just as bad as google web search? All these corporations that are allegedly indexing us to "value-add" with some perfect high-resolution consumer model can't even do basic shit despite all the spying. I almost expect* my privacy to be fucked, like I guess hey that's modernity. What never ceases to surprise me lately is how the pretense has kind of dropped and we get nothing in exchange, even petty conveniences.

> This happens to me almost every time Skype bills me, and I've been a customer for probably 10+ years with both my bank and Skype

Why are you still with that bank? Even if you like everything else about them, couldn't you just open an account with another bank for Skype billing? Having more than one account is helpful anyway for avoiding having a single point of failure where you can't buy anything.

Unfortunately we didn't use the contactless change to finally fix this. NFC payments are still stuck in the world where the client doesn't have a way to make the payment themselves so has to trust the payment terminal the merchant puts in front of him with their secret information. The transaction should have been reversed. The merchant should have the dumb side, where they only communicate payment details, and the client's phone should be the one doing verifications and initiating the payment. It's bonkers that this hasn't become standard yet. Even more bonkers that internet payments didn't make the same switch long ago.

at least in this respect the now prevalent UPI (unified payments interface) used throughout India fares better.

each merchant -- even a roadside vendor or a mobile hawker of wares -- displays a QR code that has their payment account details / UPI handle.

Customer uses their own phone and UPI payment app to scan that QR code, look at the merchant details displayed, punch in the amount to pay and authorize the payment using their PIN.

(a variation on this is: hand-held POS terminals display a QR code that also encodes the amount to be paid so that the customer doesn't have to punch in the exact amount).

and since this is a unified protocol the users are not stuck with a single payment app or a single payments processor or a single bank network to transact with each other. QR codes are universal - can be scanned by any UPI app.

I have other reservations about the digital trail this leaves for every petty transaction of your life -- and the small risk of a petty vendor being able to harass you later based on the information you leave in their records.

If we don't trust the government -- this makes us jittery about how much they can track you or even cripple your life by disabling a few key things that you need this all to work smoothly.

Those risks aside,this UPI system has been a boon to ease of transactions (without worrying about handling cash and change) across the country. Net positive with some scope for improving privacy protections.

> look at the merchant details displayed, punch in the amount to pay and authorize the payment using their PIN.

Feels like a lot of work. I prefer just tapping my phone and then getting the amount charged pushed to my phone and watch so I can complain if its wrong whilst I'm at the checkout.

That would have been nice, but not backwards compatible with millions of POS terminals and payment processing setups out there.

One big advantage of contactless card payments as implemented in most countries is that you can seamlessly introduce it, making it look like a regular chip or even magnetic stripe transaction to the POS and everything behind it.

With the recent new QR systems around Southeast Asia, they got around this by adding support to existing terminals with just a software update. They print out the QR code for the payer to scan. It’s a bit janky, but works until the merchant updates their terminal to one with a screen capable of displaying the QR.

It might work for some use cases, but being able to receive a payment is often only part of the story. There's reconciliation, settlement, refunds, tax reporting, handling of/liability for fraud disputes and much more.

For example, consider a rental car agency or a hotel reservation. These usually make extensive use of the pre-authorization "feature" [1] of credit cards to reserve a deposit without actually charging it before the final billing amount is known. After a rental car is returned, toll charges are often posted to the card weeks or months after the rental.

QR payment systems often don't support these use cases at all (since they're usually payer-initiated and confirmed); and even if they did, chances are that their API semantics are sufficiently different from credit cards as to require significant reworking of the POS and/or backoffice systems of the merchant.

[1] It's actually more of a historical artifact of how authorization and clearing/settlement used to, and to some extent still do, run over almost completely independent rails, but for some use cases, this can actually simplify things.

> It might work for some use cases, but being able to receive a payment is often only part of the story. There's reconciliation, settlement, refunds, tax reporting, handling of/liability for fraud disputes and much more.

Disputes are quite simplified by the fact that this is always a "customer present" transaction; the platforms generally simply do not provide the ability for the payer to dispute and this is understood by the payer.

Refunds are fully supported by every QR system in wide use. Reporting and reconciliation is different but not a problem; the QR service providers all integrate with POS systems and accounting systems.

In many cases in these markets, merchants and consumers both went from dealing mostly with cash to dealing mostly with QR, so there is less of a legacy issue.

> For example, consider a rental car agency or a hotel reservation. These usually make extensive use of the pre-authorization "feature" [1] of credit cards to reserve a deposit without actually charging it before the final billing amount is known. After a rental car is returned, toll charges are often posted to the card weeks or months after the rental.

> QR payment systems often don't support these use cases at all (since they're usually payer-initiated and confirmed); and even if they did, chances are that their API semantics are sufficiently different from credit cards as to require significant reworking of the POS and/or backoffice systems of the merchant.

Bharat QR (India), Alipay & WeChat Pay (China) and QRIS (Indonesia) all support pre-auth and are widely accepted for hotels and car rentals in their respective markets.

Sure, the APIs are different, but that hasn't prevented almost universal adoption in the world's largest and second-largest markets (India & China) and rapid ongoing adoption in the world's fourth-largest (Indonesia).

> Bharat QR (India), Alipay & WeChat Pay (China) and QRIS (Indonesia) all support pre-auth and are widely accepted for hotels and car rentals in their respective markets.

Interesting, I didn’t know that!

Anyway, all requirements I mentioned definitely all feasible using QR codes (and apparently it’s already been done) – I just don’t think it would be a drop-in replacement at the terminal-to-POS interface if the existing terminal expects a credit/debit card like interface.

And the point you mentioned probably makes this a non-issue in many cases anyway:

> In many cases in these markets, merchants and consumers both went from dealing mostly with cash to dealing mostly with QR, so there is less of a legacy issue.

EMV is in a substantially better position than online credit card payments: the terminal cannot clone a card (though it sees a PIN and card number, it does not see the CVV, so it is not useful for online transactions, and the card contains private keys which are relatively hard to extract. The only remaining hole is creating a magstripe card, but these are becoming rare even in the US). The card does see and verify the transaction. The two main issues are the PIN entry onto the pad (which exposes some information, though with NFC this hole is somewhat removed), and the fact that the payment is still initiated by the terminal, with no way for the user to independently see the transaction amount before authorising the transaction (NFC on a phone can in principle fix this, though in a somewhat annoying manner: it could refuse the transaction the first time, then prompt the user, and accept the next transaction for the same amount).

This is how it works in a lot of places, including everywhere in China and parts of south east Asia. The merchant’s device displays a QR code, which you scan with your phone. The details of the transaction are shown on your screen, and you can select things like where the money should come from, sometimes discounts etc, and then tap to complete the transaction.

so that means that all payment methods must be stored on your phone? How is that any safer than Apple Pay or PayPal?

In the case of Bharat QR (India) or QRIS (Indonesia), it's just a standard which various payment methods implement. So you can choose to scan the QR with the app of the bank that you want to pay from, or with a mobile wallet app (those wallets themselves usually being able to be linked to bank accounts, cards, etc).

In the case of Alipay and WeChat Pay (China), the QR codes are proprietary to the mobile wallet app, but both also support connecting the wallet to bank accounts and cards.

When using a card the safety characteristics are quite similar to Apple Pay or PayPal: the card details are neither stored on your phone nor transferred to the merchant. But in these markets few people use cards; they either pay directly from their bank account using these QR systems, or they keep a balance in a mobile wallet and pay from that.

> You can blame the evil competitor but the real problem is that credit cards are not the right tool for payments to strangers over the internet.

Granted the entire system needs a revamp, but credit cards are one of the best tools we have to pay strangers right now. Credit card money isn’t your money being spent, and comes with a fraud guarantee. I would rather use a credit card than something linked to my money in a checking account for sketchy transactions.

Yes, it’s a hassle when the card number inevitably gets stolen, but NFC payments, etc are starting to tackle this.

One thing I’ve seen a lot is people misunderstanding credit cards. If you pay them off monthly, you usually get some kind of reward and additionally a huge layer of fraud protection from your personal finances. That being said, I also can’t wait until more secure credit card systems become more prevalent.

In much of the world, the "credit card" payment goes through a pre-paid card. Then you're actually putting your own money on the line, and even if there's a guarantee, it's a pain to actually go through the process of invoking it.

If this is one of the best tools, then I'm really dismayed at the state of payments around the world. SEPA bank transfers are so much better, even if they have other problems.

Define "much of the world", because that is absolutely not how credit cards work.

Paying with a credit card means your credit card company pays that charge for you. Yes, you are borrowing money from your credit card company.

Once a month (or whatever your billing cycle is), you receive a statement showing all the charges on your credit card. The statement will also show any credits if applicable (eg: refunds). The sum of all charges and credits is called the balance.

At this time, if you spot any suspicious or fraudulent charges on the statement, you call your credit card company as soon as possible to dispute those charges. If they are indeed fraudulent, those charges are reversed/removed.

If the statement looks fine, you pay your credit card company whatever balance is shown on the statement.

Note how your own personal money only comes into contact with the credit card at the time of paying off the charges on the credit card, and only after confirming the charges are legitimate. The credit card company has a vested interest in fighting fraud because it's their money on the line, not yours. This is why credit cards are considered safe and widely popular.

Contrast debit cards and banks, where all charges on your debit card come into contact with your own personal money immediately. Banks don't have a vested interest because it's your money on the line, not their's, so they won't be nearly as enthusiastic about fighting fraud on your behalf.

You’re definitely correct in how credit cards work, but I’d like to make one wording change:

> Contrast debit cards and banks, where all charges on your debit card come into contact with your own personal money immediately. Banks don't have a vested interest because it's your money on the line, not their's, so they won't be nearly as enthusiastic about fighting fraud on your behalf.

The credit card issuer may be a bank and for most new credit card holders, there’s a decent chance it is their main bank (e.g. BoA and Chase in the United States have many credit card products).

Also, with debit cards, the federal Electronic Fund Transfer Act does limit liability for the card holder.

Source: https://www.federalreserve.gov/boarddocs/caletters/2008/0807...

This is not how credit cards work, because the system of "credit card payment" is typically used with things other than credit cards. At least in Europe you go through extra expense and hassle to get a credit card, if you're even allowed.

If someone says "credit cards" to mean things that aren't credit cards, that's not really my problem.

Let me put it in another way: there's no "credit card payment system" for payments over the internet. There's Visa, MasterCard, whatever other "card" system. Those don't just facilitate payments for credit cards, but also for other kinds of "cards", which, in my experience, are no less common. Talking about paying by card over the internet doesn't make sense without considering that hordes of people don't use credit cards for that.

Is it? Last time my card was used in an unauthorized way, one phone call to the bank locked the card and had a replacement the following day, and I got a letter a few weeks later for me to sign to confirm it was a fraudulent transaction, that was it.

> you usually get some kind of reward

What kind of reward? I’ve always paid mine off each month and never gotten a reward on any of my ~15 cards.

cash back? airline points? I would say you must not be American but you said you have 15 cards so I don't know what to think.

I think it’s possibly your wording that had me confused.

> If you pay them off monthly

You get the things you mentioned whether or not you pay them off monthly or just pay the minimum and carry a balance. You just have to remain “in good standing”.

My cc number is useless without access to my bank account. The hacker would also need to steal my phone and bypass the fingerprint scanner somehow to get in there.

>One thing I’ve seen a lot is people misunderstanding credit cards.

Practically all the credit card haters turn out to not understand credit cards, it's almost hilarious. Are people not taught even the very basic of financial know-how from anyone?

> Why are we still using credit cards? It’s not great as a consumer either

Because the big networks (Mastercard and Visa) as well as the issuer and acquirer banks spend insane amounts of money on advertising and lobbying - even in the EU where payment fees are capped, the cap on CC fees is notably higher than on debit card/SEPA fees, so there is a clear incentive for everyone in the chain to push for credit cards.

Additionally, issuer banks make a ton of money on interest which means they have even more of an incentive to push for CC usage.

And also this reliance on a few payment providers causes the same type of problems as this business have with Google - big businesses trampling yours on a whim, with no real recourse. The problem is actually far worse with payment processors, who are increasingly taking it upon themselves to be an unelected worldwide morality police, deciding which types of commerce shall be legal with their own de facto law

I've talked about this before [0], but tl;dr - American banks operate worldwide, and since they are subject to US laws, worldwide banking is de facto under US jurisdiction.

> The banks operate under a laundry list of laws outside of a criminal conviction, such as the Terrorist watch list as well as whole countries that are under US sanctions. US sanctions are a particularly large bite because the US will sanction you from the US financial system for working with the above, even if you are not under US jurisdiction.

> This, of course, doesn't mention the all the reporting used for detecting tax evasion or money laundering.

> US banks are absolutely a wing of the court by operating under the given rule of law, and through the US banks' worldwide influence this 'rule of law' gains a global prominence.

[0]: https://news.ycombinator.com/item?id=28820330

Is it? My bank accounts in two European countries have in the last year transitioned from Visa Credit Cards to Vise Debit cards. Because the banks in both cases wanted about 2.5 euro per month for something that does not provide any value to me. Unfortunately Visa Secure seems to be changing its validation mechanism every 3 months though, which each time is super annoying.

CC in europe require a 2fa confirmation where you recieve usually a notice of the amount you're approving

This is not mandatory by law though and mostly it's up to merchant to decide whatever they require 2FA or not. AFAIK payment processors like Stripe actually let you make 3DS (and whatever it called for MasterCard / AMEX) mandatory.

I guess problem is that in US you'll lose a lot of customers by declining payments without 2FA. Also likes of AMEX use 2FA via email so I guess there could be fraud too.

It is required by law (the PSD regulation, specifically) in many circumstances.

CC in europe require a 2fa confirmation where you recieve usually a notice of the amount you're approving

How does that work when you buy things in places where you don't have cell service?

Yes, they exist. Even in Europe.

The SMS (or more likely, bank app) confirmation thing only happens for online payments – and if you don't have internet, how are you shopping online?

For payments involving the physical card, the chip on the card and your PIN are the two authentication factors required. (Credit and debit cards are PIN-based in the EU; signatures aren't a thing anymore there.)

I guess in those cases, something offline like google authenticator (or similar) would be better.

And how does the PoS machine work then?

In the edge case where there is no cell service yet the PoS device has connectivity (e.g. WiFi or other cellular service) they might set up a WiFi access point for users to get push notifications (assuming the 2FA method is not archaic insecure SMS).

Personally, I am substantially more suspicious of whatever random wifi network I’d need to connect to in this scenario than I’ve ever been with payment terminals out in the wild. There so, so much more attack surface on my phone than there is with my credit card - and resolving fraud on the credit card is as easy as a phone call to the issuer (at least in the US). No such luxury if my device gets pwned or networks are MITM’d or I’m associate to suspicious activity originating from this network.

While a random WiFi network isn't what I'd love to join too, at least it's an option for receiving a code through an encrypted channel (push notifications).

If that encryption can be MITMed, then there is a much bigger problem as any traffic can be MITMed at cellular network level anyway, voiding out any WiFi-MITM concerns.

The PoS asks for the pin in sales > 50e for 99% of population, you can change your personal limits but still

this is not sms 2fa/based but a physical/android based pos to charge the bank lends you

PoS can do offline transactions and sync them later, if the merchant is willing to accept the risk.

Card present and card not present transactions are differentiated.

It does work, though I am not 100% certain of how.

Something to do with having a “next authentication token” on your device already with a 24hr expiry.

You 2FA trough your bank app, SMS is too insecure for this purpose.

It’s not really a security concern, but SMS is only one factor (and EU regulations require banks to ask for two).

SMS fees outside the US are also orders of magnitudes higher – paying a few cents for that can make the entire transaction uneconomical for banks, since interchange rates are also heavily capped in Europe.

I have had too many phones land in water, then get bricked, then be unrecoverable. Then find that 2FA locked me out of key stuff. Like my Apple account.

I know that SMS is insecure. But I can get it back after a predictable disaster.

most 2fa codes you can store the qr seed you get into your authenticator app as backup code.

sms is trash yeah, 2fa just works if you care enough to know how (in most sites)

With my Apple account, I didn't even remember 2fa having been set up at all. And if I had backed it up, it would have been to a computer that itself had been replaced when it died. With the Time Machine archive having been corrupted and unrecoverable, so it would have been lost.

Today I've noticed the qr seed idea. But I'd prefer having my personal phone having access to nothing irreplaceable, and not worrying about it if it dies.

If I work in an environment that needs to be secure, then I'll worry about following security recommendations. But to whatever extent possible, I prefer not working in an environment that needs to be secure. And then not bothering with the UI disasters that secure solutions regularly impose on people.

> Yes, they exist. Even in Europe.

You mean you have wi-fi, but don't have cell service?

That is like... super rare.

It's not rare at all where I'm at.

I mean actually, I frequent a business where you cannot get a cell signal, but they offer free wifi. Metal building blocks the signal. This could happen anywhere.

Right but then you just connect your phone to the wifi? The following methods I have had for the 3DS card payments are (ultimately depends on the bank):

- Bank sends you a tiny card reader that you enter your PIN and it gives you a one time code. If you want to make payments that require 3DS (online only ofc) you have to have this card reader on you but it doesn't actually require an app or internet connectivity.

- You have an app on your phone, you drag a code from a notification onto another area of the app itself which does something (somehow - no idea the purpose) and verifies the transaction. Certificate is stored on device only.

- You open an app and it'l notify of the purchase amount, location, merchant and you just tap allow

- You receive a code in the mail that is renewed once a year which is then combined with a SMS message (or app notification). The payment flow asks you for some characters from both codes.

You do not require cell service for any that I have used and wifi is enough.

Further Edit: Just to clarify though, all of these are ONLY for online purchases. Purchases in shops you just use your pin if it requires authorisation.

Not rare at all. I grew up in such a place (well, before WiFi, but now it has WiFi and still doesn’t have cell service), and have lived in two other houses like this. On holidays I have stayed in hundreds of places like this.

I remember in Berlin going to a bar where there was no cell service (some combination of poorly sited base stations and thick walls made of something dense). They of course offered free WiFi considering this.

Where I am now, there’s a section of beach full of cafes that has no cell service. If you walk 100m north or south it’s fine, but that bit is a dead zone. All the cafes have free WiFi.

There's Wi-Fi calling, but unfortunately at least in Germany, many operators don't support receiving SMS over that, unlike the US carries I've tried it with.

However, most banks/issuers have since switched to using their app as the second factor, so all you need is Wi-Fi, practically.

A few even support displaying an offline code in the app that you can enter during checkout, but that's becoming less common since it doesn't support displaying the amount and payee given how it works.

I live in Edinburgh - buildings here are thick stone walls with lath and plaster on the internal surfaces. It's very common to have little to no cell signal indoors

We’re still using credit cards because they severely limit personal liability. Many CC companies give you the ability to have temporary cards with short term expiration linked to your account. However, there is minimal incentives for you to do so.

The credit card company and indirectly the vendors carry much off the cost of fraud. The credit card company spends a lot of resources on preventing this fraud. Introducing a proper solution for online payments would allow them to reduce costs and offer better deals to vendors and consumers. They also are the only participant in this who is a individual participant rather than a group. It seems like this is the ideal setup for credit card companies to introduce innovative solutions. They have the incentive and the leverage, yet it's not happening. What am I missing?

You are missing that the credit card companies want less transaction friction. If they wanted security we would have chip + pin in the US like the rest of the world. Charging volume overrides everything. Interest rates and those that carry a balance more than make up for fraud losses.

Strong authentication/payment confirmation and strong consumer liability protection are not mutually exclusive.

In the EU, card issuers and merchants are required to use 3DS for e-commerce payments and PIN verification for in-person payments in many circumstances; yet chargebacks are still possible.

We use CC because the infrastructure is there and there is legally mandated (depending on jurisdiction) fraud protection. When you pay with CC, the issuer is potentially on the hook for fraudulent payments, so they are incentivized to provide the protections.

And of course there are many that use CCs for the purpose of a loan to purchase items they can’t currently afford.

Although you're right that Apple Pay is cryptographically verified, you may be surprised to know these two things:

1. you can charge any amount - the amount shown in the Apple Pay UI is arbitrary

2. you can make multiple charges, also of any amount (e.g. for a subscription)

It is tokenized, but practically it's just a card number you can charge like any other card number. It's also typically linked back to the original PAN, so multiple payments can be correlated together with ease

Your payment processor and the network has to trust you if you're reusing the Apple Pay cryptogram for a subscription payment. You _can_ do anything (e.g. you can represent yourself as an open loop transit network reader and get a card number without any authentication from express mode cards!), but the network will not allow you to succeed doing that for very long, if at all.

> Why are we still using credit cards?

Because they're accepted by pretty much everybody and nobody has come up with a system that is any better.

A multi-cryptocurrency payment system would be the perfect solution for online payments but unfortunately nobody has figured out how to solve the double-bullet problem which stands in the way of mass adoption.

Central banks are preparing to launch the digital euro and the digital dollar. Cryptos had their chance and they blew it.

No, it's really not. As a buyer I don't want irreversible transactions to someone anywhere in the world, I want something that if the seller isn't acting fairly (items not as described, not shopping orders, etc) I can lean on to get my money back.

That's why 3D secure exists: https://en.wikipedia.org/wiki/3-D_Secure

Blame your government for not caring enough to have it implemented

I hate 3D secure, it's a way for banks to move the liability and inconvenience to me, their customers. In most implementation, I need to wait for an sms, often that sms takes ages to come.

Then there's a bit of a monopoly with 3d secure implementation by cardinal.js and their solution falls down completely if you have a decent amount of traffic on the site (I have worked on flash sales websites, cardinal js is about as reliable as I can throw my car)

Blaming certain government can get you banned not only from facebook but from real life altogether.

Reply on news.ycombinator.com