Hacker News new | past | comments | ask | show | jobs | submit login
Why we ditched PayPal for Stripe (gc-taylor.com)
382 points by gtaylor on Dec 8, 2011 | hide | past | favorite | 119 comments

The post is spot on.

My initial attraction to Stripe was because of a reason mentioned in the post: not wanting to redirect or otherwise interrupt the normal order process of my site with another company's (branded) checkout form just to handle credit card payments. The other reason for initial attraction was of course their elegant API, which was very refreshing to see after having dealt with Intuit's QBMS API (shudder) in the past.

Stripe really sealed the deal though when I tweeted them to ask my first question about signup and one of the co-founders reached out to me. Since then, I've been in contact to share my feedback or ask other questions, and the quality and timing of their responses is one of the best I've ever seen.

When a customer of ours had an issue placing his order, I wrote Stripe to see if they could offer any insight as to what errors they might be seeing on their end. While the error was unrelated to Stripe itself, they were so awesome that they actually took the initiative to browse through our checkout page and point out the spot that they thought to be the issue.

A company that stands beside you when debugging your checkout page, maintaining swift response times on an issue that isn't even theirs? That's customer support.

I probably sound like I'm gushing right now, but I just have mad respect for this company. The product isn't the only thing that's top notch, the people behind it rock too.

You almost always get amazing customer support from early stage companies. I'm certain people got amazing customer support from people high up at PayPal when it was just starting. You cannot judge a company on whether a co-founder responds to you on Twitter in a short period of time, and if you did, you should probably judge it negatively: I would wonder what was wrong with PayPal if someone that high up had enough time to be sitting around checking Twitter.

(edit: I typed this over too long a period of time, and some of this post appeared after I had already submitted a draft with the above paragraph that received some upvotes, so I've now edited again to add this edit paragraph to explain that everything after this point was added after I received said upvotes. ;P)

Also, I'm very curious about their API... I didn't see much information on chargebacks. Processors like Litle & Co make it very easy to fully automate the chargeback representment flow. PayPal, incidentally, does /not/ provide this either, but they do have APIs that let you (with only some hoops to get through bugs that I've filed with them, and we may see fixed fairly soon) correlate and track all of the chargebacks and how they relate to your transactions.

Yet, when Stripe first started appearing on Hacker News, their website seemed to have almost no information on chargebacks. I asked after this, and the page "appeared" with an apology that it was supposedly there but not linked, but it then had very little information on it. I still (checking again now) see no information on how I'd determine /which/ transactions had chargebacks automatically: they seem to seriously rely on sending an e-mail? Why does their API page never once mention the word "chargeback"?

That's somewhat a fair point, but I'll disagree.

In that instance, the co-founder replied, but I've heard from a number of Stripe's other employees since then, and in every case the customer support has been wonderful. Perhaps that's solely because they are still a startup, but given what I know now about the people themselves, I don't believe that to be the case.

I don't mean my original comment to suggest that the co-founder will always be the one to respond to a tweet as Stripe grows, but I do suspect that their standards for customer service will remain high, and someone in the company will give a quick and quality response. That said, with Stripe, I believe that–even if they aren't the ones responding to every tweet, which is admittedly much to ask–the co-founders will continue to have an eye on what people are saying about them and interact appropriately, not wall themselves off.

Edit to reflect your edit:

I remember that HN thread where you brought up chargebacks. For anyone interested, they discuss how they handle chargebacks here: https://stripe.com/help/chargebacks

I can't attest as to why they manage chargebacks that way, and will not speculate beyond the note that they are still new and seem to be developing their service in response to customer feedback and perceived needs.

For you, or anyone else who might be interested in requesting features regarding chargebacks or any other aspect of their service, I highly recommend writing in: support@stripe.com or https://stripe.com/help/contact. As I mentioned, they're very responsive, and seem to love the feedback.

I am curious if you've ever actually called PayPal. I have received nothing but high quality support from them. You can call them throughout most of the working day (until 8pm PST, I believe), and they seem to have somewhat knowledgable engineers available at that tech tier. They also have a merchant technical support site that seemingly no one knows about where you can often get answers in the middle of the night (I often get responses back at 12:30). If you are even reasonably sized you can also ask for a dedicated account manager: I have the cell phone number of someone at PayPal whose job it is to find me answers to problems I have.

Though, I cannot say PayPal is perfect. I have run into a bunch of annoying issues correlating settlements (bugs filed recently, will be curious to see if they get fixed), and their pricing is not the best that is out there (although is still better than Stripe). I am curious if you've looked into any alternatives. I've spent the last few days talking to Litle & Co, and I must say that the people there /love/ talking to you about payments... their booth at ad:tech was the most enjoyable conversation I've had about payments in a while, and I got to spend another half hour on the phone with them yesterday learning more about how bank ACH settlement works.

Edit to reflect your edit ;P

That is the page I just had gone and reviewed now. It still seems incredibly manual. I would not feel comfortable running a site at scale where I'm dealing with receiving e-mails in an undocumented (probably designed-for-humans) format as my only source of notifications for chargebacks. :(

It is often these "at scale" issues that are seemingly not handled by them; example: per their API page, Stripe does not resend webhooks if there is an error in the response... doesn't this make them useless to rely on? Am I required to sit around and poll my transactions to feel 100% certain that I didn't miss something because my load balancer accidentally gave them a 503 during some traffic spike? :(

I second that. I've had to call PayPal a few times due to integration issues and the people on the phone (all 4 I spoke to) were beyond kind and helpful.

Unfortunately, everyone is coming out the woodwork now to get their two shots in while PayPal is down.

Telephone support is not an adequate substitute for sane API design and good documentation. Or, for that matter, electronic forums where I can write complicated questions and get complicated responses.

In this thread I provided a few specific areas where Stripe's API seems downright primitive: no way to do chargeback reconciliation ("chargeback" isn't even in their documentation anywhere, which should be an immediate red flag), and a "webhooks" model that does not retry on server failure (meaning you cannot trust you will actually receive the notifications, and will have to rely on polling them for updates). Is there something in specific you did not like about PayPal's API?

I will be the first to say there are warts, but the warts are really far down in the trenches (I only noticed them after using them for years; I did my initial PayPal integration in less than a day): Stripe seems to be missing important things upfront.

Also, I am confused what you mean by "electronic forums"; do you mean like an online ticket site? I have filed numerous tickets against PayPal, and they have always been answered within a few hours during the day; they even have people available to respond to integration issues in the middle of the night.

I haven't integrated Stripe, but I have integrated WePay, PayPal, Google Checkout, and Amazon Payments into various applications.

WePay's API is very well designed and easy to understand. The documentation is blissfully short and effective. When I had technical questions, a post to their email list got me a detailed response within hours (and usually within minutes). Honestly it's the best developer support experience I have ever had with any product in my 16 years of professional software development. I hope it lasts.

All three of PayPal, Google, and Amazon suck, but I will honestly say that PayPal is probably the worst developer experience I've had in that same time period. And this was for a very simple implementation of a single product one-time purchase.

1) It took hours to figure out what product I wanted. PayPal's product assortment is a trainwreck. What the hell is the difference between Web Payments and Web Payments Pro and Adaptive Payments and about a dozen other things with idiotic names that all sound the same. The chart that tries to help you pick a product is useless.

2) The layout of paypal's website is labyrinthine. Even after I figured out what product I needed, assembling all the relevant documentation was hard.

