Hacker News Reader

Comment by analog31 | Hacker News Reader

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.

View on HN

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.

This. Entirely.

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.

> (you can generally trust PayPal)

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.

PayPal have certainly had a few screw-ups. My personal favourite: when they locked $750,000 of MineCraft sales money. http://www.escapistmagazine.com/news/view/103385-PayPal-Free...

At a glance it seems software products are now covered - https://www.paypal.com/il/webapps/mpp/ua/useragreement-full?...

Card-readers are “trust your bank with information security” black boxes.

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.

> Card-readers are “trust your bank with information security” black boxes.

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.

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.

[0] https://stripe.com/us/payments

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

That is mostly how Apple Pay works. The one-time hash happens to be a transaction-specific credit card.

There are also banks that provide virtual credit cards that can only be used by one merchant and where you specify the max amount and expiration date.

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

It's 2018 we should be generating these on the fly from my encrypted 2FA phone app instantly.

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.

You do, if you use Apple Pay or Google Pay.

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.

There's ApplePay, which provides a very nice experience (if your customer is using Safari :( )

There is payment systems being standardised in browsers at the moment.

https://www.w3.org/TR/payment-request/

Google Pay follows this standard. Apple Pay has a similar, but Safari-specific, API.

not sure if this is an obtuse cryptocurrency joke, or you didn't realize you were describing cryptocurrency...

> If a company is not a huge name

Not to be snarky, but a huge name is no guarantee of safety. See: Target, Equifax.

Even eBay itself (PayPal's parent) had a major password hack in 2014.

However, the advantage of PayPal is that I can buy from multiple websites while only needing to trust one entity with my credit card information.

If trusting one entity can already be insecure, having to trust dozens of them is nuts.

Parent didn’t say that. You assumed the converse.

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?

But these problems don't exist if you use a service like Stripe. You never ever store any confidential customer information on your own servers.

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.

Nope, it's designed so that the card details never touch the vendors server. They don't see it to be able to store it.

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.

Ebay presumably doesn't have this problem though... they are large enough to be trusted on their own...

It just takes one malicious ad on the payment page... and the tempation to shove ads into the face of every customer and his dog is big.

Think about java updates and a certain antivirus product as a great example of insane greed :)

eBay itself had a major password hack in 2014.

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.

I like the ease of use of pay pal, but the redirect is a pain point for sure. Occasionally I'm not sure if I've actually purchased something.

Best way to integrate with stripe is to use their checkout button to get a token instead of receiving CC info directly.

Iirc, still need to use backend code to do the actual charge, but at least you never see any sensitive info.

Right, but the poster is saying they don't want to run a server AT ALL.

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.

Couldn't you run a more static based site if you don't have to run some PHP code though?

I was just using php as an example. See stripes documentation for more info:

https://stripe.com/docs/stripe-js

https://stripe.com/docs/charges

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.

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

IMO it should be like this, in favour of the buyer.

What do you sell? Or maybe put in profile?

You don’t need any of that. For a small shop an email from the payment processor with the customer’s name, address, and order details is all you need.

No lambda, backend, or database necessary.

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.

The idea is that they want their god-given chunk of that sweet transaction margin, not hand some proportion of it over to PayPal.

Then they should have kept PayPal as a subsidiary.

Ha! Nothing like improving the bottom line.

Adyen actually provides this too, it's called Hosted Payment Pages (HPP)[1] and it's difficult to find because the documentation structure is abysmal.

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

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.

> scrpt scr=paymentproviderscript.bla?

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.

This is already possible via iframes, check out braintree payments for example.

Most third-party payment gateways I've worked with are like this.

They usually offer some kind of "pay links" or something similar.

How's visa checkout? War under the impression that it was a direct PayPal competitor.

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.

That’s very different from PayPal’s offering.

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.

Does Stripe Checkout not fit the bill?

https://stripe.com/checkout

Stripe Checkout still requires server side code for the Stripe checkout form to submit to.

Stripe checkout does this

Reply on news.ycombinator.com