Stripe: instant payment processing for developers - <AUTHOR> https://stripe.com <comment><USER3> Stripe pretty much takes payment processing kicking and screaming into 2011. Merchant accounts are a _serious_ drag. I've opened a few and they've been nothing but headaches (especially if you're young—nobody trusts you.) Couple that with getting a gateway account, dealing with credit checks, monthly fees, monthly minimums, slow people in the payments industry, PCI compliance...

Stripe takes payments and put them behind a simple API. No crappiness and 1099 rules of PayPal. No more reconsidering the meaning of life like back when I had a merchant account. The only downside I see is the 7-day rolling batch (deposit to bank), versus the nightly batch from the merchant account, though I assume that is for fraud protection.

Maybe if you're charging millions of dollars, you should use a regular merchant account. If you aren't, I'm telling you now: don't even bother with a merchant account. Just use Stripe.

<comment><USER4> I would love to see someone drag it kicking and screaming outside of the US. :(

<comment><USER5> Also, it would be nice if there was somewhere I could drop my email address to be notified when Stripe makes it to the UK.

<comment><USER6> Third'd (i reckon stripe should set up a UK notification email/landingpage)

</comment></comment></comment></comment><comment><USER7> Stripe is a game changer. I've been using it for a few months and honestly its the best API I've ever used. The documentation is clear and concise. Its customized to your account so you can literally copy and paste and see the result. Just like it says, it gets out of your way. I was up and running and accepting recurring payments in less than an hour or so. I actually began to think of larger "swing for the fence" type of ideas that I would have never considered if I were stuck to using Paypal because it was so painless. Looking forward to them eating every other payment processor's lunch.

<comment><USER8> Anyone know whether they used a documentation tool to generate the 'example on right' style pages? E.g. <https://stripe.com/api/docs?lang=python#delete_customer>. It's very clean. The general layout and feel of the API doco is great.

<comment><USER9> It's mostly just a custom thing I wrote. The CSS is mostly taken (with permission) from Jeremy Ashkenas' sites (see Backbone, CoffeeScript, etc.)

<comment><USER10> Navigation menu doesn't work in IPad.

<comment><USER9> I think it's fixed in iOS 5, but yeah not an ideal answer.

</comment></comment></comment></comment></comment><comment><USER11> "You don't need a merchant account or gateway."

That's a killer feature right there. I've been considering using Braintree for a project, but seeing this is really making me reconsider.

<comment><USER12> As a beta customer, not having to deal with 95% of PCI and merchant accounts etc. really made a huge difference to how fast we got going.

<comment><USER13> Sure, but other companies, e.g., Spreedly, let you outsource PCI compliance as well. This is the first I've seen that let's you get away without having a merchant account.

<comment><USER9> We're abstracting away the problem of having a merchant account, because we generally believe there are too many complex moving parts.

<comment><USER14> Wow! This feature is what I was looking at. Glad to have something processor that doesn't need me to have a merchant account. Sweet!

</comment></comment></comment></comment></comment><comment><USER15> Been a beta user for a while, and I love their Ruby API. I used to use Braintree...while they were a good merchant account provider - it was overkill for what I needed.

I much prefer only paying when I make money. I don't NEED a merchant account. I just need to be able to collect money from my customers in an automated way. Stripe makes that relatively easy.

Their API has a quick feedback loop, where you can execute a transaction from the command-line very quickly (for Ruby anyway...I imagine it would be the same for other languages).

Their support is also awesome - could be because they only had beta users. But either way, awesome service so far and much better to deal with than a 'traditional' payment solution for those webappers out there (in my experience).

Not affiliated with the company in anyway, other than a customer.

</comment><comment><USER16> US only. Well, I kind of knew it before even hitting FAQ.

A bit of a rant here, but it's crazily difficult to do so many interesting things when you don't live in top-20 country (Lithuania here)

Stripe? Nope.

BrainTree? Nope.

Recurly? Nope.

Something else... Likely, Nope.

And so, the only way to get paid is to deal with some of the most expensive and oldest gateways and merchant accounts.

Oh, and:

Hulu? Nope.

iTunes? Nope, but we do have App Store.

Netflix? Nope.

Spotify? Nope.

Pandora, Rdio, ... Nope.

...Amazon? Mostly nope.

And so, the only way to buy or stream media is to buy CDs and DVDs for crazy prices.

Sigh. Rant is over.

Stripe, I know that may take years, but please, don't forget the little guys.

<comment><USER17> Have you looked into incorporating in the UK? It's probably quite a bit of hassle up-front but should solve this type of problem. Unlike in many (most?) European countries, incorporating a limited company in the UK is pretty cheap and straightforward in itself.

<comment><USER18> I don't see what incorporating in the UK would buy you. Payment processing here is a total clusterfuck.

</comment></comment></comment><comment><USER19> Their signup process threw me for a loop. You just click into the dashboard, then fill in a name and password later. It looks like just visiting the front page gives you an account, because the sample code is already using some generated API tokens.

I've considered doing something similar for my own side project, but went with the more standard sign up because I was worried it would be confusing (as it was to me, for a few minutes). Do you guys think this is becoming more mainstream, at least amongst developers and the tech-savvy, that other projects could get away with this? I'm curious how many support requests Stripe gets because of this.

Edited to add: How does this work for the non-logged-in state? I already have an account, and the browser cookie expires (or manually delete the cookies). I'll go to the dashboard, and be logged in as "anonymous", and have to sign out and sign in again as the right user. Seems like an extra incongruous step.

<comment><USER9> Yeah, it does sometimes confuse people. This is something we're considering about changing (the flow worked differently when we were invite only), but we thought it was worth experimenting with a little longer.

Mostly, I think it depends on the type of app you have. For something like 280 Slides (a previous project I worked on), it makes a lot of sense to get started right away without having to sign up. We'll see how things go for Stripe.

<comment><USER20> This is extremely confusing. Thought it was just a test account. Left depressed because I couldn't sign up.

<comment><USER21> yep, i thought the same.

</comment></comment></comment></comment><comment><USER22> US only at the moment. Anyone know if they have plans for the UK? I would dearly love to say goodbye to PayPal forever.

<comment><USER9> We're definitely working on expanding to other countries. There's no definite timeline just yet, but it's one of our top priorities.

<comment><USER23> I've held off developing / launching a few small biz ideas because of the state of payment providers in the UK - ready and waiting to help you test when you're over here :)

<comment><USER24> I concur entirely (and have spoken with my MP about it).

However, as far as I can tell, anyone using any of the more established "big name" billing services to collect payments for a UK company is almost certainly breaking at least one law on a "your business is at risk" scale. Stripe would have to be very special to do better.

The usual culprits are VAT (I have yet to find a billing service that would actually allow a UK business to comply with its basic statutory requirements on this count, including several that claim to support VAT) and privacy (exporting personal data, such as names and credit card details, outside of Europe requires certain guarantees, which again I don't think would be met by any of the services I've looked into so far). I imagine quite a few businesses are getting away with using these services and not meeting their obligations, but personally I wouldn't want to operate with that sort of risk, particularly now Business Record Checks are becoming big news.

Stripe does seem to have a fairly clean API, but on the flip side, it also seems very limited in features next to some of the more established competition, so maybe it's just horses for courses. Again, I know that none of the other billing services we've considered this year even got close to supporting the _basic_ charging model we wanted, never mind all the bells and whistles we've been considering, and if you wind up having to do a bunch of financial legwork yourself, these services start to look like very poor value for money pretty quickly.

IMHO, what small businesses in the UK really need is for the government to stop hassling banks about lending lots of money (sometimes useful, but not to many of us) and just get them to provide basic services like card payments in a sane manner: no multi-month waits to get up and running, directly comparable charging structures on some standard basis, transparent migration of customer card data between all the vault services without causing a PCI nightmare so there is genuine competition in the market, and so on.

And then I woke up. :-)

<comment><USER25> I don't see the problem with VAT. Just keep rack of where your customers are and pay the VAT on those in Europe. Where does the payment processor come into it? If you owe VAT then pay it.

<comment><USER24> It is not as simple as that, at least in the UK, and the fact that so many payment services seem to think it is explains why any UK business relying on them for payment processing is probably breaking the law.

There are all kinds of rules on disclosure of VAT registration details on invoices, sequential numbering of VAT invoices (across an entire company) for audit purposes, etc. Any payment system that doesn't integrate with other company procedures to meet these basic statutory obligations _can't_ be sufficient.

<comment><USER26> I have an online business selling globally operating out of the EU and I now know more about VAT than I care too. I agree that the rules can get quite complex but as far as I can tell the payment processor does not need to be able to do anything special other than the ability to store/display the required information with each transaction (date, sequential invoice number, and VAT number in the case of a B2B transaction). You can just put that in a free format field (in PayPal for example), that's all they would need to add I think.

Sure it would be nice if they stored tax (multiple rates possible on one invoice!) and VAT numbers in a separate field, it would be even nicer if they validated the VAT numbers for you, or the buyers location, but it can all be done outside the payment processor.

<comment><USER24> Indeed, but you do need to be able to store and display that information in the right places.

As you say, technically invoices are supposed to record the VAT against each line item, because the rates can be different for different types of product/service.

Regarding the serialised invoice numbers, if you as the merchant are having to keep track of such things then you're still doing some of the tedious work so the value of outsourcing the billing process is lessened. I agree that it might be viable to record the extra information in a separate field for one- off transactions, if the billing service allows that kind of annotation on transactions and your systems can generate the appropriate number taking into account any other sales channels you're also using.