3) The documentation is flat-out wrong in several (rather important) places. For example, the IPN guide (naturally, a PDF https://cms.paypal.com/cms_content/US/en_US/files/developer/...) on page 9 clearly states that you must explicitly post back messages to paypal to get them to stop sending (which is retarded and screws up transactions), but HN says that this is not the case. You can see my venting about this almost a year ago here: http://news.ycombinator.com/item?id=2341119

4) Posting a technical question to PayPal's forum gave me an unhelpful response from a clearly first-level "read the flowchart" technical support rep. Pointless exercise.

5) PayPal's APIs all feel like they were designed in the 1990s. Seriously, I would be horribly embarrassed to publish an API like that. I put more thought into (and produce better documentation for) my opensource projects. Useless crap websites like Foursquare can come up with solid APIs, there's no excuse for a company that handles actual money to be this janky.

It's vogue to hate PayPal because they really horribly suck. And now there are good alternatives. So I say, let them rot. WePay costs a little bit more but it is worth it not to have bit scary parts of my codebase that I dread going into.

If you are the kind of person who cares about whether the validation closes the IPN retry so you can come up with a reasonable strategy for handling your database transaction policy (which is a good thing: people should care this much about everything they do), then Stripe's documented policy should be a non-starter, as it seems to indicate there is not going to be any retry at all if the request in any way hits your server: "Stripe ensures that webhooks are sent successfully but does not attempt to re-send webhooks that return errors in the response."

WePay's retry policy at least exists, but only retrying three times total, with those three times only spanning a single hour of attempts, is kind of bothersome... I have totally had outages that affected some random load balancer for an hour in the middle of the night: PayPal will retry for something like four days, and has a mechanism to "force flush" the notifications as your infrastructure comes back online.

Honestly, all of these APIs are not that great. Amazon's API, for example, does not let you get the shipping address. They return it as part of the co-branded UI return, but that request to your server, at scale, will sometimes be lost in transit. When the user goes back through the payment process, you are encouraged to look up the existing token the user succeeded in authorizing by CallerReference and then continuing the payment, but that means the shipping address is not sent, and you can't query for it. You can, however, get it via IPN, but if you find some silly bug in your code that drops an IPN's incoming shipping address (but returns a successful result), you are simply screwed and have to talk to the customer to recover the shipping address for that transaction.

Looking more at WePay, I again see the same thing I keep harping about regarding Stripe: I see no mentions of chargebacks. Doing a "site:wepay.com chargeback" search using Google I find their terms of service, but nothing in their API documentation; and omg: their terms of service regarding chargebacks is the worst I have so far seen... $35 ding and your account seems to immediately be put on hold and goes into account review? For a single chargeback? WTF.

Hey Saurik, Just wanted to say that we're aware of the (significant) flaws in the webhook APIs. We're in the process of redesigning them now, so thanks for the feedback on what is important to you.

(Also, just FYI, you can see logs of all the webhooks in your Stripe account, including the response body and response status code, and they can be retried with a button click -- a manual process, yes, but it is at least possible)

I don't understand your PayPal IPN rant at all (I designed IPN; it's not perfect but it works pretty well). PayPal POSTs payment details to you. You capture those details, post them back to PayPal as-is and PayPal tells you if they are valid or not. Pretty simple. Of course there is a unique identifier: the txn_id. And because the validation step is a simple hash that doesn't hit the DB, it's very performant.

The rant was about the retry algorithm, which (from reasonable interpretations of the documentation) seems to "clear" (for lack of a better term) the IPN during a successful "response" (the term used in the PDF), but where a "response" seems to be defined as the verification step, not the HTTP request returning a successful status code.

