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.
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.
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).
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.
The point you mentioned probably makes this a non-issue in many cases though:
> 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.
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.
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.
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.
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.
How does that work when you buy things in places where you don't have cell service?
Yes, they exist. Even in Europe.
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).
this is not sms 2fa/based but a physical/android based pos to charge the bank lends you
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.
Something to do with having a “next authentication token” on your device already with a 24hr expiry.
I know that SMS is insecure. But I can get it back after a predictable disaster.
sms is trash yeah, 2fa just works if you care enough to know how (in most sites)
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.
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.
You mean you have wi-fi, but don't have cell service?
That is like... super rare.
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.
- 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.
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 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.
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.)
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.
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.
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.
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.
What kind of reward? I’ve always paid mine off each month and never gotten a reward on any of my ~15 cards.
> 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”.
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.
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.
> 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...
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?
And of course there are many that use CCs for the purpose of a loan to purchase items they can’t currently afford.
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...
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.
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.
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, only the PSP ever actually sees it. And yet, if you were to shop on any of our retail partners, you would still have the impression that you are giving the merchant your number.
Could a non-PCI-compliant merchant ask you for your credit card number? 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 integrate with the 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. 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? 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.
> 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.
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.
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.
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.
> 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.
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.
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
> 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.
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.
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)
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.
What stops a business from doing the same thing?
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.
Merchant doesn't pass your information to the PSP, you are actually talking to the PSP directly.
Always made me nervous... are they writing it down? Typing it into their home-made software?
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.
(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.
Blame your government for not caring enough to have it implemented
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)
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.
> 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.
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
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.