Stripe cofounder here. As this news breaks, I want to say thanks to the HN community. Stripe is in large part the result of the feedback and advice we've received here since we launched on HN back in Sept 2011 -- https://hackertimes.com/item?id=3053883.
Seeing this comment makes me realise how much of a crazy technical risk I made choosing to use Stripe when I did.
My company started charging for things in April 2012, but I made the decision to use Stripe months before that, something like January 2012. Only 4 months after you launched!
We only did 1500 transactions on our launch day, yet at the time it was enough to break your service for a little while due to load. Your customer service at the time was really great and you refunded all the transaction fees for our launch day and gave us a list of all the customers who had tried and failed to make transactions so we could contact them.
I don't think I realised at the time how small you guys were. We are lucky that you guys didn't fail, and I doubt that the me of today would have relied on such a young company. Certainly we could have moved to a different payment processor, but losing all the saved card data would have sucked a lot.
Large companies tend to have arbitrary size requirements for potential vendors before allowing them to become an approved vendor. But I think companies should consciously choose startups as vendors for precisely that reason. Startups care more about figuring out what it takes to make customers happy.
Hope to see you guys update the web interface a bit for a performance/little more flexibility. The API is great, but the web interface could use a bit more love :)
Awesome :) One big issue (with actual effect on revenue of your users) you guys could solve better would be handling delinquent/expiring cards better. We had to built some things in house to deal with this on our end, as once you have a non trivial amount of paying customers it can become at least a small pain. I know there are webhooks for failed payments etc but this stuff is really difficult to surface in the web interface.
Hey Alex, Churn Buster (http://churnbuster.io/) is available via Stripe Connect to solve exactly this problem. We're in private beta right now, so please email me at andrew@churnbuster.io if you'd like to take it for a spin. We've got a number of paying customers already (including some folks who previously had their own basic webhooks integration) and they're all saving much more in rescued transactions than they're investing in the product. Also, it's a 30-day free trial, so you literally can't lose! :-)
Sure, glad to give feedback, though this would make sense if you're familiar with using stripe. Our team is of course not one of Stripe's larger users, though we do use them enough to fall under one of the volume discounts. Here's a few things that I can think of from the top of my head:
When selecting a user to change the plan, the modal takes about 3-4 seconds to populate the new plan dropdown. The new plan dropdown is like 200px wide, which makes managing multiple plans pretty cumbersome.
The main dashboard view only has Gross Volume, with no way to switch to other views (ie, no way to take into account refunds)
Event view is pretty cumbersome for managing things, as it shows only 20 events at a time. Also, event filters apply to all of customer payments, not one ( so going to filters resets whatever customer you were looking at )
Logs are labeled with non human readable things like "200 DELETE /v1/customers/cus_2fdyjF3lV1FYyc/subscription"
There's no dedicated "Name" field for customer details though there is a name field that lives under card details.
>When selecting a user to change the plan, the modal takes about 3-4 seconds to populate the new plan dropdown. The new plan dropdown is like 200px wide, which makes managing multiple plans pretty cumbersome.
I agree with this. I was wondering "What Stripe UI improvements?" because I am largely happy with the UI (very much so, actually). But there are corner cases that could use some tweaking. This is definitely one.
The main dashboard could have some more information, or could be customizable, I agree. Not high priority for me but would be nice.
Not ridiculously easy, rather slightly easier as the merchant still must maintain aspects of their environment covered by the PCI DSS as they are still delivering Stripe.js from their server environment. Here's a bit more information on that:
This post is inaccurate. (Check out Darragh's response in the comments.) It's also worth noting that 1) Stripe and its processes are audited every year (we're a PCI-certified service provider), and 2) that MasterCard has actually followed a very similar strategy with their Stripe competitor.
Stripe's level one service provider which is independent of the merchants PCI compliance. The merchant is presenting the form for which the user enters their credit card information from within the context (same origin) of their domain: e.g., https://merchant.com/payment... As a result, under the PCI DSS they are obligated to protect that component of the transaction because if they don't a criminal could change it so that the card data doesn't POST to Stripe.com but instead goes to the criminal. Implementing a bit of Javascript and enabling SSL/TLS is far from all that is needed to be PCI compliant as a merchant so long as the payment form itself, whether delivered via an iFrame or a bit of Javascript is hosted within the merchant domain.
(Stripe Developer) - tl;dr -- This claims that Stripe.js runs on the merchant's server environment, causing the server to be subject to PCI DSS. In reality, Stripe.js is served from Stripe's servers, and runs only in the browser, and this has always been the case.
In order to get Stripe.js to execute within the same origin of the merchant environment the merchant must include code like this: <script src='//stripe.com/Stripe.js> within their HTTP response. This can be modified by a criminal on the merchant server to go to <script src='//badguy.com/mystripe.js> if the merchant has not implemented proper controls as outlined in the PCI DSS. The same can happen if they implement weak crypto. At the end of the day the merchant is responsible for this PCI related component because it's executing within the context of their merchant domain.
Adding a bit more to be crystal clear here. The merchants customer will only see the address in the address bar for the merchant and will be able to validate the merchants public cert. No customer I know of would view the source to make sure that the reference to Stripe.js is in the source.
Additional edit to address Silhouette's point. Yes, an attacker can modify the <a href to go to their site as well, but unlike an embedded script the customer does have a chance to call BS and back out of the transaction after growing concerned by the domain transfer & doing a Google search to see if it's legit. They don't have any chance in the case of an embedded script. Now if we go back to my original concern, it's that merchants are being told that they simply need to implement Stripe.js & enable HTTPS. Modifying that statement to something like this would be far better:
"Stripe minimizes the scope of PCI DSS by removing the need to implement and audit security controls surrounding the transmission, processing, and storage of card-holder data. This does not; however, absolve Merchants from compliance with the PCI DSS & in order to assist with that we offer the following..."
This can be modified by a criminal on the merchant server to go to <script src='//badguy.com/mystripe.js>
And then the merchant won't be following one of Stripe's two basic rules for staying PCI DSS compliant any more, will they?
That aside, of course you want to keep your server secure. But if you can't, as a matter of practical security and protecting cardholders in the real world, how would it be any better to have your site intended to transfer entirely to a payment service on their own domain rather than just loading JS from that domain? An attacker who has compromised the security of the files on a merchant's server can change an <a href='...'> that should transfer to the payment service so it goes to a hostile site just as easily as they can change a <script src='...'> that should load JS from a payment service so it loads JS from a hostile site.
I started building a SaaS for the legal industry around 2004. It was very small targeted at specific industry. Back then it was very hard to get everyone on board to use Credit Card. I ended up automating everything (including the monthly billing sent directly the user's inbox), but because of difficulty of payment gateway processing (getting a merchant account, parsing the authorize gateway code)
And since I was a one man shop, I just had my users to send me checks at end of the month. I was not the best organized person back then. So let's just say there were quite few uncashed checks. Really wish Stripe was around them.
If it were only so easy. I guess there's no need for the merchant to have a PCI program, properly implement SSL/TLS, have anti-virus, change default passwords, protect agains SQLi, XSS, command injection or any number of other flaws which would give an attacker access to modify the Stripe.js code or the DOM for the page used for the collection of card information within the merchant's same origin. Nope, none of this is necessary because Stripe says that a merchant only needs to use HTTPS & implement their Stripe.js to be PCI compliant.
It's interesting that this isn't how the PCI council sees things:
Hm, it looks like that support forum answer needs to be updated -- we actually support filling out PCI SAQs right from our dashboard (and automatically ask users to do so). We'll go update it.
Also, if you'd like to drop me an email at patrick@stripe.com, would be happy to chat about PCI more.
Instead of just down voting this post, it would be helpful to know what specific parts of it are incorrect. This is the first I've heard of these objections.
These posts are probably being downvoted because they come from a new account, which has been attacking Stripe repeatedly in multiple discussions now, including making some assumptions/claims that are readily confirmed to be false (and are obviously so to anyone who's actually integrated Stripe) and citing supporting web pages that don't necessarily support the claims made.
While the PCI compliance issue may not be quite as simple as Stripe's documentation has previously implied, nobody else seems to be able to identify the kinds of serious compliance issues that patcheudor keeps implying we're all suffering from by using Stripe and following their existing advice.
I am simply pointing out that unlike what is covered in the Stripe documentation, a merchant is not absolved of PCI compliance by simply implementing Stripe.js in their HTTP response & turning on SSL/TLS. The PCI DSS and related materials cover this fact quite well. This "dispute" if you could even call it that came about when Pete Keen inadvertently also over simplified the compliance issue in one of his posts, for which he has since rectified:
I think the downvotes have to do with what is a pretty serious accusation and not apparently backed up with facts. What would be helpful is if the accuser produced a better description of what he feels is out of compliance, wrong or misleading.
Because the PCI guidance isn't factual enough? An essay could be written about the problems with broad statements like merchants only needing to worry about the inclusion of Stripe.JS and the use of HTTPS to be PCI compliant. Luckily those already exist. This one covers it pretty well:
That article is wrong on the technical implications, like "It may be their code, but it is executing on your server" (cc data is sent directly to Stripe's servers, never touching your own).
That was maybe not quite the right language, but is easily salvageable. What the author was trying to convey is that the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant. The actual credit-card form is delivered by the merchants server & therefore they own all the PCI DSS related controls surrounding ensuring that the payment form code delivered via their HTTP response is secured. If instead of referencing Stripe.js, the merchant instead sent the user directly to https://stripe.com/payment... and the user could validate they are at stripe.com by looking in their address bar & checking the SSL/TLS security by clicking on the lock then that's a different story and the merchant would have far less exposure to the requirements outlined in the PCI DSS.
I appreciate your interest in the security of Stripe, I think we definitely share the same goals here (making everything as secure as possible). However, I think there's some misunderstanding in some posts (and in the blog post):
> [...] the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant
When Stripe.js is included within the user's browser by a (mandated https, not http) request, it comes directly from Stripe's servers, not from "the server infrastructure owned by the merchant."
Stripe.js isn't served from the merchant. It comes directly from Stripe. Stripe.js helps keep payment card data away from a merchants own servers.
Keeping card data away from someone's machines doesn't mean that they don't need to comply with the Payment Card Industry Data Security Standards, but it does make things quite a bit simpler.
In most cases it means that they're eligible for one of the light-weight self-assessment questionnaires.
PCI compliance, of course, shouldn't be where people stop thinking about security though. You're absolutely right that if the pointer on the merchant's site is changed to a malicious site, that's where the payment data will go. The merchant needs to keep that pointer safe in the same way that if you're redirecting to a hosted payment form or elsewhere, you need to make sure that isn't tampered with either. (A hosted form has the advantage that at least a customer can view the SSL cert but if they don't recognize the domain (or if the domain is obscure anyway), that's not much good.)
Being compliant with the PCI standards is important but it doesn't cover all of the very, very important points of web security.
We do take security very seriously, and if you happen to find a valid security issue with our service, we pay bounties[1] for properly disclosed vulnerabilities.
If you have any other questions, or would like to wax poetic about security or PCI please don't hesitate to send the security team an email at security@stripe.com or to email me personally at alex@stripe.com.
Alex, thank you for your response. I don't think my original observations about the wording of a support doc falls into a vulnerability disclosure. That doc has since been updated with enhanced guidance which addresses my original concern. As I think we all understand, the merchant must be responsible for ensuring the integrity and security of the HTTP response containing the reference to Stripe.js. After that they are absolved of the requirements surrounding the transmission, processing, and storage of the card data. As the PCI DSS states, they are ultimately responsible for their PCI compliance as the merchant.
My understanding by reading patcheudor's responses is that the issue isn't with Stripe's PCI compliance, but rather the fact that merchants that use Stripe's API need to be fully PCI compliant. According to him, using Stripe's API doesn't obviate the merchant's need to be fully PCI compliant, unless they do something like open up another window where the URL clearly shows that they are inputting a form from Stripe's own servers. Otherwise, the merchant needs to conform to full PCI compliance.
This is my reading of his comment too.. more specifically, that since the page comes from the merchants server, the page could be modified by an attacker to alter the form to (for example) submit credit card details to another server instead of Stripe's.
I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since it never reached the point where Stripe could protect it).
> I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since it never reached the point where Stripe could protect it).
Yes, this is certainly true. This is why we also use the dashboard to ask the relevant questions from the PCI self-assessment questionnaires. https://support.stripe.com/questions/do-i-need-to-be-pci-com... gives a brief overview, but this discussion is making me think that we need to write something longer and more definitive. There's a lot of confusion around PCI pretty much everywhere.
You're playing semantic shell games here. The user has no reasonable way of knowing that stripe.js came from stripe, and as such, there are no technical OR human controls that enforce that behavior.
In short, the fact that stripe.js is delivered from stripe DOES NOT MATTER, because the user CAN NOT reasonably validate this behavior.
I know you're not dumb over at Stripe; I have a hard time believing that you're not willfully lying. After all, "disrupting" onerous industry security standards is to your competitive advantage.
I think you just hit on a major issue that merchants face when it comes to the PCI DSS. Many merchants have been wrestling with the scope of PCI DSS compliance for years. They are looking for easy solutions where unfortunately there are very few. The PCI council has done a very respectable job of creating compliance guides and standards documentation. However, when it comes to implementation merchants struggle with scope. If a merchant server as an example responds with a reference to the stripe.js & that code is then executed within the browser context of the merchant domain, is that merchant server in scope for that component? I believe it is and every QSA (PCI qualified security assessor) I've had this same conversation with has come to that exact same conclusion. If Stripe consults with their QSA and they come to a different conclusion, then I would hope Stripe would share that publicly with the community. That would certainly be a ground breaking event for those of us who deal with PCI DSS on a daily basis.
In terms of accusation, my goal here is to ensure that Stripe.com and others who are working in this space are being as clear as possible with their communication, that's it. Stripe is going to address statements like the one I pointed out on their site & hopefully as an industry we can get to a point where everyone is a bit more clear on what falls in and out of PCI DSS scope.
I have three comments though if you're willing to listen!
- I think your customer service department (although they do a good job) the quality has gone down, I often have to now wait several days for a reply. I guess this is the inevitability of growth though. In an ideal world it'd be nice to go back to when I got same day replies :)
- We're a UK business. We take payments in EUR/GBP/USD. Like EUR, it would be nice to be able to withdraw our USD to our USD account in the UK! At the moment we're forced to withdraw it to our GBP account which is expensive.
- It would be nice to be able to hold up withdrawls. At the moment our account is flooded with lots of payments, it would be nice to schedule all payments to be weekly/fornightly or a specific day of the month. Make our accounting process a lot easier and cheaper.
Thanks for all the great work, I've been excited ever since I've started reading about you and am a big fan! (I got a tshirt on the way as well for reporting a small glitch which I'm excited to receive!)
Thanks for the feedback, Tom! I understand how the USD -> UK transfers would help; we're looking into making that an option.
For accounting, we've found that better reporting tools usually solve the need for less frequent transfers. Would one of the options at https://support.stripe.com/questions/reconciling-transfers-w... make this easier on you? Feel free to email me if not so I can understand more about your setup. Every part of Stripe should be incredibly simple, including accounting, and I want to make sure we get this right.
Re support: you're right that the replies have been slower than they should be, though that's getting better. Basically, our userbase grew massively in 2013 and our support hiring didn't keep up with it. I spend all of my time on scaling the team, and we've more than doubled the size of the team in the past couple of months. More hires are on their way. I realize our internal machinations aren't very relevant—you just care that the result is excellent—and I'd like to be clear that we're working on this. You should expect to see significantly faster replies and more ways to get in touch with us over the coming months.
While you should already be seeing improvement in this area, feel free to get in touch with me directly at michael@stripe.com anytime. I'd love to hear any other feedback, and am more than happy to help with whatever questions you have.
I'm pretty sure you can hold up withdrawals. You just cancel the automatic transfers from your dashboard then when you want to do a transfer just schedule it manually (or through the API).
One of the best parts of that 2011 thread is the number of people asking for Canadian support, then how quickly Stripe actually ended up supporting Canada (within 1 year roughly).
We desperately needed Stripe and you guys delivered so quickly. Much appreciated.
Dear Stripe. I love you. Please add Micro-Transactions support like PayPal at the 5% + 0.05 cents transaction fee for payments under $12 dollars. Patiently waiting, Chris Norstrom.
great job guys. i've used stripe and it definitely works well. love the "checkout" and the customization i can do with integration into my own page. pretty seamless compared to other vendors.
only quip: price! would love to see a different pricing scheme for cheaper products. $0.30 fixed fee is a lot for carts that are only a few dollars!
awesome man, joined the club 2 years ago and now my company relies on you and EasyPost, both YC companies to get our work done every day. It's great to work with your group, you guys have done a great job, props!
Congratulations to the Stripe team. Strips is one of those excellent companies that make the tech world a better place.
I actually spent the day working on adding Stripe integration to a Django application for my startup. Since there seem to be a number of Stripe people on this thread, I thought I might give some feedback.
It was fairly straightforward to add a custom credit card form, but not as easy as I had expected. You've made a really nice form with Checkout, but that isn't flexible enough for many users. You leave a fair bit of work to your customers if they use the raw Stripe.js library. You mention your open source jquery library for doing client side validation [1], but don't provide any good examples. In particular, the neat trick in Checkout where you show the logo of the type of credit card being used isn't documented anywhere. This blog post [2] is a crucial piece of information. Your Django examples seems a little out of date, as you've been using Flask for your python examples.
In short, I spent a day pulling things together, and got a form that has many of the nice features of Checkout. That's cool. However, you should really make it dead simple for your customers, with good examples that give ultra-slick validation and results.
I have it without such extensions. I pasted the text from the article in a comment below if anyone still has difficulty accessing it (it took me a while to get through).
This is both amazing and scary. The amazing part is obvious.
The scary part is we now have companies that are worth a billion dollars that are unlisted and have no public scrutiny. Either a billion is not a very large number to the American people today, or we believe that public scrutiny is unnecessary for large companies today. I don't think at all that Stripe is one of them, but wouldn't a billion dollar company be a powerful entity that could invest to subvert the public interest?
I'm not sure what you mean by 'public scrutiny'. Surely any common person on the street has absolutely no influence over Google or Microsoft wishes to do. And going public hardly has any influence at all.
Beyond all Companies/Organizations are not Governments, they don't collect taxes and they are not voted into power. So they are not answerable to anyone. These are individual(s) who are investing their own time, money, and on their own risks to create wealth.
> Beyond all Companies/Organizations are not Governments
All juridical entities other than individual persons -- and this definitely includes all corporations -- are creations of government through which special privileges are given to particular individuals on the theory that by doing so some common good will be served.
Even if that $1 Billion number was actually a revenue number and not just a "valuation", Stripe wouldn't even register in the top 300 private companies in the US:
Congratulations. Stripe really changed the payment implementation for Developers.
Please know you have this valuation, support more Developers communities in meetups, developers conferences, API conferences.
Twilio opened the way in the Telco world, please do it in the Payment one.
Stripe is amazing - I can't believe it took until 2011 for something like them to exist. It really blows my mind - one of those "seems obvious, but only after you've seen it" things.
Here's to y'all figuring out more than just CC payments in the future, and making them just as awesome.
When is Stripe coming to India? An estimate would be really nice! The only way Indian startups can get to use Stripe right now is by setting up an LLC/LLP in US/UK and accepting payments through the LLC.
The problems with this approach are:
1) High initial cost of setting up the LLC.
2) Lawyer consulting fees and/or CPA fees.
3) Separate taxes for the LLC.
4) The same income is taxed in the country of the LLC AND India.
India is one country that needs Stripe very badly right now. The payment gateways here have the shittiest/unreliable APIs you could imagine of. One of them (CCAvenue) even got hacked and it was found that passwords were being stored in plaintext. (!)
However, the transaction volume is pretty much as high as any other country. Would love to get an idea of when Stripe would become available here..
Stripe is probably my favorite infrastructure startup of the past few years, and I'm delighted to see them do so well. Looking forward to seeing what happens in the _next_ two and a half years!
I'd love to know what are stripe's plans to launch in countries where payment gateways are regulated and one company has constitutional monopoly (looking at you, Chile).
I've always thought of Stripe as a "faster horse" in the world of payments. I expect Google, Apple, or Square will find some way to disrupt credit cards completely and move consumers over to a new method of payment for most transactions. PayPal would also like to do that, but I'm not sure they have it in them. And Bitcoin may well upend them all.
I'm curious about what one of these decks looks like.
When you raise money, you presumably have some notion of how you are going to spend that money. $X for new engineers, $Y to build out the London office, etc.
What does a plan for SPENDING the $80m they raised in this round even look like?
Stripe is one problem which is solved really really well. Behind the pretty API there is serious amount of work with bureaucracy and traditional systems. Kudos to a job well done.
Congratulations to all at Stripe on the milestone. It’s nice to see a good idea being well executed and leading to the success it deserves. There can’t be many new businesses that have had such a positive effect on so many other new businesses in such a short time.
Was just watching the old prototype day recordings from the s09 batch. Impressively focused on the same problem since day 1: "We're like Authorize.net, but we're easier and faster." Lots of progress - congrats!
I am a developer interested in integrating a payment system into one of my sites where my target customers are mainly in the US. Could someone outline the major differences between Stripe and Balanced?
All depends on the country your bank account is in.
As an Australian company selling to the US, we've kinda been left in the lurch with their AU beta.
When it was launched we were told they were working on being able to accept/convert USD into AU accounts, so at the time we (incredibly naively) started building our subscription code around their API, assuming it'd be ready by the time we were.
Almost 6 months later and all we can get out of them is "we don't have an eta but we're working on it", and we've been sitting here the whole time losing money hoping that it's just around the corner, when really we should have just thrown out the work we'd done and gone with a provider that can already handle it.
You should check out https://pin.net.au/ – it's an Australian competitor to Stripe. You can accept payments in USD and Pin will settle in USD to an Australian account (this is exactly what we do at FastMail). We've been using them exclusively for the last few months and are pretty happy, other than the lack of Amex support, which they're still working on.
Thanks - we originally looked at them but they didn't have recurring payment support at the time.
Since then they "acquired" an entirely separate recurring payments company (I don't recall the name), and it was all just a bit too much of an integration mess at the time, when compared to Stripe who also announced their beta then.
Oh no — I'm very sorry to hear that. We try to avoid giving ETAs for functionality in order to avoid having people get stuck like this. (At the same time, we sometimes do indicate when we plan to do something — which does have this failure mode.) But we should probably have been clearer that it wasn't going to happen imminently — want to drop me a line at michelle@stripe.com and I'll see if there's any way we can help?
I'm also interested in this and would like to include in the comparison other companies which may (or may not, hard to tell as an outsider) be in the same space: Square, Dwolla, Braintree, WePay.
Steve from Balanced here. I'm in charge of the API.
You can look at this comparison in a few ways. We share a lot of the same investors: Both YC, SV Angel, a16z, etc. They've gotten a lot more funding than we have, and so have a bigger team.
You get paid faster with Balanced: we have _same day_ payouts to Wells Fargo customers, and _next day_ payouts to any other bank. Stripe is seven days.
Feature wise, we provide a lot of the same things, but Balanced has more. We support ACH debits AND credits, for example, and Stripe only supports credits. We're soon adding push-to-card as well. We have escrow, and let you choose how long to hold funds in it.
Speaking of escrow, in general, we have lots of extra features for marketplaces, since that's our bread and butter. Stripe now has a marketplace product, Connect, but it basically requires all of your sellers to sign up for Stripe. Our customers tell us that white label is important, and so Balanced is 100% white labeled. We individually underwrite all sellers, and we give you full control over your descriptor, on a per-transaction basis.
Our fee structure is 100% transparent, and the same for everyone. You can negotiate with Stripe on your rates, ours are just published publicly: https://www.balancedpayments.com/pricing
In general, Balanced is striving to be as open and transparent as possible: new feature discussion is done in the open, on GitHub. As I just mentioned, our pricing is transparent. We're working with Gittip and several other companies to start the Open Company Initiative[1] to help promote general open-ness. Loving that internal transparency from Stripe with their emails. [2]
To say some more good things about Stripe, they have launched in a few places internationally, and we are still US only. We can accept foreign credit cards, but merchants need to be in the US.[3] Hoping to fix that, regulations are hard.
Stripe has a loyal fanbase for a reason: they do a great job. I really appreciate the clarity of their docs, for example. Patrick, I know you're as much of an HN junkie as I am: congrats on the raise. Let's all keep dragging the payments industry kicking and screaming into the future. ;)
Here's some links from others, comparing the two of us:
> To say some more good things about Stripe, they have launched in a few places internationally, and we are still US only. We can accept foreign credit cards, but merchants need to be in the US. Hoping to fix that, regulations are hard.
You should have a form on your website where I can add my email address and then you can tell me when Balanced is available in my country.
Good suggestion. We'll work on adding that [1]. Right now, we have those interested +1 on a GitHub issue tread [2], so we can contact them later, but you're right something a bit cleaner would be easier for you and us.
Congratulations to Stripe. It's great to see a company with an excellent product succeed against the huge incumbents. I use Stripe for all my projects and I can't recommend it enough.
In the crowded field of online payments, venture capitalists are betting Stripe Inc. is a standout worth more than a billion dollars.
The payments startup has raised about $80 million in new funding this week from venture-capital investors including Khosla Ventures, Sequoia Capital, and Founders Fund, said brothers John and Patrick Collison, the company's co-founders, in an interview. Stripe, at just over four years old, is now valued at $1.75 billion.
The lofty valuation for such a young company suggests Stripe is growing rapidly in the area of mobile payments—a market that Forrester Research estimates will add up to $90 billion in total U.S. spending in 2017—and posing a threat to eBay Inc. EBAY +3.84% 's PayPal, the digital-payments leader for more than a decade.
Introducing WSJD, the Journal's new home for tech news, analysis and product reviews.
The San Francisco startup is among several companies trying to simplify how businesses accept payments online and through a mobile device. Stripe provides easy-to-use computer code that any merchant can plug into their website or mobile app to begin accepting credit-card payments. The company takes 2.9% of most transactions in addition to a flat commission of 30 cents per charge—the exact same rate set by PayPal.
"Payments are still startlingly disconnected and fragmented," said Stripe President John Collison. "Less than 5% of consumer spending happens online today. It's pretty clearly going to be much larger than that."
The new funds will help fuel Stripe's international expansion. Stripe, now accepted in just 12 countries, has plenty of work ahead to catch up to PayPal, which is in more than 190 countries. Entering each new country requires meeting local laws governing payment providers, and sometimes requires Stripe to team up with existing businesses, Mr. Collison said.
While the company doesn't disclose its revenue or number of merchants, its software is now used in thousands of popular mobile apps, including ride-sharing service Lyft and grocery delivery app Instacart. Its total payment volume has doubled since last September, he said.
Stripe's transaction total is likely dwarfed by PayPal, which processed $125 billion in purchases last year. But according to Khosla Ventures' Keith Rabois, an early PayPal executive, Stripe has a competitive advantage because it created a simple new service that is popular with developers.
"PayPal has a lot of legacy technologies cobbled together, whereas Stripe has reinvented everything they are doing from scratch," Mr. Rabois said. "Stripe has created a brand where all new developers start with the premise that Stripe is the right answer. If you were a developer today and you thought about using a different option, your engineers would think you're insane."
Stripe saved costs for Lyft, which began using the service a year ago to let drivers quickly process mobile payments. "Stripe removed the need for us to hire additional internal staff to process payouts to Lyft drivers," said Lyft co-founder Logan Green in an email.
For its part, PayPal stepped up competition in mobile payments last year, when it paid $800 million for Braintree, widely seen as Stripe's closest rival. On Wednesday, eBay said that activist investor Carl Icahn wants to split up the company, dividing its PayPal payments unit from its e-commerce site.
A spokesman for PayPal declined to comment.
Stripe has now raised more than $120 million from investors, who include PayPal alums Elon Musk and Peter Thiel as well as Andreessen Horowitz, Redpoint Ventures and General Catalyst Partners. Stripe was last valued at close to $500 million when it raised funding in July 2012.
An engineer-heavy workforce, Stripe now has about 90 employees.
The company is in talks to power payments for a shopping feature on Twitter Inc. TWTR -0.14% 's social network, according to a person familiar with the discussions.
Write to Douglas MacMillan at douglas.macmillan@wsj.com