If this were the case (and it seems from other responses to the rant that it is not, but honestly the documentation seems to read as if it is), then it would not be possible to both verify the validity of IPN requests /and/ guarantee that the information is safely committed to one's database.

In essence, and to explain, there are really only two options: either my server commits to my database before or after I perform the verification.

If I do it after, then I might fail (for whatever reason, let's say out of disk space), but will not get a retry of the IPN as I already cleared it.

If I do it before, and the verification returns "invalid", then I have to attempt to undo what I did to the database, which might not be possible, or itself might fail.

Instead, IPN needs to (and I am under the impression from the responses to the rant that it does) clear the IPN retry if the entire request succeeds, allowing for verification to be separate: you first verify, then commit, and finally return a successful HTTP status code to clear retries; here, if your commit fails, you will get another attempt.

I still don't totally understand the issue. If your commit fails you can return a "500 error" which will cause the IPN to retry.

I can see how the validation step might be confusingly described. For what it's worth, the validation step merely compares a hash of the variables to confirm the authenticity of the IPN. It doesn't touch the DB at all.

The reason you don't understand the issue is because it is implemented correctly, which is why I kept pointing out the responses to the rant that indicated he was wrong about how it actually worked (to make clear I understood this, apparently failing ;P), and kept adding the parenthetical hedges about the documentation. Really: you nailed it, and the PayPal IPN mechanism works great (seriously: no sarcasm).

The rant really was just about how he perceived it working based on what I do feel is a reasonable reading of the documentation (and in fact I think I originally had that interpretation myself until I actually tried it in practice): that the documentation lists the "response" as the verification process, and does not seem to have any provisions for "500 error": again, though, the way it works is fine.

You are being far too generous regarding the documentation. Here's the relevant part:


The IPN protocol consists of three steps:

1. PayPal sends your IPN listener a message that notifies you of the event

2. Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message

3. PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your listener must respond to each message, whether or not you intend to do anything with it. If you do not respond, PayPal assumes that the message was not received and resends the message. PayPal continues to resend the message periodically until your listener sends the correct message back, although the interval between resent messages increases each time. The message can be resent for up to four days.


This is clear, unambiguous, and - if what you say is correct - just flat out WRONG. My misunderstanding wasn't just "a reasonable interpretation", its the only reasonable interpretation. At the barest minimum, competent documentation should state "PayPal will attempt to resend messages until your handler returns a 200 OK http status code." It doesn't. Anywhere.

This is a perfect example of why working with PayPal is an unacceptable developer experience. And who doubts that one year from now this document won't have changed one bit?

It's not the best wording but doesn't necessarily imply that the payment is dependent on handling the IPN, just that the retrying is affected by the handling.

But it is unforgivable that there does not seem to be any mention of what response the PayPal server is expecting to indicate that the IPN has been successfully caught.

Never said it was. I've complained about PayPal's API documentation just as much as the next guy.

I'm simply referring to the fact that most arguments over the past week have revolved around PayPal's technical support teams and the service that they provide.

Should they simplify their API and provide documentation that's 1000x better than what they have today? Yes. Am I going to act like the other 1,000,000 on the web right now screaming about how shitty they are? No. It's a brilliantly run company that needs to improve on somethings.

People need to grow up these days. Not you specifically stickfigure, but people of the web. No one is constructive anymore. People just want to vent and vent and spew rhetoric.

I have called PayPal once before. The experience wasn't horrible, but it didn't leave me enthusiastic like Stripe's does. I'm not holding that against them though: it's only one mediocre experience, and I have not used them much because of the whole payment redirection thing (I did not know about their Pro account then).

To be clear: I'm not actually saying that PayPal is bad. I don't have enough experience with them to weigh in one way or the other. I am merely saying that I do like Stripe.

I'm not sure of Stripe's reasoning behind not resending webhooks, but I don't know that I care for them not resending them either. Perhaps this is something they'll be addressing in the future or otherwise have a legitimate reason.

I have called PayPal once before. The experience wasn't horrible, but it didn't leave me enthusiastic like Stripe's does.

Well, talking of facts small companies with a small customer base will always deliver better customer service than the larger ones. True test of these companies will come when their subscriber and customers run into millions(In paypal's case hundreds of millions).

Imagine a situation where where 283 million registered customers and probably more unregistered buyers. Ensuring operations related to that magnitude of people work fine for 99.99% of the people, 99.99% of the times. And then ensuring the remaining get appropriate customer support is not just difficult but requires a lot of work to maintain and run.

At that scale the founders will have a lot more different work to do. And addressing one user out of those hundreds of millions by communicating them on twitter might not scale properly. And the customer support employees are working in call center shifts. They are not going to be any more enthusiastic any more than other general call center employees.

Coming to arcane policies, Now for all those millions of users. There are definitely going to some x% of crooks out there gaming the system. Frankly speaking if you don't have such policies you may actually end up putting a lot of your other buyers and other customers in trouble and expose them to fraud. The problem is in programmatically handling hundreds of millions of users and their problems is not easy. You can build a system to do payments et al, but that's only beginning. So any good payment gateway etc will ultimately end up looking like PayPal.

PayPal works at a scale, Whether a new competitor will work at scale is question of time.

But don't write PayPal off, It actually works well for those hundreds of millions of registered and more unregistered users.

Either way, Stripe is the best solution at this moment. If Stripe ever ever becomes big and bloated like PayPal, hopefully a new startup pop up to compete with them.

Agreed. You have a low bar if you are impressed with co-founders helping you out. That is obviously only a figment of the service being tiny.

> I'm certain people got amazing customer support from people high up at PayPal when it was just starting.

Can you imagine what that could have been like?

Customer: yeah I've having trouble accessing the purchase history

Support (Elon Musk): you need to twiddle the such-and-such.

Customer: tried that. can you escale to your superior?

Manager (Peter Thiel): can I help? I want to make personally sure you have a great experience. Also, avoid college. I'll pay you.

If only Stripe were available in other jurisdictions.

Stripe, please come to Australia!

Doubleplusupvote on this one. Although I'm wondering if I can still use it if incorporated in the US.

No you can't unfortunately, you must have a US bank account :( I tried that already

I hear it's something that they're working on.

You can sign up at https://stripe.com/global to be notified when they do come to your country. I bet that also gives them a priority list.

> maintaining swift response times on an issue that isn't even theirs?

But the problem is theirs. Their site says it all:

"No setup fees, no monthly fees, no card storage fees, no hidden costs: you only get charged when you earn money."

Therefore, if you're having an issue with your checkout form and their API, it very much is their problem. You're not able to process payments, so you're not able to get paid. Because you're not getting paid, they're not getting paid.

I don't even think the "Why?" of good support matters, from our (the user's) concern, as long as the support is there and fast.

Technically, PayPal depends on people sending payments through them to draw profit, as well, but that didn't get us good support.

The big takeaway from the top of this thread is: Stripe's support was fast, even when it wasn't necessarily their service that was causing the issue. Why they came to the rescue fast doesn't really matter.

That's a huge stretch. It would be like claiming that an engineer at Google should email me whenever my website goes down and help me fix it because, if my website is down, then it's one less website in their index, and they need sites in their index in order to sell advertising.

To make sure that I'm clear: the problem was entirely unrelated to Stripe; it had to do with a different component of my site.

> not wanting to redirect or otherwise interrupt the normal order process of my site with another company's (branded) checkout form just to handle credit card payments.

That's a restriction only for the free accounts.

With the Pro account ($30/month) you use the API and your customers never leave your site.

But doesn't that API require you to submit the card number to them from your server and hence makes you have to do a ton of PCI compliance work?

Require? No.

Unless you do more than 20k CC transactions/year, OR store CC numbers directly on your server, no one is going to require much of anything from you except one of those fake website scans.

Right, there's always the option to just ignore PCI and live with the possibility of being fined if something goes wrong. But you're right, that's not always a big risk.

Would like to know more about this- i thought the whole point of it was that you didn't have to deal with PCI...

Edit: i just checked; https://www.paypal.com/pcicompliance

It looks like Paypal takes care of PCI compliance only if you use; PayPal Website Payments Standard, Email Payments, or Payflow Link. Otherwise you're on your own.

It's common sense once you boil it down to this:

If someone's credit card number hits your server at any time, you are liable for a proper level of care for that information. The proper level of care in this case is set by the payment industry in the form of PCIDSS (the Payment Card Industry's Data Security Standards).

