I used to work for a small ecommerce webdev shop. I’ve worked on sooo many shitty insecure shopping carts over the years I simply know not to trust basically any small website asking for my card. Completely unencrypted, storing CVVs, sending CC details as GET parameters, I’ve seen it all. It’s painfully common!
If a company is not a huge name, and is handling your credit card info themselves, they are mishandling your credit card information in one way or another. I guarantee it.
Having been through PCI compliance, it’s no joke. It’s really not worth doing yourself in my strong opinion.
Handing a merchant credit card details "feels" like handing them a blank Check and trusting them to not take more than they should because of the risk of them losing the data.
Edit: The digital hash should say where money comes from, to who, for what purpose, time, auth code and so on.
I live in Denmark, and they have a system of phone banking here called "Mobile Pay" it works kind of like that. Where you transfer money to the merchant public phone number and show them proof of sending.. However it only works for in-person payments where you can swing your phone to show.
Seconded. At the risk of simply rephrasing everything you just said:
It's a pity the banks and credit card companies just refuse to innovate.
When I buy something from an online vendor, they should never get my full card details. PayPal ameliorates things (you can generally trust PayPal), but really there should be no need for PayPal. The banks/credit-card companies should provide a convenient way to authorise the payment, in a way that doesn't trust the vendor.
Here in the UK, we already have chip-and-pin, and card readers (the kind that show unique numbers - they're used for online banking), but we're still stuck with the trust-the-vendor-or-use-PayPal model for online payments.
Using card-readers for online payments would also help with credit-card theft.
I agree, but I also have a counterexample:
"Oh, you bought SOFTWARE?? All those pretty marketing pages about our amazing safety and protection system do not apply to virtual products. We agree this vendor totally screwed you over, but it's not our problem."
(this was a few years ago, may have changed)
edit: It eroded my trust in the company completely. I don't really have an opinion of their technology.
At a glance it seems software products are now covered - https://www.paypal.com/il/webapps/mpp/ua/useragreement-full?...
If their online banking password policies are anything to go by — Halifax and especially Nationwide — then very definitely no thankyou.
Nationwide asks you to set three pieces of memorable information. You can then log in with any 1 of those 3, at your option. https://onlinebanking.nationwide.co.uk/AccessManagement/Logi...
This seems obviously stupid to me, but I'll accept that Nationwide knows better than me if HN says so.
Well of course I trust my bank. No escaping that. The point is not to have to trust the vendor.
> online banking
I wasn't suggesting a payment system based on signing-in to online banking.
Your complaints about online banking security may be valid, but aren't the same issue.
Adyen works with your shop no matter how PCI compliant and well-built, so you can have it in the checkout or the separate payment page. Interestingly you can also pay by paypal via Adyen.
I have found the online login bit for merchants to be as flaky and naff on Adyen as other payment gateways of yesteryear - forever timing you out and not letting you in, just really bad UX as banks seem to prefer.
I don't see these blockchain based payment systems as fundamentally solving anything in online payments needed for ecommerce, the Adyen tool kit is pretty large and bits such as the 'token' are not needed in real life, or some of the stranger mobile payment solutions that also promise to change the world as much as the crypto-coin 'promises'.
The alternative, telling the user to manually go to their bank and generate a token for amount X, would lead to so many people not bothering, and to so many lost sales. Or copy-paste errors, because users are dumb.
Many just don't turn it on because it's another step and they don't have issues with fraud, as well.
Google Pay follows this standard. Apple Pay has a similar, but Safari-specific, API.
Not to be snarky, but a huge name is no guarantee of safety. See: Target, Equifax.
If trusting one entity can already be insecure, having to trust dozens of them is nuts.
Just because a vendor doesn’t NEED to store your CC doesn’t mean they’re not out of sheer ignorance or incompetence.
As a reply you'll get some kind of token that you can use to actually charge the credit card (or SEPA, or whatever else).
It's a secure way of handling payment without the "we're now redirecting you to some payment site" which BY THE WAY Paypal themselves offer in the form of their Braintree payment services.
Think about java updates and a certain antivirus product as a great example of insane greed :)
Made numerous payments to shoddy businesses in SE asia the last month, but since most offer PayPal as payment provider I feel confident entering my CC number.
I'd much rather trust Paypal than a company worried about losing track of me or that I might see a different branding.
That different branding is the very reason I'm doing the transaction in the first place: I trust Paypal way more than any company's self-hosted checkout.
"etc."? That leaves a lot of companies where you potentially do business. Note that the size of the company isn't necessarily an indicator that the company knows how to safely handle payment information.
Iirc, still need to use backend code to do the actual charge, but at least you never see any sensitive info.
Oh noes, I have to run php code stripe has done all the work on and provided to me! Scary!
If my inventory service breaks I might have some pissed-off customers or have to re-ship some items, the odds of getting in bigger trouble than that are low. If my payment infrastructure goes down or gets compromised, the odds of lawsuits or federal/financial-org penalties are way higher.
So sure, you still probably have to have a "server" somewhere (you could probably make a fully static site for a merchant using third-party payment links, javascript, and mailto links or something--think "email as database"--but I suspect this would be neither featureful, secure, nor reliable), but the difference in what you need to maintain/serve is huge.
You also mention a passive web page, if you're talking about a static site (as in a jekyll or hugo site hosted on S3), you may be right. I don't fully understand how that might work since if you're accepting payment for a service, presumably you also need to keep state somewhere to track the delivery of that service to users and such. But if you did want to accept Stripe on a static site, I would think you could use Lambda functions in AWS to handle the callbacks without worrying about the maintenance costs and security risks of running your own linux server.
You're right, I mean a static site -- one that cannot run a server side script.
At its most basic level, you can pay me by going to PayPal and telling them to send money to my account. PP takes your credit card info. I get an e-mail, and my PP account shows a log of transactions. Then I click on "create shipping label," and it creates a shipping label (USPS or UPS) to the customer's address.
At a slightly higher level, PP will generate a "add to cart" button in the form of HTML that you paste into your web page. But it does the same thing as sending money to my account -- it just looks a bit more professional and maybe less confusing.
This is for a gadget, but for enthusiasts in an area where people are not typically tech savvy, and don't feel put off by a site that doesn't look professionally maintained.
Edit: I should note that despite seeming sketchy, a lot of trust is built into PP's buyer and seller protection policies. If I try to screw around with you in any way, PayPal will happily reverse the transaction.
And they will also happily reverse the transaction if you don't.
No lambda, backend, or database necessary.
There's a shared secret you can use to verify the payment when they callback to you after payment, and their HPP is skinnable.
[1] https://docs.adyen.com/developers/api-reference/hosted-payme...
They can't do this because then the untrusted merchant has access to everything again. It needs to be sandboxed in a separate page so that the customer is talking directly with the processor, with SOP, cors, https, and simply not being able to intercept PII and payment information.
They usually offer some kind of "pay links" or something similar.
That’s very different from PayPal’s offering.
PayPal seems to be unique in being able to take payments from a passive web page, because the customer conducts their transaction at PP's website.
This is why I continue to use PP for my tiny little business (without eBay). Even though I consider myself reasonably tech savvy, I don't trust myself to maintain a website that is compatible with everybody's browser, phone, etc., and that guarantees the security of their personal data. Moving to another payment processor requires a quantum leap in technology that I'd rather not keep up with. I'd rather design another gizmo.
From time to time I look around for an alternative to PP, and haven't found one yet. I suspect that many small-time eBay sellers may be in the same boat.