Even then, for subscription services that renew automatically, there would need to be some robust mechanism for the billing service to "claim" the next invoice number when they collect a scheduled payment. Perhaps some of these services could cope with this, but I have yet to see one personally whose documentation explains how to set it up using their APIs and callbacks. And if you get to the point where you have to handle scheduling regular subscription payments on your in-house system to account for this, again you're defeating the point of outsourcing the billing in the first place.

IME, it doesn't take long before you have to do so much in-house anyway that you might as well do the lot and save yourself a signficant overhead and the additional risk/dependency of involving another organisation in your billing process. This sort of processing is tedious but not rocket science, so if you can't just wrap _everything_ up and shove it out to a specialist service, avoiding having to go near that sort of stuff in-house at all, I just don't see how the cost/benefit of these services is going to make them attractive to a business here in the UK. YMMV, of course.

<comment><USER26> Agreed, there are no services offering recurring payments (in Europe anyway) that do the whole thing, and I would love to outsource more if I could since billing is a nuisance that just detracts so much from the actual business. We currently use PayPal but that doesn't even allow you to pro-rate subscriptions when up- or downgrading. I noticed in the API docs that stripe.com at least has that one covered already.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> Stripe, recently saved me. I am still fighting with my merchant processor *First Data who is awful. I talked to Stripe via Sean Harper with FeeFighters and I was up and rolling in 20 minutes. Yes, Jaw drop fast. Most payment processors require at least two weeks to be setup. Their UI/UX is beautiful and simple. When I need help I get it immediately. I love this company. :)

</comment><comment><USER28> I'm not sure about avoiding PCI compliance so easily. You're embedding their JS library on your page. That page has to be secure, otherwise if someone can inject malicious Javascript they can sniff the CC data as soon as they are entered.

You might not be storing the data on your servers, or transmitting the data directly, but security failures in your setup can cause the data to be leaked.

Compare this to sending the user to an external website via a redirect that lets the user at least verify that they're really talking to PayPal or whoever.

<comment><USER29> PCI is absolutely schizophrenic about this point, and right now embedding your provider's form within your own same origin domain is kosher with them.

You're right if you're thinking it shouldn't be.

<comment><USER24> > You're right if you're thinking it shouldn't be.

Why do you think it should not? AFAIK, doing so exempts you (legitimately) from much of PCI DSS that applies if sensitive data hits your network, but does not automatically exempt you from the rest.

Are you concerned that someone will be able to compromise the page on your own server so it no longer embeds the payment service's form correctly, and then capture card data that way?

<comment><USER29> The exemption you are talking about is not legitimate, because of the way browser security works.

<comment><USER24> Perhaps you could elaborate, rather than posting vague innuendo about "how browser security works"?

What specific danger do you see in the embedding scenario that could not arise anyway if the host system were compromised sufficiently to interfere with the embedded material?

<comment><USER30> I'm obviously not tptacek, but I take his statement to mean that currently, PCI finds the following scenario acceptable:

You have a site that takes payment info. Rather than process that information directly and store it you decide to use a service like this to silo out payment processing. This keeps your main environment outside of the scope of a PCI audit (as the only systems in scope for PCI are systems which either process or store payment card information).

You are now not under any obligation to ensure that your application isn't riddled with security vulnerabilities, including vulnerabilities like cross- site scripting which would completely undermine the security of using a third- party javascript library to handle payment processing. This isn't some sci-fi scenario either, I see this every day in the applications I test (mostly e-commerce and online banking applications).

Using the library hasn't introduced any "new" vulnerabilities into your environment, but it has given you an opt-out to actually trying to have a secure system.

He seems to take exception to the fact that PCI doesn't see any problem with this. It's basically a loophole to continue to deploy hole-riddled applications that once hacked, you can say "We are PCI compliant, what are you gonna do."

This gives credence to the people who argue that PCI isn't really a security standard, but just a way to shift blame after a breach.

<comment><USER24> I'm not disagreeing with your example, but isn't that a much wider problem? After all, _any_ business or individual can set up a web site, stick an official-looking form on it, and harvest card details. They don't need any sort of payment processing infrastructure to do that, and clearly nothing PCI DSS says can protect against all malicious strategies for compromising card details.

My understanding was that the parts of PCI DSS we're considering were intended to cover carelessness where a legitimate business collects customer details but then leaves them vulnerable due to internal security failings. If the details don't hit the internal network, _those_ failings can't happen, so it is reasonable to exclude them from the scope of the corresponding parts of PCI DSS.

Beyond that, I'm not sure I see any difference between the embedding scenario and the common practice of redirecting to a payment service's own web pages when a customer reaches a certain point in the order process. If you're exposing a vulnerability that lets an attacker compromise the embedding, they can almost certainly compromise the redirect in the equivalent case as well, and in reality it is unlikely that most customers would notice even if there were clues to give away the attack in some cases.

I'm also not sure what you mean by keeping your main environment outside the scope of a PCI audit. For the payment gateways we've been looking at that offer both hosted and embedded integrations, it is common that the hosted one has minimal audit requirements but the embedded one comes with certain audit obligations for your web site even if you're relying entirely on their system to handle the card details.

Now, if this isn't a mandated practice in PCI DSS, then I do see your point; I've always assumed it is, since everyone we've looked into seems to do it, but in fairness I haven't just looked it up today. However, if that is part of PCI DSS then in fact sites using the embedding strategy are subject to more rigorous scrutiny than those that simply redirect, even though essentially the same attack vectors are probably available for both.

<comment><USER29> If you're a single XSS vulnerability away from transparently capturing credit card vulnerabilities, but there is no requirement anywhere in PCI DSS that your application be in any way hardened against XSS vulnerabilities, all PCI DSS has done is move the target slightly.

<comment><USER24> I completely agree, I'm just wondering how that's any different to any other hosted integration.

Perhaps I misunderstood your original point as being too specific to the embedding situation. Would you apply the same criticisms to the other common integration strategy based on redirects?

If your intended point was that any legitimate business taking credit card details via their web site should be subject to at least some basic level of audit, then I think we are probably in agreement (though I do have a thing about card companies imposing security rules on merchants but then trying to leave merchants with all responsibility for any fraud anyway, which is a totally one-sided deal).

[Edit: As an aside, I'm not sure how this would work in a case where the merchant is using an end-to-end solution, which Stripe seems to be, and has no direct relationship with any other financial services. Presumably the responsibility then has to fall on the payment service, which would have to impose some sort of reasonable audit procedure on all of its clients?]

<comment><USER29> The disconnect I perceive here is that you seem to hope there's some technical solution that can factor out an unhardened storefront from a hardened payment processor. That would be nice, but I don't think it can be done today.

Fortunately for developers, PCI's response to this problem seems to be "LA LA LA I CAN'T HEAR YOU".

<comment><USER24> > The disconnect I perceive here is that you seem to hope there's some > technical solution that can factor out an unhardened storefront from a > hardened payment processor.

On the contrary, I don't believe that can be done effectively within the architecture we have today. I just don't believe it can be done effectively for hosted integrations that redirect to the service provider either, so I don't see that the embedding approach is any worse than what was already in widespread use.

Moreover, given that it is unrealistic not to provide hosted payment services (since the overheads of doing everything in-house are prohibitive for almost any small business), I think the only useful response is to impose some basic level of audit on any site that is integrating with an external card payment system. But now you're more into economic/commercial/legal arguments than technical ones, because you have to consider what level of oversight is reasonable (given that any fool can set up a fraudulent site regardless of what you do, how much extra burden is it really sensible to impose on legitimate merchants), how it can be enforced (particularly if the site visited by the end user has no direct legal/commercial relationship with the card services companies), and whether there is a sensible balance between functionality/security and actually being able to operate in the first place as a merchant (which is a balance that the UK currently gets absurdly wrong, though I don't think the scenario we're discussing is why).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> In Patrick Collison's presentation at Startup Bootcamp last weekend, he really brought home the social impact that a payment processing company can have in the third world. Even though it's US only for now, this team has huge goals and the experience and vision to back it up.

Their goal is to abstract away the complexity of payments, especially internationally. I wish them luck, and can't wait to use it.

</comment><comment><USER32> This looks really, really nice. Support for Canada would be wonderful and pretty much essential for me to be able to use it. The other thing I'm wondering about is ACH payments - will Stripe handle those; if not, is it planned? Also, would Stripe be suitable for a card-holder present situation, e.g. if you wanted to use it for web-based point of sale software?

<comment><USER9> We don't handle direct transfers between two ACH accounts yet, but it's something we're thinking about and planning for down the road.

As for point of sale applications, Stripe isn't really optimized for that. Have you checked out Square?

<comment><USER33> ACH payout to multiple endpoints would be killer (think App Store type 70% payouts to users).

On another note, your markup is doing some strange things:

;var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});var MrchComponent = Component.extend({});;var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});var SideboxComponent = Component.extend({});;var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});var RecentPaymentsComponent = Component.extend({});

<comment><USER9> Heh, indeed it is. This is part of a web framework we're using right now that lets us push code updates to the page, but it just appends content. We're reworking how a lot of this works right now.

</comment></comment></comment></comment><comment><USER34> I saw this on the front page and had to upvote-- I've been using Stripe since early June and can say that it is the best payment platform to develop on, period. It's just lightyears ahead in terms of development time, PCI compliance issues, and overhead. Not only that, but the guys at Stripe are _extremely_ responsive to customer service questions and issues.

These guys are trustworthy professionals and gentlemen.

</comment><comment><USER35> Amazing product. We're building an eCommerce platform (<http://www.kout.me>) and have been building our payments on top of stripe.