So setups where the data goes through you, you're on the hook.

Where you're sending someone to an external site to pay, in a frame or otherwise, then you're not.

A quick glance at the implementation guide for any payment system, present or future, is enough to know who's on the hook for PCIDSS just by seeing whether the card number's gonna get POSTed to your server or someone else's.

I think the better description would be:

You are on the hook as soon as your code touches credit card data.

Is this true? I was under the impression that if we used Stripe's javascript function to tokenize credit cards, we get to skip a lot of PCI compliance stuff we would otherwise be responsible for.

You might want to talk to your PCI QSA to get a professional opinion. My views are explained here:


Said that, you might want to think beyond PCI. Security is as strong as your weakest link and you might want to "play" in your mind a few scenarios: what if there is an XSS attack? what if your employee goes "rogue"? what if your server is hacked? Then you will need to decide what is important for you and how much risk you are willing to tolerate. Different solutions (Stripe + javascript, WePay + iFrame or redirect, PayPal, traditional payment gateway, etc.) will give you different upsides and downsides in usability, security, international support, price, customer support experience, ... There is no silver bullet :)

I used to work as a low-level tech for one of the largest PCI compliance providers. For smaller merchants (I think less than 20k? transaction per year) there's 4 levels of compliance: A, B, C, and D.

A is for merchants who redirect to another site or use an iframe (like paypal). B is for merchants who use a dial up terminal. C is for any merchant who accepts credit card information electronically (i.e. an internet connected terminal or a website with no redirect / iframe). D is for anyone who stores credit card information.

A & B just require you to fill out a self-assessment indicating you're aware of the rules and following them. C & D both require "scans", probably of your website or server (at least a couple hundred dollars, if not more).

I am not familiar with A/B/C/D levels but PCI spec clearly defines PCI 1-4 levels based on volume/number of payments:


Ah, yes. What I'm talking about above applies to level 4 merchants, (less than 20k ecommerce transactions), who can get away with lower level compliance. The ABCD levels refer to the self assessment questionnaires (SAQ) these level 4 merchants are required to completed.


I guess I never bothered to look at anything below level 1 :)

Thanks, I wasn't aware of that.

Edit: I was looking at it more and, as MichaelGG pointed out, I think it still means that you have to handle the credit card on your server and be PCI compliant.

The better question would be "why wouldn't you ditch paypal for stripe?"

Stripe is much easier to integrate than the x.com/paypal.com family of conflicting api's, all of which lack easy to read documentation.


Compared to


