Here's what puzzles me. I have looked into Stripe, and just browsed the Adyen webpage. Both of those services seem to require you to maintain your own "active" server that can run server side code.
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.
The reason for processing on your own server is so you own the entire checkout experience. If you redirect he user to another site for payment, you run the risk of losing track of that user. Also, the third-party’s branding may clash with your own.
Going to a well known third party is a guarantee that my payment data isn't sitting in a poorly secured vendor database. That's more important to me than a seamless transaction. PayPal is most useful when you don't fully trust the site you are buying from to have their shit together.
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.
This. I wish there was a fundamentally different way of handling payments. Something like a one time hash you give the vendor that serves like a digital check(cheque). This way, if they lose the hash they lost their money instead of the customer's.
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.
> I wish there was a fundamentally different way of handling payments
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.
"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.
Many online payment processors have integrations that don't require card information to reach the merchant's server. For example, if you use Stripe[0], the merchant only receives a token that can be used for API calls. If you use Apple Pay or Google Pay, regardless of payment processor, the merchant receives a transaction-specific credit card.
You can do all of that with Adyen, however if you run a shop which people only buy from once in a while, e.g. garden sheds, then you would not have value in the token, therefore this is not a common feature.
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'.
I could be wrong but I think this is how Apple Pay is supposed to work. (Though a non-proprietary version of this would be fantastic, but this is a baby step I suppose.)
Yeah, but that's like buying a gift card for every merchant. That's a huge inconvenience. I can't buy one for every small website I want to buy stuff from..
This is a reality in many places already. On the internet I never input any real card details, I go to the app, generate a virtual card with X amount available or for one buy only or for a single merchant for Y amount of time and use the generated card details instead.
Isn't 3DSecure like this? If properly implemented (a giant if, there), the query to the payment provider would happen using client-side Javascript, so your credit card data doesn't touch the shop's server. Then a 3DSecure window from your bank pops up so you can confirm the payment.
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.
The problem with 3dsecure is that it's still driven by the merchant. If you see it, you can be pretty sure they're doing something right, but if you don't see it then you've just given them your payment details and have no recourse.
Many just don't turn it on because it's another step and they don't have issues with fraud, as well.
And why would that matter to me? I've shopped online at small (and large) vendors for 20 years and I've never experienced fraud. Even if I did, the CC company covers it, don't they?
Stripe was just getting big as I left for a job in edtech so I never had a chance to work with it. Excuse my ignorance but does it require you to send your card info to the vendors server rather than directly to stripe? If that’s the case you are still wide open to basically every form of bad handling.
Just because a vendor doesn’t NEED to store your CC doesn’t mean they’re not out of sheer ignorance or incompetence.
That's not how Stipe and similar services work. They exist to prevent your scenario. They actually work very similar to Paypal except that you don't have to be redirected to the Paypal site to enter your credentials. Instead you get a small "secured by Stripe" widget that takes the credentials (directly to Stripes PCI compliant servers so that yours don't have to be).
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.
I see a possible problem with that statement: starting from a poorly secured sellers site, users can't really be sure if he ends up on the real PayPal page anyway.
You and I and the rest of the HN crowd are concerned about this problem, but the rest of the world doesn't even know that it exists. I wonder what real world bounce rates look like for PayPal vs InsecureCart.
The third party branding can also be positive depending on your own brand trust.
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.
Since when does checkout needs to be an "experience"?
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.
Checkout has been an experience for decades. The candy/magazines by the checkout line in your grocery store are now ads on the cart page. Amazon even promotes using a specific credit card in some cases: Use Discover to save 5%, or Save 10% when you get an Amazon Visa.
It also puts you squarely in PCI scope which is a massive burden. I believe many of the modern payment processors offer embedded iframe solutions these days where they handle the sensitive bits (card and CVV#) but allow you to style the payment form however you like.
to an extent yes. There is another lever, PA-DSS compliance which is less stringent than full PCI-DSS compliance because you aren't actually storing card data on your servers, they are just passing through, or pages that collect them are being rendered by that server.
From a user perspective, I wouldn't trust a site that uses it's own payment processor, unless you are Amazon, Ebay etc. Double that if you ask for credit card details. Redirecting to a well-known payment processor (PayPal etc.) guarantees that I can pay safely.
>
From a user perspective, I wouldn't trust a site that uses it's own payment processor, unless you are Amazon, Ebay etc.
"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.
Then what are they running their website on? This is a perfect example of the infectious nature of the word cloud, people say the word cloud as if there's no server still running it!
Oh noes, I have to run php code stripe has done all the work on and provided to me! Scary!
There's a big difference between running a server that does basically glorified inventory tracking, and running a server that hosts (even just a wrapper around) payment infrastructure.
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.
Working with Stripe and PayPal are essentially the same if you use best practices. Stripe can do the payment page and redirect if needed and can also capture paying info from a static page that is submitted via JS in the background. In the end you'd get a simple token that's just a reference to the payment details in Stripe (just like PP). If you integrate with the Stripe payment page then they will even remember you across sites (again, just like PP) and you won't have to input payment details.
If you use Stripe, you still need a server to make secure API calls to charge the card. The card is not charged until you make an API call with the token.
Not sure I follow - you mentioned not handling browser compatibility which implies you're not directly writing
the html/css for the site. If you're using shopify or hosted wordpress or something, I would think
most of those providers would handle the Stripe integration for you?
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.
I'm using Google Sites. Previously, I wrote plain HTML, but just the most basic sort, that most browsers will typically format into something readable, even if not beautiful.
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.
Wouldn't small time eBay sellers just use whatever payment processor eBay integrates with? (there's no need for them to host any part of the payment process since the transaction is conducted entirely on eBay). Reasons to not use the default processor would be : transaction cost.
You might want to take a look at https://www.everbutton.com/. It basically wraps Stripe’s API so you can drop front end JavaScript without any backend code. Much more customizable than PayPal with all of Stripe’s benefits.
I think the idea is that eBay doesn't want to have users sign up with Paypal anymore. Instead only ever interact with eBay, with Adyen just being the pipes for eBay.
i agree it's actually kind of bad that payment providers don't provide this page. todays technology could even render it on the webpage of the customer shop without redirecting fully to another page (scrpt scr=paymentproviderscript.bla? or so?). If people have to maintain and host their own script it makes them horrible prone to attack. In which case i'd rather have a payment provider who needs to secure it than every customer of the payment provider (reduces attack surface). i think paypal does good by providing this passive system and other providers should follow it, and perhaps if it's not to their liking innovate in this line instead of dumping their issues to the customer shop.
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.
I can't speak for how it is now.
However: the implementation for developers was so bad that they offered my company $200k to integrate it into our site and we STILL lost money on the deal.
No, Visa Checkout is a confusingly named product that only serves to send credit card data to a merchant’s servers. The card data isn’t even kept safe by a intermediate token; the merchant has to run a PCI compliant solution.
I'll take a look. Thanks. If nothing else, offering two payment options would be good for the very small fraction of customers who have had a bad experience with PP for whatever reason.
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.