Very amazing concept and something that we've needed for a long time. The best thing is the developer focus behind it; it's clear from the beginning that this came to fruition with fellow developers in mind.

</comment><comment><USER36> I know this has already been stated and it doesn't add much to the discussion. However, I feel it's important to add my little two cents just so the Stripe team (and others in the same space) can hear it (again):

Please, please, PLEASE make a payments solution like this available outside the US. Europe, for instance, still lives in the dark ages as far as online payments are concerned and has plenty of startups who would jump at the opportunity to use Stripe.

</comment><comment><USER37> Sounds nice, but the bottom line for me is that a typical $47 credit card sale, which always costs me $1.33 at PayPal, would cost me $1.66 at Stripe. Not much difference, true, but discouraging. I have no need of a fancy API, either--PayPal lets me specify the basics and fire off a simple Post from my PHP code. PayPal takes care of receiving financial information so I remain clean. Just my experience; yours may vary.

<comment><USER38> That's much how I feel as well. I accept credit cards and PayPal, and pay 2.2% as well. Stripe gets added to the bookmark collection for "services to use should I ever have a problem with PayPal" (which, knock on wood, won't ever happen -- my account is 11 years old now).

</comment></comment><comment><USER39> I'm comparing payment processing options for a very straightforward SaaS app. I was heavily leaning toward Braintree, but Stripe and Samurai seem easier/cheaper. Is there a strong reason to go with Braintree? I'm not sure if having my own merchant account makes a big difference.

The pricing for 1,000 monthly users looks (roughly) like:

(edit: I did the % based on $9/transaction)

Stripe: $329/mo @ $3,948/yr

Samurai: $358/mo @ $4,296/yr

Braintree: $487.90/mo @ $5,854.80/yr