Stripe doesn't have a history of randomly locking accounts, and even if they do (if you process payments, I can understand the legal need to now and then) their customer support is so responsive and helpful I wouldn't really mind.

Stripe is easy to use. The web UI is fast, the api makes sense, I get joy out of it.

Stripe sent me a real, physical letter, to thank me. I was one of the early users of the beta, and we all got real letters, on thick cardstock, I wish I had taken a picture of it. That may be a virtue of being a small userbase startup, but if you start with that mentality, it means a lot.

Paypal does have slightly lower fees, but Stripe is worth it.

Paypal also makes it easy to add a paypal pay button to sites, but those a fraught with stories of accounts shut down, and are ugly.

I was one of the beta users too–I showed the letter to my co-founder and we both got huge smiles on our faces.

Here's a picture of it: http://yfrog.com/nz99532600j

I can only see two reasons why someone might need PayPal rather than Stripe: if the business resides outside the US, or if they need to take methods of payment other than credit cards. Other than that, Stripe seems like a no-brainer.

Josh, you are failing to recognize other reasons why a business might still consider using Paypal as their merchant account provider. Here are ours:

1) Costs. We pay 2.2% + $0.30 USD per transaction vs. Stripes' 2.9% + $0.30 USD per transaction. At our transaction rate, that makes a difference in received revenue.

2) Moving. Refactoring a well established business to interface with a new payment provider can be a costly and expensive process. Think of switching personal banks.

3) Fraud. Paypal probably has the most advanced fraud protection in the online business today. If you deal in any decent amount of online payments you will find this to be a huge issue.

Additionally, we have our own dedicated Paypal account manager that actively reaches out to us and keeps in contact, and we can instantly call a direct line to this person if we need assistance with an issue.

With that said, our team is actively looking at Stripe because we like the ease of use when it comes to reoccurring payments, which we don't do at this time but plan to implement in the coming year. From what we see, reoccurring payments are a messy with Paypal and I'm not satisfied with Paypal's solution compared to their competitors like Recurly, Chargify, and, well, Stripe. But I am impressed with what Stripe has to offer on all fronts. Especially their API which appears to be very easy to use. ...And, they have a nice looking reoccurring payments process which fits our vision nicely.

Anyway, disclaimer: we run between 50K and 100K a month through Paypal, so that is probably why we get fantastic support from them and better pricing.

I'd love to use Stripe, however the 2.9% fee is a total deal breaker. I'm currently using Payflow Link (by PayPal and Verisign) and I pay a flat rate of $20 a month plus 500 incl monthly transactions. I can get more at 0.10 per transaction. And after that it's all done with my Merchant account, which I've been able to negotiate down below 2%.

When you're doing hundreds of thousands of dollars (or more for you big guys) in credit card transactions, eating 1% just for a friendly API is a huge turnoff.

Please Stripe, prove me wrong and provide an external merchant account option!

I'm the lead API engineer at WePay, so I'm definitely biased toward the WePay API, but I do think Stripe is a great service.

The WePay API does allow you to embed the entire checkout experience on your own site with our iframe checkout. The iframe contents are customizable (header color, button color, etc), but as Greg mentions in the comments, it's not quite as customizable as Stripe or another merchant account based system.

Unfortunately, even with Stripe, you are still liable for most of the PCI spec (our iframe checkout gets around this). We made a bet that there are a lot of developers out there that who are willing to give up a little on the customization side to not have to deal with the headache of PCI compliance (we've gone through that process ourselves and it is complicated and expensive).

Out of curiosity, how does an embedded iframe let you avoid PCI completely and an external javascript lib not?

The external javascript library is still being loaded on a page served from your domain, so it's totally possible for you to grab the credit card data and ajax it to your server (or for an XSS vulnerability to allow a 3rd party to send it somewhere). Since the CC info is accessible to both the client and Stripe, both are liable for PCI compliance. [edit: just to be clear, with stripe, you aren't liable for all of the PCI spec (just part), which is one of the awesome things about the service]

With the iframe, the checkout form is served from WePay's domain, so javascript on your page can't directly access elements on the checkout form. There are still potential vulnerabilities such as clickjacking (we do some things to protect against this), but since the CC form is served from our domain, only we are liable for PCI compliance.

We at Stripe (and more importantly, our PCI auditors) don't agree with this assessment of how the chain of responsibility works.

When you use Stripe.js, you need only serve your page over SSL and verify that you aren't collecting credit cards through other means to be PCI compliant.

We don't do PCI assessments (I have a generally low opinion of the process), but we do the "real" appsec work for lots of companies that do, and the impression I have is that --- counter to what you'd expect --- 'boucher is right, and you can self-assess using their interface, despite the fact that anyone doing so is in fact an XSS flaw away from giving up cards.

In particular, while I have no idea whether Stripe's implementation is letter-of-the-law PCI compliant, I do know that 'LeBlanc's reasoning is not PCI reasoning (particularly: you can't draw a line from architectural susceptibility to "liable to audit") --- even though it's the reasoning I myself would use.

Interestingly, PayPal actually offers (or offered?) an iFrame checkout for some customers and it was confirmed to be PCI-compliant. But again, another PCI auditor might have another opinion on it :)

Paypal actually offer a Embedded payment experience which in no sense gives the feeling of embedded payments on the website. https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&c...

On this link you can find the experience of Embedded payments, i implemented it on our site but the docs on the api are not complete on paypal, rather complete they are not present at one place.

(PayPal Digital Goods for Express Checkout in fact uses an iframe.)

Disclaimer: I work for WePay and I am directly responsible for WePay's PCI audit process

I am sure everyone would agree that PCI spec is complex and not easy to understand :) Said that, its intention is pretty clear: protect credit card information from leaking to "bad" guys.

A great deal of PCI spec is about protecting the stored credit card data. You are absolutely correct that Stripe's JS solution allows one to avoid dealing with these issues. However, many other sections of PCI spec discuss other potential vectors of attacks. For example, if you don't follow security coding guidelines then an attacker can embed a malicious JS on your website (through XSS or other attacks) and steal credit cards information. Obviously, the suggestion to serve your pages from SSL don't help you to avoid these problems.

I think Stripe's model is great. But I don't believe that it allows one to completely avoid PCI compliance. I believe that you correctly phrased it on the stripe's home page: "Stripe.js lets you build your own payment forms while still avoiding most PCI requirements."

I guess you could say Stripe gives you the shotgun, but you have to decide whether you want to use it properly, or blow your foot off.

So basically: Be smart about what goes on your sensitive, mission-critical payment-receiving pages, as you should be. It's not extremely difficult. A little bit more responsibility in turn for more flexibility.

Someone already said in this discussion that PCI compliance is a legal term :) To some degree, it is a deal between you and your QSA (or you again if you are doing self-assessment). I heard about a few businesses that accept credit card numbers w/o bothering to do anything about security at all. You will need to decide for yourself the acceptable risk for your business in various "things gone bad" scenarios and how much you want to invest in protecting against scenarios that are bad for your business.

We've designed WePay solution to make it "out-of-the-box" as secure as possible for both our partners and WePay. We plan to offer more customization options in the future to improve usability while keeping it simple and secure to use. Doing security right is hard. We believe that WePay can help with it and make our partners life easier.

This seems like a risky compliance hack to be relying on. While it might conform to the letter of the law[1], it absolutely does not comply with the spirit of PCI compliance in regards to securing cardholder data.

There's literally no security difference between processing the card transaction through your own servers, and processing it client-side via HTML/JS that your servers are providing (and can modify).

[1] I wouldn't have thought this would meet compliance requirements, but I'm not a PCI expert -- I've only had to work on compliance on the user side, and deal with the auditing requirements.

Sorry, I should have made it more clear that with stripe you aren't liable for all of the PCI spec (I edited my comment to reflect that).

Either way, I think Stripe is doing awesome work and I hope you keep kicking ass!

With this same argument, could I not use the JavaScript I inject into the site (via XSS or whatever) to replace your entire iframe with a different iframe (hosted off my corrupt and evil server) that looked identical to yours? I don't need to access elements of the checkout form: the key problem with an iframe is that the user cannot tell what the URL of the iframe is to do basic verification of where the page is being served from.

What about a script injection to rewrite the DOM and create a mock WePay iframe that's actually loaded from a third party server?

There is no good reason for any of these backdoors around PCI, except for the fact that everyone knows it's not going to be feasible to "test"† every website anywhere that does any commerce.

It's probably best not to ask too many questions. It'll only hurt your brain.