<comment><USER40> We work directly with Wells Fargo on our backend to make sure you end up with all the normal benefits of a merchant account (the money will be held in your name, you will be able to put whatever you want on your customers' credit card statements, etc.). We just want to abstract the whole process here -- basically, putting you on the account or accounts that makes the most amount of sense so you can start processing immediately and then continue processing at high volume.

<comment><USER39> Very cool. Is there no underwriting process then? That seemed to be one of the biggest steps in getting setup with Braintree.

<comment><USER41> There is quite a bit of screening/evaluation behind the scenes, but one of our goals is to not have legitimate businesses worry about any of it.

</comment></comment></comment></comment><comment><USER42> Even though the credit card details never hits the webserver of the host site, does the fact that the fields are on the site rather than in a secure iframe not mean that there's still a PCI issue? Namely that if a malicious party manages to find a way to inject javascript into the page they can read any form field they want, regardless of whether it's being submitted elsewhere.

This was true of Braintree (the form posts to a remote url rather than to a server run by the site), how does Stripe alleviate this issue?

<comment><USER9> If someone injects javascript into your page, nothing you do will matter -- you are compromised.

This is why your site has to be served over SSL (to prevent MITM attacks), and why you should be careful about what third party content you embed in your site. In particular, you should never embed a non SSL resource on an SSL page (also known as the mixed content warning in most browsers).

<comment><USER42> But say you have a untrustworthy employees (it happens), as long as they have the ability to deploy code, they can compromise your site. So my question is, to what extent can a solution like Slice (or Braintree) truly alleviate the PCI burden, surely you'd still need a record of who has the ability to deploy code, audit trail for deploys etc.

Obviously you should be doing all this stuff anyway. I guess the point I'm making is that solutions like this make great claims about their ability to solve all your PCI woes, and I'm wondering about the extent to which this is actually true. PCI compliance is (normally) quite expensive to achieve, so your solution is obviously very attractive. But is it enough?

<comment><USER43> >But say you have a untrustworthy employees (it happens),

Well that's still a PCI requirement, but many more of their requirements wouldn't apply (i.e. rendering stored PAN unreadable, etc).

When in doubt: <http://www.youtube.com/watch?v=xpfCr4By71U>

<comment><USER9> Rumored cost of this video is over 1 million dollars.

</comment></comment></comment></comment></comment><comment><USER44> My only concern is that Stripe will be such a hit that they'll be bought out by someone like Paypal. Which would suck since the point was to move away from Paypal to Stripe.

</comment><comment><USER45> Been playing with the API as a beta tester and the docs truly were written by devs. Clean, concise, and gets straight to the point, and they have example code in multiple languages. Plus some really awesome customer support - overall Stripe really rocks.

</comment><comment><USER46> Best API ever for a payments processor - period. It literally takes a couple hours to set up begin collecting payments. If I could buy some shares right now I would. I've convinced 2 people to use it and both are in love. This startup is money.

</comment><comment><USER47> I mean this as a serious question: when Stripe has 10,000 customers next year, why will they be less capricious and infuriating than Paypal?

Is there a fundamental difference, or does Paypal just have a ~15-year history of sucking, while Stripe doesn't?

<comment><USER41> Good question.

A lot of PayPal's issues stem from the draconian fraud measures they need to employ to handle user-to-user payments. Our business and fraud problems are fundamentally different because we don't support this use case.

Additionally, we've been really careful to grow slowly, and to make sure the experience for our users remains great. We've been in invite-only mode for well over a year before opening up today, and intend to monitor (and, if necessary, limit) our growth so that this doesn't happen.

We'd rather be small than suck.

</comment></comment><comment><USER48> We've been using Stripe for Picplum.com since the middle of the summer. These guys are insane -- they saw an error before we even did and emailed us saying they were working on fixing it. Top notch team.

</comment><comment><USER49> First, I wish the folks from Stripe all the best, and the only thing I hoped was International companies support.

But as anyone tried Saasy (<http://saasy.com/>) ? They are the subscription service of Fastspring. They don't require a merchant account and support international vendors. While I haven't tried them yet, when I used non- subscription payments they were the best (www.fastpring.com). They are also very well regarded by indie developers so their subscription service may be quite good.

</comment><comment><USER50> Does Stripe allow delayed payments? That is, people put in their credit card details, Stripe authorizes the card but doesn't capture the amount charged, then we can approve/decline the transaction, and then Stripe can capture or void the transaction?

We have a situation where we need, for legal reasons, to verify that people giving us money are allowed to do so, and we really don't want to have to reverse the charge after the fact if we find out they're not eligible to pay us.

Otherwise, the system looks great, and I want to use it right now.

<comment><USER9> We don't support what's typically known as separate auth and capture in the payment industry (though we may in the future).

Typically, we recommend just capturing the card information by attaching it to a customer object, and then making a charge later. If you're charging a really high amount, or for some reason need a 100% guarantee that the charge will succeed, then right now you'll have to make the charge and then issue a refund in your situation.

<comment><USER51> Note, though: when you refund the charge, the fees you paid aren't refunded to you.

This was the one downside of Stripe for me, vs. PayPal (though it's pretty minor -- I only have a handful of refunds a year... but I offer them all the time, and I've always liked feeling free to do that).

</comment></comment></comment><comment><USER52> What about lock-in? This is awesome for getting started fast, but what happens when you have 100,000 subscribers and you want to switch to Braintree or someone to get some better pricing?

<comment><USER9> We don't like lock in either, and we'll never use it as a business tactic. If you want to move your stored credit cards to another provider, we'll help you out in doing so.

It's a bit tough to make this obvious, because we can't automate it unfortunately. PCI requires that we work directly with the environment that we're sending your data too, to ensure the transfer is also secure.

<comment><USER52> Best answer, thank you.

</comment></comment></comment><comment><USER53> Man... I literally just bit the bullet and opened a merchant account and gateway at Auth.net last week, and the second I do, FeeFighters comes out with their own superior gateway, and Stripe launches. Talk about bad timing for me :(

<comment><USER54> Makes 2 of us. Just finished integrating with Auth.Net. Yep, bad timing IF this is as easy and secure as everybody says.

</comment></comment><comment><USER55> Congratulations on your official launch. I've been using Stripe for a while now and have chatted with several of you in the campfire room. You have always been extremely helpful, no matter what wildass time of the night I may decide to poke my head into the room.

I have nothing but good things to say about your service.

Thank you.

</comment><comment><USER56> I'm guessing that the target audience is solo developers that don't qualify for the volume discounts that every other payments vendor/gateway offers.

As lovely as this API looks, not offering a volume discount is a complete dealbreaker for my business. There's no way I could justify eating an extra ~1% per transaction just so my API integration goes more smoothly and I don't have to deal with the headaches of a merchant account (and while I would call that process anything but smooth, I don't seem to have the awful experiences of some of the commenters here -- just chance, I guess).

The cost/benefit to a business that does any significant volume online just isn't there for this.

<comment><USER9> Volume pricing is something we'll think about in the future, but you're right -- right now we're trying to focus on building the simplest possible payments system on the web, even at the expense of maybe being less attractive to the biggest merchants for a while.

</comment></comment><comment><USER57> Been using them for a while now on Forrst and Tinyproj and they're downright awesome. Smart folks, super developer friendly product.

</comment><comment><USER58> This is an amazing service. I've been researching all of this for a project I am advising on. Merchant Accounts, gateways, fee here,fee there, PCI - it can make your head explode.

It looks like these guys have done it right, and finally hidden the layers friction, banking (and open palms) for us.

Nice Work!

One Nit if anyone from Stripe is reading - it was a bit hard to find the answer to "How & When do I get paid". There is a small blurp on the pricing page (still doesn't say how), but nothing in the FAQ or Docs. Please spell this out a bit more.

<comment><USER59> The front page says "Earnings are transferred to your bank account on a 7 day rolling basis.".

<comment><USER58> Thanks, I did miss that.

There are probably better specifics in the TOS or elsewhere, I guess I was looking for something spelled out better in the docs. (Ex: "Use any standard US Business or Personal checking account")

It's probably just me though :-)

<comment><USER9> Good suggestion, thanks.

</comment></comment></comment></comment><comment><USER60> Wondering when it will work in Canada? Also, how does it work "without merchant account or gateway" ?

<comment><USER40> We're working on international support right now -- though we don't have an ETA, launching in the US was definitely the first part of getting there (and we care a lot about going international -- about half our team is from other countries).

You don't need to make your own merchant account or payment gateway because we abstract over those details. We'll make whatever accounts are necessary and we work directly with the banks to make sure that your money is held in your name, what you want appears on your customers' credit card statements, etc.

<comment><USER61> Is there any chance you guys could set up a mailing list for people to be notified when there is more international support? Merchant services in Australia suck.

<comment><USER9> Just shoot an email to email@example.com

</comment></comment></comment></comment><comment><USER62> I was under the impression that if my website is asking for a credit card number that is later used for a transaction, then it needs to be PCI compliant. Perhaps, it is a Canadian specific, but this need for the PCI compliance is the major selling argument in favor of hosted payment services.

And on a related note - is Stripe available outside of the US?

(edit) Ah, found it.

      > Do I need to be in the United States to use Stripe?
      > Yes.

Damn. Bummer.

<comment><USER9> The exact details of PCI are pretty complex, but, roughly the answer is that any system that touches credit card numbers has to be PCI compliant.

This means that if you take credit cards on your website, you need to be PCI compliant. But the exact requirements differ depending on your setup, and what Stripe helps you do is ensure the credit card information never hits a server owned by you. This drastically reduces the scope of your compliance to a simple questionnaire.

As for being outside the US, not quite yet. We're working hard on that front though, so stay tuned.

<comment><USER62> I was first going to say how's that the CC #s from my web form are not hitting my server, but then looked at your Docs - and what you did is ingenious - <USER2> form is mine, but it is submitted to your site.

The _curl_ example on the front page is rather misleading. It was the only thing I actually _read_ through on that page and I walked away with an impression that that code snippet needs to go to my server. Just the 2c worth of UX feedback :)

<comment><USER9> Thanks for the feedback. We'll work on clearer examples.

<comment><USER63> I'm not sure I understand the PCI implications of using the API. If I use the Create a New Charge example on the homepage in my code, aren't the credit card details going through my server?

*Edit: Nevermind. After reading through the API, I learned you can use a token instead of the card details.

</comment></comment></comment></comment></comment><comment><USER64> Looks like a great service. Too bad I can't use it, since I'm a Canadian.

It gets really tiring to see interesting new services launch that _refuse to take my money_ because I live in a different country. I'm hoping that it's something non-trivial that is preventing them from operating in countries like Canada and the UK, and I look forward to using the service once they are able to offer it to me.

</comment><comment><USER65> Respect. Stripe is a very smart company solving a big problem.

</comment><comment><USER66> This is an incredible product built by a team of amazing developers, solving a serious problem.

I will enjoy watching their success.

</comment><comment><USER67> Awesome that the payouts are now much faster. That was the one thing keeping me on the fence but will be using it right away for StartupThreads.com

</comment><comment><USER68> I operate in what the credit card processors consider to be a "high risk industry". It's nearly impossible for myself or my competitors to get a merchant account without a reserve. In other words, for every $1 we charge, the merchant bank holds X% in reserve (until we hit a certain threshold). Thus, if we tried to defraud customers by selling bad products and then "disappearing," the merchant bank could use the reserve to refund customers.

So, with that as a preface, how will Stripe deal with chargebacks? It seems like it would be very easy to set up a scam, e.g. a merchant sells phony inventory and then "disappears" when customers complain.

<comment><USER9> Yup, dealing with risk is a hard problem that we're giving a lot and thought and effort to. We rely a lot on online info to verify identity, which gives us some advantages. But yes, we're working hard on mitigating the risks involved with fraud.

</comment></comment><comment><USER69> Stripe is simply amazing. We've been using them for many weeks now and things just work. Setting up payments was so much easier.

</comment><comment><USER70> We've been using Stripe at MixRank, and refreshing how easy it was to set up. This is how easy accepting payments _should_ be. The team is excellent too; they've been extremely helpful so far.

</comment><comment><USER71> Wow. Excited. After watching PintPay toy with my emotions, I'm glad someone did it up right. I hope they've got a viable model. The market is positively starving for something like this.

</comment><comment><USER72> I got this awesome handwritten letter in the mail today from Stripe. <https://p.twimg.com/AaoSX5BCQAAx4T9.jpg>

</comment><comment><USER73> I was very excited reading their faq until I realized it's US only service.

Can't wait to see you guys expand internationally. Best of luck.

<comment><USER74> Stripe looks so good, I think I'm going to try and open a US account.

</comment></comment><comment><USER75> I have a problem with using merchant startups. If they go out of business, what happens to my clients? If I have thousands of clients, I would not want to be forced to get all of their credit card info again (since I wouldn't be storing any of that info).

Although I hate using the big guys, at least I know they will be around in 5+ years.

<comment><AUTHOR> We'll happily export your card data to another provider if you ever want to move away.

<comment><USER75> Are you legally allowed to even do that? Do you store card data yourself?

<comment><USER41> Yes and yes. We are a PCI Level 1 Service Provider. More information on our security practices: <https://stripe.com/security>

</comment></comment></comment></comment><comment><USER76> Can you fetch any meta data on a customer's saved card? For example if a single customer has four saved cards you might want to present it as: * Visa ending in 1234 * MasterCard ending in 5678

Also, when a customer's card is expiring how are they prompted to enter an non-expiring card?

<comment><USER9> You can get the type and last 4 digits of the card. Right now, we only allow you to store one card for a customer -- something we'll probably change in the future.

Since we aren't putting ourselves anywhere in the front end of your app, we can't notify your customers when they have cards that are about to expire -- it's something you'll have to choose how you want to communicate.

</comment></comment><comment> old-gregg Awesome company, we're at Mailgun have been using them for a long time and couldn't be happier.

</comment><comment><USER77> Stripe looks awesome for small scale business. At large scale, Braintree still has cheaper pricing (<http://www.braintreepayments.com/pricing>) and the monthly cost is negligible.

<comment><USER9> Pricing is pretty hard to compare directly between something like Stripe and Braintree. In particular, there is no one clear answer, because it depends on your own mixture of AMEX cards, international cards, rewards cards, etc. We have some medium sized businesses on Stripe who have run the numbers and come out cheaper with us, but that won't be true for every merchant.

Part of what we believe to be valuable here is the simplicity of knowing exactly what your fees will be on every transaction, and in aggregate. There aren't any surprises.

</comment></comment><comment><USER78> Quick suggestion... I tried to share on Facebook and didn't get an image. Set this in your <head> so it looks better when shared:

<link rel="image_src" type="image/png" href="PATH TO IMAGE" />

<link rel="image_src" type="image/jpg" href="PATH TO IMAGE" />

</comment><comment><USER79> Something that is really needed, looking forward to the availability outside the states.

</comment><comment><USER80> Does Stripe let us take our data with us if we want to leave for another processor? If I build a recurring revenue business on Stripe, am I screwed if they hike up their fees by not being able to move the credit card #'s elsewhere?

<comment><USER9> Yup, we do. Checkout my other answers in these comments.

</comment></comment><comment><USER81> Interesting. Is there an end-to-end demo from the user's perspective? Do the users know they are storing the CC info on Stripe? Or they think my site handles everything and is responsible for everything (privacy, etc)?

<comment><USER41> We are completely transparent to your users - it's a conscious design choice. You can always choose to tell them about Stripe and link to our security page if it makes sense. <https://stripe.com/security>

</comment></comment><comment><USER82> Not to take away from the product, which I think is pretty awesome, but I do foresee a rather sticky issue should the company blow up somewhere down the line; the logo is rather reminiscent of that of my former employer Deutsche Bank's, and I wouldn't put it past the multinational financial behemoth to take notice, with potential financial consequences, especially as Stripe pushes its product internationally. For reference:

[http://www.oraclefusionnews.com/wp- content/uploads/2011/07/d...](http://www.oraclefusionnews.com/wp- content/uploads/2011/07/deutsche-bank.jpeg)

<comment><USER9> Stripe does not currently have a logo, other than the word Stripe.

<comment><USER82> Sorry about that, I was basing my comment off the Crunchbase profile (<http://www.crunchbase.com/company/stripe>) and assumed that was the logo.

</comment></comment></comment><comment><USER83> I've been watching Stripe for a future project that is looking more and more likely ... but this looks so good, I might do the project just to have a reason to use Stripe! (j/k)

Can't wait to see how the international version works.

</comment><comment><USER84> Is there a processing volume limit? Will Stripe be verifying customer orders?

<comment><USER9> There are no volume limits. What kind of verification are you talking about? Stripe does offer address verification: if you send the address with your requests, we'll return the AVS response from the credit card network, which tells if that the billing zip codes and street number are a match.

<comment><USER84> What about sales receipts? Are those generated by Stripe and sent to the user or is it up to the merchant to deliver them?

<comment><USER9> We don't offer support for emailing your users right now.

<comment><USER84> How long does it take for a refund to be re-credited to the user's card? What's the chargeback threshold before an account gets put on hold? Is there a refund threshold? Eg. 1 out of 4 of our customers are dissatisifed with our product, so we refund 25% of all transactions.

Also, you've created something absolutely amazing. ISO Sales agents across the country are going to be trembling.

Speaking of which, will you have a partner program?

<comment><USER40> The amount of time it takes fro the refund to be re-credited usually depends on the issuing bank. When a refund happens, we send the refund over immediately and settle it at the end of the day. There are currently no chargeback or refund thresholds, but we'll have to see how that evolves as we grow.

We don't currently have any partner program, but it's definitely something we're talking about. Lots of things are in the pipeline!

</comment></comment></comment></comment></comment></comment><comment><USER85> Amazing product, just curious about which font was used in the stripe logo?

</comment><comment><USER86> Hope you go international as soon as possible there is a lot of good potential around this. I just hate the way paypal has recurring billing setup, the documentation is not 100% completed in paypal and I had to loose a couple of hours to ge around an error that was saying basically: " there are 1000 things that could go wrong ", the problem is that I was missing a field that I had to submit to them, the docs war not saying anything about it, but with the help of good old Google. Go stripe

</comment><comment><USER87> Awesome. I have been waiting to have a better look at Stripe, it sounds so great.

I have a question for someone who might know: how can Stripe operate without requiring it's users to sign up for a merchant account? Do they hold what is known as a 'master merchant account'?

I am just curious as these sound notoriously difficult to get and might explain why it's US only for now, not to mention the AML considerations of letting users sign up and accept payments so simply.

This all just makes what they are doing even more impressive :).

<comment><USER40> We basically are trying to abstract away all the pain of creating merchant accounts and setting up with separate payment gateways. On the backend, we are partnering with Wells Fargo and First Data to set up whatever accounts are necessary to both get you started immediately while making sure you get all the benefits of a full-fledged merchant account.

<comment><USER87> Cool. I'm not a US citizen but it's great that you can do this and that Wells Fargo is on board as this is a killer feature in my opinion :).

</comment></comment></comment><comment><USER88> Excellent API and fast support. These guys are gonna go far.

</comment><comment><USER89> Good to see an alternative to paypal, but instead of paying 3% to a transaction central, I'll still offer a 5% discount to anyone who pays me through bitcoin.

</comment><comment><USER90> I tried stripe a couple months ago and I was unimpressed. Mostly it was the pricing ( i think at the time it was 3.9% + 30 cents ) because I was looking to do smaller transactions $4.99 a month subscription.

But I got into the beta anyways and started playing with it. Within 10 minutes a rep was emailing me trying to get more information and that I wasn't ready to give out.

I ended up going with Paypal's micro transaction processing.

<comment><USER9> Our account application asks for your personal information (thinks like bank account details, home address, etc.) as part of our automated verification process. Once it gets submitted, we try to verify and approve the application as quickly as possible, hence the quick contact.

Of course, you don't have to submit this application until you're ready. You can save your account on Stripe without filling out the account app, and do as much testing as you like, forever. Once you're ready to process real payments, that is when we'll require some of this information.

Hope that helps explain things.

</comment></comment><comment><USER91> This is awesome. The big question is: how are you going to deal with fraud? Fraud policies false positives is largely what makes people hate PayPal.

<comment><USER9> I think the difference is customer service, not fraud per se. Customer service will always be our highest priority -- and that means when we do end up in situations where fraud is a concern, we'll work with our users to resolve things quickly.

</comment></comment><comment><USER92> I don't have anything to contribute other than a thank you to the folks behind Stripe for trying to fix this seriously broken system.

</comment><comment><USER93> This is exactly what I have been looking for. I only wish you guys had a micropayments model as well. Any future plans of that?

<comment><USER9> It's something people are asking for, so we'll be looking into it.

</comment></comment><comment><USER94> If a Stripe employee is reading this, tiny suggestion: I just shared the URL to stripe on both Facebook and G+. On G+, the nice little blueprint icon showed up as the thumbnail. But on Facebook, no icon at all making the post far less noticable in people's feeds. Just a tiny thing that will help the spreading of the word.

<comment><USER41> Thanks, fixed.

</comment></comment><comment><USER95> I'm not a developer, but I am considering selling things through my website and maybe also selling things in person outside any shop. Is there any particular reason I would pay a developer to build this into my site rather than just using Paypal (which I've used for years and had no big complaints with) and/or Square?

<comment><USER40> You would use Square for your in-person payments (Square, so far, is for brick-and-mortar stores whereas we are doing online payments). But we definitely are targeting developers more currently, so can see why we may not be as easy of a choice for you. We do offer quite a bit of analytics around what you are making and being paid out, and we also give you a viable way to get set up easily with minimal PCI compliance without having to use a hosted payment solution (so customers checking out wouldn't be sent to another website, which I believe PayPal's hosted solution does), so these features may appeal to you.

</comment></comment><comment><USER96> We're incorporated in Hong Kong. I'm beginning to think we should launch a US subsidiary just to take credit cards...

</comment><comment><USER97> Stripe was like love at first sight, it was exactly what I was looking for a loooong time, but I can't use it for now apparently :(

Two questions: My company is an LLC and I have a valid SSN, however my bank account is in Portugal, can I still apply for stripe ?

If not, do you have plan to support EU countries like Portugal ? thanks

<comment><USER9> You should email firstname.lastname@example.com for specific things like this.

</comment></comment><comment><USER98> This looks amazing. @boucher, sounds like support for Canada and the UK is in the pipeline, how about other EU countries such as Germany?

In the meantime, can somebody recommend a (vaguely) similar service in/for Germany, or otherwise an old-fashioned payment processor that's less painful to deal with than others?

<comment><USER9> Germany is definitely on our list, thanks!

<comment><USER99> Can you share list of countries you expect to be supported "real soon now"?

It would be helpful to know if I should keep an eye on your service, or just forget about you fro another year or two.

</comment></comment></comment><comment><USER100> Can someone please explain to me how 2checkout couldn't do this? For example they claimed to be pushed by the card companies to become a "reseller", resulting in the fact that their checkout pages cannot be customized. What gives?

</comment><comment><USER101> I see the Getting Started developers intro, but I'm having trouble visualizing what this can look like purely from the customers side. Do you have any live implementations you can link to as an example of a Stripe integration?

<comment><USER9> Stripe doesn't communicate directly with your users, so there is no standard look from a customer's perspective. We're providing the tools to build your own payment forms hosted on your own website. Perhaps in the future we'll look into helping by communicating more directly to customers.

</comment></comment><comment><USER102> Stripe looks great and is definitely at the top of my list. Does anyone know what name shows up on the customers statement? Is it customizable to something that includes your company name (e.g. Stripe __your_name_here)?

<comment><USER9> Stripe doesn't appear at all. You have full control over what appears on the statement.

<comment><USER103> These little touches are awesome. With Auth.net it seems I ran into a character limit with my (not very long) company name, and the beginning was truncated - TopHat became Phat... I tried to get it changed once upon a time, but I gave up due to the pain.

The old 1 month payout schedule was one of the few things holding me back from switching, but now that's it's more frequent, count me in!

One question, can one charge from multiple URLs with a single account?

<comment><USER40> You can charge from multiple URLs, but all your data will show up together as if it were for one account. If you want to have multiple accounts for different websites, your best bet currently is to just sign up multiple times (we're working on having subaccounts).

<comment><USER103> Great, that's fine for my purposes. Thanks!

</comment></comment></comment></comment></comment><comment><USER102> Stripe looks great and is definitely at the top of my list. Does anyone know what name shows up on the customers statement? Is it customizable to something that includes your company nane (e.g. Stripe __your_name_here)?

<comment><USER104> It's entirely up to you: there's no mention of Stripe. Most of our customers simply put their domain on the statement.

</comment></comment><comment><USER105> Been using Stripe for Taskforce for a few months now. Stellar API, stellar service.

</comment><comment><USER106> Well done lads! Just on their customer service - really great. I'm a novice developer hacking together my first webapp and the people I dealt with at stripe were excellent, very patient and helpful. Best of luck with it.

</comment><comment><USER107> Goodbye recurly and chargify. You're no longer the prettiest girls at the dance.

</comment><comment><USER108> Will strip offer hosted page in the near future? We are currently using Spreedly's hosted page for customer to input their credit card info so that we don't have to worry about SSL and other security issues?

<comment><USER9> We may at some point in the future, but it's unlikely to be one of our short term priorities. Stripe.js does make things easier for you, but you'll still need SSL.

</comment></comment><comment><USER109> Just curious, how does the gambling industry manage payments? I've been thinking about building a poker saloon and would like to know how to get players to put their money on the table, so to speak.

</comment><comment><USER110> Any plans for supporting a DBA (doing business as) field as part of the API? Having only one identity associated with the Stripe account wouldn't cut it for us.

<comment><USER9> For now, we recommend just setting up multiple Stripe accounts; it's a feature I'm sure we'll add in the future.

<comment><USER110> In our particular case we would need somewhere between 50 or more accounts, so it's just not feasible. Having it as part of the charge API would be ideal. Glad to hear you're considering adding it as a feature.

</comment></comment></comment><comment><USER111> echoing the excitement for the international expansion.

</comment><comment><USER112> Is the TOS(Terms of Service) a work in progress? Currently "not found."

<https://manage.stripe.com/tos>

<comment><AUTHOR> Sorry about that. <https://stripe.com/tos> is the correct link. We'll get it fixed.

<comment><USER112> Thanks for the update. I did have one other question and wasn't sure where to post it here. What's your timeline for a Perl API binding?

<comment><AUTHOR> We're not working on it right now, but would love to discuss. I'm email@example.com -- want to drop me a line?

</comment></comment></comment></comment><comment><USER113> Having the sample code right there on the landing page is the most compelling thing for developers, when the customers are developers.

</comment><comment><USER114> Anyone here use WHMCS? (Whmcs.com) I'm curious if Stripe will work with it since it doesn't send the CC# through the server.

</comment><comment><USER115> Stripe is going to be huge. Theirs is a MASSIVE market, waiting too long to be disrupted. Can't wait to use the service.

</comment><comment><USER116> Is this real? Am I dreaming? This sounds too good to be true. Someone pinch me, please. (Is there an app for that?)

</comment><comment><USER117> looks great, though recurly has met my needs so far, not sure what would make me consider porting over to something new

<comment><USER9> The difference between Stripe and Recurly is that Stripe is dealing with the full payments stack for you. You don't need a separate merchant account or gateway, and it's just one flat fee of 2.9% and 30 cents per successful charge, including our subscription billing services. As a result, it's often quite cheaper than combining several separate services.

<comment><USER117> Thanks for the details. Merchant account setup with intuit through recurly was very easy though, we had that setup within a few hours. At this point, sounds like stripe would be cheaper though (~50 paying customers at $40 a month).

</comment></comment></comment><comment><USER118> off-topic: Stripe looks really nice and I wish I could use it but sadly I'm outside USA. Does anyone knows a service like this that doesn't require a bank account? Let's say I want to charge people in USA but I don't have a bank account in USA, then I would transfer the money to Paypal or something. Any thoughts?

<comment><USER119> If you're transferring the money into Paypal anyway (and exposing yourself to "the paypal risk"), why not just use Paypal Website Payments Pro?

</comment></comment><comment><USER93> Are you guys looking for investors?

</comment><comment><USER120> Question for boucher: Can stripe be used for affiliate payments, perhaps by issuing credits?

<comment><USER9> Probably best to send an email to firstname.lastname@example.com to figure out specific cases like this.

</comment></comment><comment><USER121> Just make sure you still do your PCI compliance audit if you use Stripe.

<comment><USER40> You actually don't need to do anything beyond what we tell you to do for PCI. Check out stripe.js. No need for an auditor.

</comment></comment><comment><USER122> this looks amazing but i cant use this until you support european/canadian/australian payments. both of the e-commerce stores i run get international orders every week.

</comment><comment><USER123> I'm all over this as soon as Freshbooks supports it.

</comment><comment><USER124> Thank you Stripe. We will become good friends.

</comment><comment><USER125> Please come to Australia! We need you!

</comment><comment><USER126> I really wish I could use this in EU.

</comment><comment><USER127> It seems great, until you read the fine print, which I did, in its entirety, and what I saw is quite chilling, in terms of fees, fines, and other undefined costs incurred when things go horribly wrong.

"When a Chargeback is issued, you are immediately liable to Stripe for the full amount of payment of the Chargeback plus any associated Fees, fines, expenses or penalties (including those assessed by the Networks or our payment processors). You agree that Stripe may recover these amounts by debiting by means of ACH debit of your Bank Account associated with your Stripe Service Account, debiting your Reserve Account, or setting off any amounts owed to you by us. If we are unable to recover funds related to a Chargeback for which you are liable, you will pay us the full amount of the Chargeback immediately upon demand. You agree to pay all costs and expenses, including without limitation attorneys' fees and other legal expenses, incurred by or on behalf of us in connection with the collection of any unpaid Chargebacks unpaid by you."

<https://stripe.com/tos>

I >do< like the positives of Stripe, but I'd feel more comfortable if I knew how Stripe would handle specific extremes, such as the one about which I had recently asked.

<http://news.ycombinator.com/item?id=3039782>

<comment><USER9> As you noted in your post, these terms are standard (and, essentially, required of us) in this industry. And as people suggested, chargebacks are not a big deal. They are far less common than people think, and usually they are resolved quite easily; all it takes is good communication.

<comment><USER127> I appreciate the answers given to my question from several days ago. I appreciate that all of the loopholes need to be covered, using >standard< legalese, most of which will never be needed, but when it is, the situation will be resolved entirely in Stripe's favor, not mine. I appreciate that chargebacks are >usually< not a big deal. My concern is about extremes, particularly those which come out of malicious intent, perpetrated against me, through no fault of my own. With the way that these "one-sided" agreements are structured, it appears to be quite easy for me to launch an attack against a small startup's credit processing account, with the likely result being termination of said account, mostly due to the perception of risk which I will have created in the minds of the people who implement the TOS to which the startup agreed. If I can do this to someone's startup, then someone can do it to mine, and I can't be the only person who has thought of this kind of stuff.

<comment><USER9> And yet, have you ever heard of this happening? I don't mean to minimize your questions; I think there is some amount of trust involved. We're able to tell the difference between someone running a fraudulent business and someone who is being essentially DOSd. Simply having chargebacks is never going to automatically cause your account to be terminated.

<comment><USER127> "Simply having chargebacks is never going to automatically cause your account to be terminated."

False: "WePay reserves the right to close or put a hold on any account that has generated a ["a", as in "single"] chargeback." - <https://www.wepay.com/about/terms>

No one talks about the ugly fine print. It's always "just a formality", until they need to use it against you, and that's exactly the kind of leverage a competitor or an enemy will seek out.

<comment><USER9> Well, to be clear, I'm only speaking about our own service, not WePay. Anyway, I think we've covered the issue here but if you feel like you need further discussion I suggest reaching out to email@example.com.

<comment><USER127> "I'm only speaking about our own service, not WePay."

Really? See: "We can terminate this agreement at any time (especially if you do something bad). Termination is effective immediately. Termination does not alter your liability for processed payments or related chargebacks." at the top of <https://stripe.com/tos>.

I won't bother with support, because you have not given me any real answer to the scenario which I presented. Your system thus appears to be just as easy to defraud as any other, possibly even easier, so I have no reason to trust an entity which can, and likely will, dip into my bank account to extract all sorts of fees and fines when things do go bad.

</comment></comment></comment></comment></comment></comment></comment><comment><USER128> EDIT: removed so as to not hijack another announcement. Was not the intention, just wanted to offer something people thought was useful.

<comment><USER129> Do you do recurring billing? It's not clear with a quick view of the documentation. Or do you expect that individuals are provided sufficient information to build their own (easy?) recurring systems? If you do, we'll look at moving immediately. We'd not only be saving money but your API doesn't confuse the hell out of my like what we're currently using.

<comment><USER128> You got it. We don't handle the recurring stuff for you, but we give you back a token that lets you bill your customer cards on a recurring basis. We have other customers who are doing this on their own.

<comment><USER129> Thanks, that's probably fine as we'd get better control over integration.

</comment></comment></comment></comment><comment><USER130> Just wanted to say you guys were one of the few "startups" I actually gave my email to in the beta page when you announced it. I could care less about the next social app, or next reminder app but as soon as I saw your value proposition, I KNEW I had to be notified when it was out. Thanks for making something that actually solves a crucial problems. This is much much needed, and you guys are definitely on your way to success

</comment><comment><USER131> I think that aside from the lack of support for marketplace, like <https://www.wepay.com/developer/usecases/marketplace> Stripe is awesome.

Any plans to add marketplace support in the near term?

Also are you guys PCI compliant yet?

<comment><USER9> We're certified as PCI Level 1 Compliant (the highest level). You can definitely build a market place on top of Stripe. We don't, at the moment, have an easy way for you to take money and then pay it out to other people, but if you're able to handle that step on your own then Stripe can be a great way to collect payments for your marketplace.

<comment><USER131> Is it on the roadmap for the near future?

<comment><USER40> Possibly -- it's something we're still talking about internally.

</comment></comment></comment></comment><comment><USER132> Thank you. Pay pal should be obsolete now.

</comment><comment><USER133> Bitcoin charges 0.01% @:)

</comment><comment><USER134> CANADA!!

</comment><comment><USER135> Looks like the site is down??

</comment><comment><USER136> 2.9% and 7 days. if you are still using it, you are infant in this entire thing.</comment>


ES6 modules are dead, long live C preprocessor - <AUTHOR> https://rreverser.com/es6-modules-are-dead-long-live-c-preprocessor/ <comment><USER2> White-on-light-blue text is not legible. I tried highlighting it, but the highlight color is an equally illegible white-on-light-pink.</comment>


The dark future of American space exploration - <AUTHOR> http://www.vox.com/2015/2/23/8052365/nasa-budget-europa?utm_medium=social&utm_source=twitter&utm_campaign=vox&utm_content=feature-share-top <comment><USER2> The real missing part of this article is that NASA's budget is dominated by building launchers. If all NASA did was build payloads and buy launch services, it would get a lot more done for its dollar.

In the short term this is not feasible, but we are on track for it happening in the next 10-20 years. I think we'll have many years of SLS/Orion, but that is probably the last NASA launch system. Once NASA gets out of the launcher building business, the entire enterprise because much more viable. The cost of any particular mission is not terrible, and if any single mission fails it's not the end of the organization. If the launch program fails, NASA gets off track for a decade. Effectively the Space Shuttle was a slowly unfolding 30 year failure that pushed NASA off course for decades.

<comment><USER3> I think you are right that building launch vehicles consumes much of NASA's time, money, and focus, and that private launch systems will relieve NASA of this burden (if they accept the relief).

I do not think this is NASA's main problem, as they were able to create launch systems while performing exploration in the 1960s. It seems that they lost their way after Apollo, when NASA no longer had a clear priority. NASA is now dominated by internal politics, where each center tries to run its own projects, and there is no overarching goal. If NASA had one main program, it would be more visible to the public, and have a greater chance of success on a realistic timeline (5-10 years), though NASA would risk complete defunding if there were problems with the project.

Mars in the short term (5-10 years) is a realistic goal (under their current funding levels) which could get NASA started again, but it would require them to sacrifice a variety of smaller projects which have strong internal lobbies.

<comment><USER4> They didn't lose their way. In the Apollo years you're talking about, NASA enjoyed as much as FIVE PERCENT of the federal budget.[0] You can build all the Saturn V launch vehicles you want when the government is throwing bags of money at your particular problem.

[0] [http://en.wikipedia.org/wiki/Budget_of_NASA](http://en.wikipedia.org/wiki/Budget_of_NASA)

<comment><USER5> Their budget during the Apollo program was 50% higher than it is today. I don't think funding is the primary problem.

<comment><USER4> Technology is more expensive. The projects themselves are more complex and machinery more expensive. You can build an antenna with pocket change that will let you talk to someone on the moon, but you need some serious hardware to talk to something on Mars, let alone further out. Plus the bureaucracy -- the oft-referenced bureaucracy -- is grinding more and more to a halt. It's more expensive from a bureaucratic standpoint, with more layers of management slapped on layers of management. The NASA of the 60s was an entirely different creature. We would do well to try to get that back, but honestly, really I think it's too late for that. I think honestly it's out of the American government's hands what happens in space over the next 50 years, barring another space race with China (fingers crossed). American commercial interests? Maybe. But our government just grinds to a halt when it needs to get anything done.

<comment><USER5> It seems that you agree with me that funding is not NASA's primary problem (I think I am actually more optimistic about NASA's competence). The point I disagree with is "Technology is more expensive". Technology has gotten dramatically cheaper (though I agree that current projects are more difficult). We have better materials, better manufacturing techniques, better computers and all of it more affordable than it was in the 1960's. Look at what SpaceX was able to do; in their first 10 years their total expenditures was only $1 billion, a small fraction of what it would have cost half a century ago.

</comment></comment></comment></comment></comment></comment><comment><USER6> <meta>

I am beginning to feel that Vox is more of a time-sink than a useful addition to my regular feed. This article is an example of why. It's long format, goes over well-trod ground, adds in some items that are politically interpreted a bit heavily, and ends up kicking off partisan discussions that don't go anywhere.

They're like Op-Ed columns presented in Wikipedia format. If we had a thesis and supporting arguments you would at least know what you're dealing with and engage it on its own terms. But as it is, you're left either accepting this huge hunk of text or going through half a dozen items to nitpick it to death. Either choice is suboptimal.

</meta>

I'm a huge supporter of the space program. NASA lost its way a while back, like the 1970s, and is not the right tool for the job we have. It's no fault of NASA's -- every new administration and every new Congress feels free to whipsaw it into a new direction.

We have some clear foundational science goals that NASA could supervise other competent organizations doing, like reducing cost-to-orbit 100-fold (mass- drivers, anybody?), creating a cheap, mass-production radioactive battery that can be used everywhere, or rewarding the first team to optically-image an earth-sized habitable exoplanet.

Writing NASA a check won't help much of anything, because five years from now the money will all be re-allocated various political ways. Yes, I grok the multi-year planning thing. Not germane.

<comment><USER7> So what kind of organization(s) do you see doing a better job than Nasa? I would agree that it's a political and rather inefficient organization, like any government-funded agency, but I'm curious how exactly we could improve.

Bear in mind that many of Nasa's best projects were undermined by politics. A new Administration comes into power vowing to re-prioritize spending, and Nasa's champions within the White House and Congress are suddenly without jobs. A recession hits and Nasa is an easy target for budget cutters. A Congressman threatens to withhold spending unless Nasa locates a facility in his district. You can't fix this stuff; it's part of the landscape.

<comment><USER8> The ideal would be for someone to figure out how to make money in space. Once you harness the mighty power of greed, nothing short of all-out war would be able to keep humans out of space. But that's proved to be a bit of a tall bar, unfortunately, which in itself sort of raises questions about the actual utility of space anew after 50 years. But before quite making that call let's see what knocking another order of magnitude off launch costs does for us.

But I find myself often thinking that space just isn't viable for very many uses without a still-higher level of technology than we have.

<comment><USER6> Agreed that we really need to knock a couple of more digits of cost-to-orbit before we can make any kind of informed decision one way or another. Also agreed that it's not looking good so far.

Mass drivers could send cargo into orbit cheaply -- perhaps given the right cargo/human ratio, you'd end up with a drastic decrease in cost overall, especially with reusable rockets.

Right now there's just no there there. Most of the great arguments for getting off the planet are 1) Science! and 2) We need to get the heck out of Dodge before we kill ourselves. These are very good reasons, but it's like pushing a rope -- you'll never make space exploration happen by lecturing people and taxing them for it. Instead put some greed into the mix. If you find a big enough pull, then you'll see the dynamics radically change.

Space needs an 1849 Gold Rush.

</comment></comment></comment></comment><comment><USER9> I'm beginning to suspect that the powers that be in American politics and in the military industrial complex simply lack long term vision.

In the next several decades following, continued US dominance is dependent on effective education and a strong economy supporting a healthy middle class. In the next several decades after that, whatever nation/culture succeeds in expanding the scope of human civilization is going to dominate through its progeny. (In much the same way that European and in particular WASP culture that originated in England became dominant through the ascendance of the United States.)

However, the system is set up to reward those who enter the financial sector, with its tendency towards rent seeking, and the realm of law/politics, which tends to engender a viewpoint somewhat distant from the first principles that govern reality.

China, with its largely technocratic leadership, and with its pent up desire to express its pride and prowess as a civilization-state may well have the means, knowledge, and impetus to engage in such an expansion of scope. This would be the smart strategic move -- instead of directly challenging the US for power on Earth, they would expand into an even larger context.

Another beauty of such a strategy: the entrenched short-term interests of the US military industrial complex might well assist them in gaining an insurmountable lead by staying fat and happy in their status quo.

<comment><USER10> Oh I am quite sure the powers that be have long term vision, they just don't align with some of what we want. They are quite willing to promise the moon and the stars; not the celestial kind; because it works.

Space exploration does not garner votes, raw science does not garner voters, and neither do they garner blue collar jobs. Politicians route money to where it buys them most influence. They rely on this money and positioning people against each other to maintain their standard of living. See, they are safe and the masses will stay in their irrational world grousing about the lack of change they do little to change.

They count on the irrational decision, the rally behind a thousand page health bill no one reads, the three hundred page net neutrality bill no one is allowed to read, and they make sure you don't want to by portraying the challenge to such as an affront to privilege and intelligent and we want to be considered both. After all, if they tell us its not smart to do otherwise well those who say otherwise must be wrong.

So they play the people off each other while they keep their backroom deals and move along merrily laughing at an electorate whose current concern is their internet connection so they don't miss the latest streaming movie.

Who needs space exploration when Game of Thrones is on.

<comment><USER9> _Oh I am quite sure the powers that be have long term vision, they just don 't align with some of what we want._

Everyone _thinks_ they have "enough" long term vision. I'm sure many of the Roman emperors who we now think of as being short-sighted thought they had it all figured out in the way you outline above.

</comment></comment></comment><comment><USER11> I've always been of the opinion that if it were left up to the private sector we wouldn't have gone to the moon or placed a human in orbit. The project would have been too long term, too risky, and have no obvious return on investment.

Which is pretty sad as if think about given the number of technologies that were developed for the Apollo program that the private sector went on to make a bundle of cash out of and the number of industries (computing for one) that were spawned as a result.

<comment><USER12> This is a great point.

However, what do you do about the gross inefficiencies of a government organization? I worked for 13 years in the public sector and saw first-hand the layers-upon-layers of management and entire management entities, while undergrads, grads, and a few unsung full-timers actually accomplished the little work that got done.

A massive public organization like NASA simply cannot get anything done for a reasonable budget. Unfortunately, sub-contracting work like we do with Boeing & friends seems to result in just-as-wasteful spending. Outside of the discovery of a commercial incentive, it seems that NASA is still our best hope for getting useful science done, inefficiencies and all.

<comment><USER11> I've seen equal or worse inefficiencies in the private sector.

While the root causes may be different, a badly managed organization is the same whether it is public or private.

<comment><USER5> While their are also massive inefficiencies in the private sector, the public sector does not have the same ability to fail. Those private companies need to be efficient enough to avoid bankruptcy.

<comment><USER13> Note that some of the private sector can't fail now either.

</comment></comment></comment></comment></comment><comment><USER7> Well, this author has a rather pessimistic view of things. In fact, we are a couple of years away from a major change of government in the U.S. and whoever succeeds the Obama Administration will have an opportunity to address the shortcomings of the space program.

The Obama Administration has focused on domestic social issues like jobs, education, and health care, and deemphasized longer term programs like Nasa.

Typically, the pendulum swings back and forth with space and science allocations, and I would expect an adjustment upward in the next couple of years even as the social spending is inevitably cut.

Also, as the U.S. economy comes out of the 2008-2010 recession and starts to generate more government revenue, it will become politically easier to re-fund some of these mothballed or back-burnered programs and get Big Space back on the front page.

Americans love cool space stuff. The entire Baby Boomer generation grew up with the 1960s-70s manned programs and these things are near and dear to their hearts.

I was a 10-year-old boy when men first walked on the moon, and my friends and I all had model rockets, Nasa posters on the wall, and dreamed of becoming astronauts some day. We all assumed that the country would just keep on funding more exploration until we had a massive rotating space station in orbit, a permanent base on the Moon, and probes reaching to every corner of the star system and beyond.

Very little of that has come to pass, and we are a poorer and less accomplished nation because of it. Nasa indeed should be getting more than $18.5B, in my opinion more like $50B or $60B. It's a great investment.

Sure, let private companies try to jump into the satellite launching business, more power to them. But the heavy lifting has got to come from Nasa, that great organization that has been neglected for too long.

<comment><USER14> > Americans love cool space stuff.

So I'd like to believe that. But my conclusion based on studying the relevant history is that it was fear which motivated Americans to spend the money for space exploration.

When Sputnik launched in 1957, it threw Americans into a panic. Here was a Soviet god-knows-what that you could see from your house in Kansas. The Soviets beat us to nearly every milestone: first satellite, first animal in space, first man in space, first EVA, first probe on the moon. The Soviets' first manned lunar landing was scheduled for 1968, but the architect of the program died at an inopportune time in 1966. The need to keep up with or beat the Soviets is what drove the space program until 1969.

I don't think we would've gone to all that trouble if we didn't have the Red Empire breathing down our necks.

<comment><USER7> Obviously, it was international politics and Cold War thinking that woke a fire under the Americans in the late 1950s. But that has little to do with what I'm talking about.

The Boomers, who are the predominant generation today, grew up on Ray Bradbury and Isaac Asimov, Star Trek and 2001 and model rocketry. We lived and breathed space exploration.

There is a huge ready-made audience for more great achievements in space. We need national leaders who can inspire the voters to allocate the funding. The last few presidents haven't been very enthusiastic. G.W.Bush actually did have a vision of replacing the Shuttle, but unfortunately he didn't lock in the funding for the replacement Orion/Constellation systems before his term ended, so the U.S. ended up with no means to get humans into orbit, a rather embarrassing predicament for the world's erstwhile leader in space travel.

<comment><USER14> None of the presidents from that generation have invested in space exploration, nor has there been any public call for them to do so, so I'm doubtful very many boomers "lived and breathed space exploration" although many certainly did.

I'm sympathetic to your point. I majored in aerospace engineering in college because I grew up reading books that told me we'd be going to Mars any day now. But in the process, I became convinced that nothing would happen in that field for the foreseeable future, and probably nothing economically worthwhile in my lifetime.

</comment></comment></comment></comment><comment><USER15> I explain this by the lack of competition. Rest of the world is not making anything comparable to what NASA does. Only Japan's Hayabusa is remotely close to a typical NASA mission. Nobody can say 'our nation is lagging behind in planetary missions' so politicians are happy and prefer to concentrate funding on more pricey things having less real scientific impact, like manned spaceflight, where there is really a lag to be fixed.

</comment><comment><USER16> Interesting that they don't mention SpaceX. One of the profound changes is that in 1962 it took the resources of a nation-state to send a probe to Mars, now someone in the 1% bracket could fund something equivalent without disturbing their kid's trust fund. That is pretty profound.

We will get on-orbit refueling. Once we get there you can launch pieces, assemble and fuel in orbit, and then head out to where ever you want to go.

The interesting question is what happens when it becomes clear that the space faring capability of a corporation exceeds that of the government. Over regulation I suspect.

</comment><comment><USER17> Maybe better to solve global warming before we chart out every square inch of our solar system. It's pretty clear that there is way more life on Earth than the other planets. Too bad because the life here is under extreme threat. You don't need to look far. Species going extinct. Rain forests converted into palm oil plantations. coral reefs bleached. And now the possibility of runaway climate change.

There are only so many brainy people on the earth. Better that they focus on these more immediate problems at hand.

Space exploration is probably just a distraction from the much more pressing problems of the day.

<comment><USER18> We hardly spend anything on space exploration. Not to mention it has a lot of benefits and carryover to the rest of the economy. If we have to make cuts, there are many other places we can target instead of the .5% of the federal budget to NASA.

<comment><USER13> If the benefits and carryover paid for it, fine. But I doubt it, not now anyway. If it wasn't borrowed money, I'd say throw .5% at at it. But no way when it's borrowed, unless it can be proven beyond doubt that the outcome is net positive.

<comment><USER19> I really wish we could retire the word "borrowed" to describe the nature of sovereign debt. It makes it sound like we're borrowing dollars from the Chinese to pay NASA. That's not how it works. (United States currency is one of the few things that isn't made in China these days.)

<comment><USER13> Are you suggesting there are no adverse consequences to the "borrowing", similar to borrowing?

</comment></comment></comment></comment></comment><comment><USER20> This article skews towards trying to make a political point, but it does so at the cost of truthfulness. It lays an elaborate case before the reader, detailing the woeful state of NASA interplanetary science and the assumed perfidy of a stingy congress.

This is a narrative that has only the slimmest hold on reality. Congress has done reasonably well at keeping NASA funded, with some occasional road bumps here and there. And certainly at a lower level than what many of us who value planetary exploration particularly highly would like. But still not too bad all things considering.

The real cause for the pinch in planetary science is NASA itself. It has indulged in undisciplined budgetary behavior and project planning at the cost of diversity and robustness in its science missions.

The major cause of these problems is something that is not mentioned once, even in passing, in this entire article: the James Webb Space Telescope (JWST). As of right now JWST is more than $7 billion over budget and 8 years behind schedule. That $7 billion compares to: 1 Curiosity rover ($2.5 billion) plus 2 Dawn double asteroid rendezvous missions (2x $500 million, 4 total asteroidal bodies visited) plus 1 Cassini mission ($1.4 billion) plus 1 New Horizons mission ($650 million) plus 1 Kepler mission ($550 million) plus an entire extra billion dollars. That's an exciting panoply of opportunities, and imagine those figures in the context of similar classes of missions. Ion engine powered comet-survey missions, planetary landers and rovers, Kuiper belt flyby missions, survey missions to Neptune and Uranus, exo-planet searches, and so forth. To say that NASA's space science missions have been sucked dry of funding is to ignore _why_ and toward what end they have been.

Make no mistake, JWST is a remarkably ambitious mission that is likely to be as groundbreaking as Hubble was, but it is absolutely squeezing the life out of the rest of NASA right now. It would be nice if congress would provide even more funding for NASA so they could go forward with JWST as well as other missions, but to implicate congress as a villain depriving NASA space science of life is to ignore the reality of the situation. This is a self-inflicted wound.

[http://articles.latimes.com/2013/jan/08/science/la-sci-sn- aa...](http://articles.latimes.com/2013/jan/08/science/la-sci-sn-aas-nasa- james-webb-space-telescope-astrophysics-budget-20130108)

[http://blogs.agu.org/martianchronicles/2012/02/14/proposed-n...](http://blogs.agu.org/martianchronicles/2012/02/14/proposed- nasa-budget-cuts-mars-exploration-by226/)

P.S. Moreover, the doom and gloom tone of the article is unwarranted. Regardless of either NASA budget mismanagement or congressional stinginess the capabilities of NASA in regards to exploration are set to vastly balloon due to the incredible reductions in launch cost on the horizon (from SpaceX and others).

</comment><comment><USER21> I am strongly in favor of boosting NASA's budget, but the US still spends more on space than every other nation combined so I think saying it has a dark future is a bit hyperbolic.

[http://www.washingtonpost.com/blogs/wonkblog/wp/2014/10/25/t...](http://www.washingtonpost.com/blogs/wonkblog/wp/2014/10/25/the- u-s-still-spends-more-on-space-than-every-other-country-combined/)

<comment><USER7> China's spending isn't very transparent, and their costs are much lower, so dollar-for-dollar they are accomplishing more than Nasa is. And they're not just screwing around. They're planning to put humans on the Moon in a few years, which implies a huge and well funded effort.

<comment><USER21> That is a good thing, the US could use some credible competition.

</comment></comment></comment><comment><USER22> NASA isn't the end-all organization for space exploration.</comment>


Pachyderm v0.5: Single Node Mode - <AUTHOR> https://medium.com/pachyderm-data/pachyderm-v0-5-release-a-more-tightly-pached-derm-25023bc51f8e

<comment><USER2> Pachyderm writes some really good blog posts that are worth checking out:

[https://medium.com/pachyderm-data/when-grandmasters- blunder-...](https://medium.com/pachyderm-data/when-grandmasters- blunder-a819860b883d)

</comment><comment><AUTHOR> Founder here. We'll be around all day if you have any questions about Pachyderm.</comment>


Java.next() - JRuby: The Rubyists Strike Back - <AUTHOR> http://batsov.com/Ruby/Java/2011/05/18/jvm-langs-jruby.html Part 4 of the Java.next() series. An overview of JRuby - a Java implemenation of Ruby <comment><USER2> One of my first questions was where is JRuby is in use, and I figured linking to the JRuby success story page was in order:

<https://github.com/jruby/jruby/wiki/SuccessStories> [http://stackoverflow.com/questions/615825/is-jruby-ready- for...](http://stackoverflow.com/questions/615825/is-jruby-ready-for- production)

I remember someone mentioning that a major benefit of using JRuby was the stable DB driver implementations. Just don't remember where that comment came from.</comment>


Submit GitHub issue via Twitter - <AUTHOR> https://twitter.com/githubissue <comment><USER2> That is a pretty cool idea.</comment>


Node.js based jsdom 0.2.0 released, now with full dom level 2 & 20% faster - <AUTHOR> https://github.com/tmpvar/jsdom

<comment><AUTHOR> For anyone that wants to see a detailed changelog: <https://gist.github.com/833296>

I really like the addition of .env because it simplifies the code required to do what most people use jsdom for. The speed improvements are welcome.</comment>