(If that's what you want to call PCI assessments)

Another thing to keep in mind is that PCI scope and PCI requirements expand with every iteration, so today's backdoor may be gone tomorrow.

PCI compliance is ridiculous enough that it's still worth avoiding though, even if only for the short term.

I don't really consider Stripe a replacement for PayPal. You don't accept PayPal because it can process credit cards, you accept PayPal because millions of people want to pay with it. Don't get me wrong, I hate PayPal just as much as the next guy, but unfortunately it isn't a viable option to stop using it in favor of simply accepting credit cards right now (though Stripe is an awesome product!).

From the consumer's perspective: I don't want to give some random website my credit card info, but I'm OK with them going through PayPal for the checkout step.

I definitely understand the privacy concerns, and myself use PayPal for a lot of things. However, I think the need for it depends a lot on your audience, and the nature and reputation of your site.

We are fortunate enough (being new and in closed beta) in that our audience knows who we are and that we're not a random sketch site. Down the road, we probably will have to support PayPal again (though very differently), but for now our current state (closed beta) and our business model allow Stripe and traditional payment gateway-only checkout.

With that said, I will put a huge "YMMV" here! This is obviously not OK for every site, and the privacy concerns are very valid.

Very true. Here's another example:

My wife sells knitting related things (patterns, books, yarn) on ravelry.com. They collect the payment for her and transfer the money to her paypal account. I suspect it will be a while before stripe can do such a thing.

If ravelry.com used WePay, each time someone bought one of her amazing works of art, the money would be deposited directly into a FDIC insured account that your wife controls.

From there, your wife could transfer the money directly into her own regular bank account.

If ravelry.com goes out of business before they transfer the money to her paypal account, there is no chance that they can take any of her money with them. (While highly illegal, I've seen this happen elsewhere with a similar setup.)

*ravelry, not raverly

Fixed. Thanks. Must be my old school raver roots. Heh.

raver you say? Do you know of any good bay area raves?

This is a good point. PayPal has moved beyond being a mere payment processor. There are a lot of shoppers (10s of millions at least) who actively prefer paying with PayPal.

agree, I'd like to know conversion numbers after the switch.

It's still really early going, but we've seen some new patterns. For example, we had a customer enroll in four different courses (we help schools offer online courses) in under five minutes. This -never- happened when we only offered PayPal.

Our current enrollment process is so fast and simple with Stripe that we're curious to see if our conversion rate is -better-, for our current audience (older, non-technical users at this point). While a $30-$90 course isn't an impulse buy, lowering the barrier to enrolling in more than one may leave us better off.

But we'll be able to discuss that better after we have more data.

From what I understand, one of the differences between WePay and Stripe is that WePay allows marketplace transactions where the app creator can take a cut of the transaction (similar to Paypal's adaptive payments API). I don't believe that Stripe allows marketplace transactions. WePay doesn't currently handle the dunning process for recurring payments but they plan to do so at the beginning of the year. Stripe currently handles the dunning process. At Bellstrike, we use WePay's API and have had nothing but good things to say about them. Their customer service is outstanding and we always have access to their developers, usually within minutes. We're getting ready to implement their iFrame solution as well. I've talked to some others that are using Stripe and they are pleased - particularly with the fact that Stripe only requires the credit card number and expiration date for a transaction - no other info. I guess it just depends on what you're looking for but I'd recommend WePay from my experience. We had a terrible time with PayPal.

I too heard lots of great things about WePay. They seem like a great shop.

As you've noted, there are some differences in feature sets on both sides. However, perhaps there will be some convergence in the future. Both services are very young, and improving very rapidly.

Both WePay and Stripe are US only.

https://www.wepay.com/Does-WePay-allow-international-non-US-... https://stripe.com/help/faq

So for now, I am stuck with Paypal.

I'm starting to think though, that it's a good opportunity for others in other countries. Stripe, Twilio, Google Voice, probably a bunch of others.

I would love to be able to use stripe instead of PayPal, can't wait until it's available in the UK.

Unfortunately they don't even have a timeline for availability outside of the US yet - http://twitter.com/#!/stripe/status/144951134795218945

WePay doesn't require you to redirect them to their site.


Perhaps "redirect" wasn't the best word to use. WePay does interrupt the flow of your site with their own system, however:

"The iframe checkout lets you embed an iframe on your own site that will contain the WePay checkout system."

With Stripe, we have 100% control over presentational stuff during checkout.

Sure, if you want that level of control. In my case, I was happy to not have to implement that part of things. It isn't a trivial amount of work to deal with the credit card / address forms and get everything correct. I made the iframe look like a part of my site well enough that people can trust it and it saves me a ton of development time.

Your app appears to be in private beta, so I can't test that form to see if you missed anything and post about it here. ;-)

hey guys - bill from wepay here.

we contemplated building a JS solution as well, but using JS can place your site within the scope of PCI compliance. (this is somewhat up for debate) the reason we went with an iframe implementation is because it is firmly outside the scope of PCI, and we are working on making it even more customizable.

either way, you are in good hands with stripe or wepay. (at wepay we are big stripe fans - they rule!) to me, the big difference is whether or not you want the money to settle to someone's bank account directly (stripe), or whether you want it aggregated and stored in an online account first (wepay).

I feel like I am becoming a ridiculous Samurai supporter in a world of Stripe supporters on HN (odd because we know they have many large customers), but my large (seasonal business, 8-figures a month for 5 months a year) contract employer chose Samurai last month and we've been very pleased. We still are splitting our transactions between them and another provider but we've been very satisfied w/ Samurai thus far and will probably migrate all of our transactions to them over the next couple of months. They have an amazing API - can do the stuff referenced in the above article... See: https://samurai.feefighters.com/developers/samurai-js and were fantastic to work with. They also have a campfire room that is usually staffed and helpful

I ended up choosing them for my non-day-job gig as well (saas business) and am very happy. Happy that both of these services exist, really.

We switched to Stripe from Paypal and Google Checkout a month ago and so far I've been very, very pleased. I plan to do a writeup of why we switched soon - wanted a bit more results first. FYI, Stripe launched a new web interface 2 days ago.

The net bottom line was this: 1. our customers (business people who are not super tech savvy) just don't understand that you can pay with a credit card on paypal and google checkout requires a google account 2. the "go off and pay" somewhere else and come back to the main site is messy

I have no real complaints with paypal over the years we used them so I can't bash them but I found that over time, we lost sales because people were confused. Now there is no more confusion - fill in a few fields and instantly you are done.

We also considered Braintree which I was also impressed with but decided on Stripe because of the non-need for a merchant account.

I am happy to answer any questions here or privately if needed.

Stripe does provide you with a merchant account (https://stripe.com/terms). They just make it a simple process by asking for as little info up front as possible. There's advantages to this such as a quicker sign up process. But the disadvantages are that you may have issues if your company grows too fast, if you get too large of a transaction size or a host of other risk issues. Your best protection against these is giving the bank the option to perform a thorough underwriting. Disclosure: I work at Braintree.

I work at Stripe. This is pure FUD. If fast-growing companies really did encounter problems with Stripe, don't you think at least one would have talked about it?

BTW - I made a post about the switch for us: "Moving to Stripe: Fixing the Biggest Mistake I’ve Made to Date"


"We investigated some traditional payment processors like Braintree and Authorize.net ... A lot of traditional gateways have long, complicated setup processes, often involving sales calls and working with banks. ... They also typically require you to send credit card data through your servers, which means obtaining a level of PCI Compliance (not that we aren't already security-conscious)."

I've used both of these. Braintree may not have been the right choice in their situation, but grouping them with Authorize.net for these reasons isn't really fair. Braintree's bundled merchant account and gateway services are much easier to set up, and their transparent redirect eliminates the need to handle card data on your own servers.

And in my experience, their "We (heart) developers" motto is, well, true. They have really great, friendly support. Braintree and Authorize.net are miles apart. At least as far apart as Stripe and PayPal.

The usual gripe - my company is based in New Zealand, and it's well nigh impossible to open a US bank account so we can't use Stripe or Wepay. I'd love to know how many of PayPal's merchants are non-resident, it's the only reason we use them.

In fact, if it wasn't for PayPal non-US websites selling to the US would be almost impossible. The US has a massive advantage in that the rest of the world is happy to pay in US dollars, but US citizens won't pay in other currencies.

So here's a very lucrative challenge, Stripe and Wepay: the one that figures out how to allow non-residents to set up an account first simply has to post the news to HN and will be flooded with new accounts. I'd switch within 24 hours if there was a viable alternative to PayPal.

In tepid defense of US customers - even US banks can't really figure out foreign currency. We went to the bank in Bloomington, Indiana to exchange some Euros we had laying around and they literally had no way to handle them. The best they could offer was to mail them to American Express. Or drive to the airport in Indianapolis. And this wasn't a local bank, it was Chase Manhattan's branch in Bloomington.

We ended up driving to the airport in Indy. No way am I just going to put a few hundred Euros in cash into the mail.

Yup, i'd switch to either Stripe or WePay- tbh, being based in Canada... Stripe/WePay guys make it seem like we're foreigners o_O

More positive news about Stripe since the last time they were posted on HN. http://news.ycombinator.com/item?id=3053883. I will give them a try on the next e-commerce project I work on.

I hear you. However I would like to point out that the two PayPal services I designed 10 years ago, Web Accept and IPN, continue to work in the same way they did a decade ago. I was fanatical about not breaking and not needing to version.

Can anyone recommend something similar to Stripe or WePay for Canadians.

Please come to Australia; I'd love to use Stripe for new projects.

I'm eager to try stripe myself but it wasn't right for our business due to the transaction costs. We do anywhere from a quarter to half million per month in transaction fees and it's amazing how those fractions of a percent and one penny turn into thousands of dollars! We looked at losing about $20k per month so it didn't make sense.

But I have a generic payment processor API that I wrote and I plan to add support for stripe into that for personal projects.

Redirects are a good idea. Redirects mean that you don't have to juggle legally sensitive credit card data yourself, and your customers see a browser indication that they are talking to the genuine Paypal (or whomever).

Paypal sucks, blocks your account and keeps your money on the least excuse, and is a bureaucratic hell, those are good reasons to not use them. Redirects aren't, IMO.

You don't need to choose between safety and no redirects. One of the major points of the article is that you can not touch the credit card data yourself, AND still get a 100% uninterrupted payment experience for the user.

Again, it's still early, but we are seeing better conversion rates so far. The PayPal redirect gave some of our less technical users fits.

So how exactly do you replace Adaptive Payments with Stripe?

I'm probably missing out on something here.. I know that flaming PayPal is popular nowadays but I can't find an alternative with both Authentication and Adaptive Payments (which our app is completely based on)

Can someone explain why Stripe doe not allow marketplace transactions but WePay does? Is this primarily due to issues of fraud? If so, how does WePay get around it?

Sounds like one of the main advantages of stripe is the API.

I wonder if anyone is working on making payments platform-independent so it's easy to switch between payment providers.

Most of the gateway-style services operate very similarly. We wrote some abstractions to allow us to eventually add Braintree or Authorize.net, since the payment cycles are much alike (from the API perspective). It only gets difficult when you try to mix-and-match something that uses redirects/iframes with services that deal directly with credit cards from your server to theirs.

We just don't want to get into PCI audits and scans just yet, but once we do, we'll probably use Stripe's direct server->server APIs like Braintree/Authorize.net do instead of stripe.js.

Why on earth Europe doesn't have something like Stripe or WePay ?? This is such an amazing opportunity, and I can see lots of people who would invest in it.

Dealing with all of the banks, currency, and laws sounds like an absolute mess. Each country does business differently.

US only. The only reason I hate living in Australia.

Or the UK. Bane of my existence.

We should setup a payments service that works everywhere, except the US. Revenge ... kidding. Although given how dodgy the PayPal APIs are and that future economic growth is likely to be based outside the US, it might be a very viable business.

Sigh. another great looking payments service thats only available in the US. doesn't anyone want my ruples?

I'm not enough of a developer to integrate completely with stripe, but we've been making the change to Dwolla.

Anything is better than PayPal. I appreciate their contributions to epayment, but their time has passed.

Other great options out there include Square, MoneyBookers, and Dwolla (if anyone is looking to leave PayPal after this article and the recent Regretsy one).

I was absolutely enthralled with the support I received in their Campfire chat.

You may want to also consider SaaSy.com: - All-inclusive – hardly any development work needed - More functionality - GUI-based for the most part - Global tax/VAT management - Works with vendors in most any country - 10 currencies - 20 languages - Best customer service experience of your life

To be perfectly honest, this is pretty far from the discussion. SaaSy looks expensive, and their website isn't even clear enough to see if they offer the redirect-less single payment checkout.

I'm assuming this is just a shameless plug? Nothing wrong with that, but it looks like you don't even have the feature set the original article is discussing.

Edit: Oh, I see what's going on: http://news.ycombinator.com/threads?id=fastspring

I cannot recommend Stripe enough. We will be posting a blog post about our (seamless, instant) transition very soon. Kudos!

EDIT: By seamless, I mean "Sign up and get an API key", and by instant, I mean "Read this article, sign up, instant activation, plug in API keys, start charging, switch complete!"

Why you'll be losing a lot of business

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact