pc

We'd be very happy to support PayPal in the same way. If any PayPal folks are reading, I'm patrick@stripe.com :-).

Oh, I think it is a peer discussion forum, first and foremost, and shouldn't be treated as a communication/acquisition channel -- which is why I think that having threads veer off into the competitive weeds does the forum a disservice. (As a reader, I find it kinda tedious when it happens in other threads.)

> There are also multiple ways to build this kind of feature.

It sounds like both Balanced and Stripe will use them :-). But let's not turn this into a Balanced vs Stripe thread. It's not especially relevant for users and we'll stay out of the way when you guys have your public launch. Continued good luck!

Hm. There are actually a bunch of inaccuracies in the above, but I don't think there's much point arguing about the details -- specifics aside, I agree that Balanced has quickly launched some cool stuff. Congrats on your time at Balanced and good luck with whatever comes next!

Right now, most of our marketplaces' sellers seem to prefer using their regular bank accounts rather than Bitcoin. But if/when the Bitcoin revolution happens, we'll enthusiastically support that too. (We're running a Bitcoin acceptance beta right now: https://stripe.com/bitcoin)

For sure; they're different -- our argument isn't that ISPs should treat traffic equally for reasons that apply to Stripe. In mentioning Stripe, I think Jon was simply saying that we spend a lot of time thinking about platform neutrality in general since it's an issue that does (in other ways) have a bearing on what we do.

We're using site/blog.rb, pretty much the last thing I wrote that's still in production at Stripe...

I already spend a lot of time talking to early stage startups (it's really important that we understand them well); this seemed like a good way to formalize that in a way that helps them too.

(That is, my hope is that this is good for Stripe, for YC, and for the startups.)

In general, I'm very leery of distracting time commitments, and I don't sit on any boards or anything like that. I think this is a (pretty rare) example of one that makes sense for all parties.

> are there any business users who use it to backup an entire organisation's systems?

Stripe has been a happy Tarsnap customer for several years. It's robust and thoughtfully designed, Colin has provided great support, and "backups for the truly paranoid" is a pitch that very much resonates with us.

Agreed; I suspect our Bitcoin prohibited business list, once formalized, will be more relaxed.

We actually haven't figured out how the pricing will work yet. (We want to make sure we have the product right first.)

We have it in beta. Email amber@stripe.com!

What do you think of the explanation that appears when you select it? (Feel free to email me if that's easier; patrick@stripe.com.)

Yes; the timing of payouts is entirely up to you.

They'll get better, but there are now some cool integrations built on top of Stripe, like baremetrics.io and linelytics.com.

We list more at https://stripe.com/docs/integrations.

Yep, for Connect as well.

We do custom pricing at scale; the fees depend on the breakdown of card types used with your service (and hence the underlying costs). Want to drop us an email at sales@stripe.com?

Not yet, I'm afraid. We're working on launching it across Europe, Canada, and Australia. (You can use Connect in those countries, though.)

This is good feedback -- thanks.

(The 7 day transfer delay is going away.)

Yeah, a lot of this page is about clearing up confusion -- turns out many people didn't know that we had these APIs.

We've actually had these APIs for a while (https://stripe.com/blog/send-payouts-with-stripe). But now we have a page that describes what you can do with them.

This is for products like TaskRabbit, Lyft, Postmates, HomeJoy, OrderAhead, and so on -- products that happen to involve some amount of each charge going to a third party. They generally aggregate the demand and build the UI themselves, though -- without them, there is no product.

[Edit: yep, what Zac said in the sibling comment.]

I think it depends a lot on your target audience.

- If your users are "in control" of their own business -- if they handle refunds and customer service issues themselves, if they'd like to log in to their own dashboard, etc. -- I think Connect[1] makes more sense. This is what, say, Squarespace uses.

- If your sellers are providing a service to another company, and expect that the company will take care of everything (a la Lyft and Postmates), I think the transfers API is a better fit.

Does that make any sense?

[1] https://stripe.com/connect

Yeah, that dynamic would be concerning. Having only YC issue the visas would be much worse than having a broader entrepreneurship visa.

Well, I think survivorship bias is separate (though, agreed, it is endemic in our industry) -- the logic wouldn't change in this argument even if YC had only funded Airbnb and Dropbox. It may be a case of misattribution by the founders concerned, but hey -- in the absence of RCTs, trusting them seems like the right default.

> The thrust of his argument is that YC is asking to be granted special privileges, in a circumstance in which they happen to directly benefit, in a way that only helps them unfairly cement their already privileged position.

I don't think Sam's argument is quite as self-serving, though I see how it could be interpreted this way. I think he'd agree that YC should not be a gatekeeper. (As in PG's original proposal.) But if the argument against the original proposal is that we somehow need more data before rolling it out everywhere, running a smaller experiment with YC would seem to be better than nothing at all.

I completely agree with you that a steady-state world of privileged visa-granters is not what we should be trying to bring about.

Airbnb and Dropbox will tell you that YC was instrumental in their success.* And, indeed, that the YC equity stake is worth it. So I think the thrust of your argument is off-base -- there's some plausible justification for it.

But to your broader point -- conferring immigration status upon acceptance by an arbitrarily-designated institution makes me uncomfortable too. However, it's a ship that sailed a long time ago. (Colleges, for e.g.) Given that we effectively permit universities to pick hundreds of thousands of visa recipients every year, experimenting with 100 for entrepreneurship seems not insane.

* (So will Stripe!)

1) You can't just allocate the startups in arbitrary locations and get the same result -- being in SV changes the outcome. (I've tried to start companies elsewhere.)

2) People benefit from Google, Facebook, Airbnb, etc., even if they're not in SV. The immediate job creation is a tiny fraction of the wealth created by startups. It doesn't matter where Bell Labs was located; it just matters that they did what they did. Similarly, we should just focus on creating more Googles, not on which state's payroll taxes get the immediate boost.

> a) Most adventurous student entrepreneurs don't really MUST need a founder visa, they can use OPT. I think founders of Stripe did that.

Founder of Stripe here. Not disagreeing with anything you've said, but I feel I should point out that OPT is far from ideal: it doesn't last very long, it requires the job is related to the field of study, full-time work is permitted only during vacations prior to completion of a degree, etc. Still, it can be a useful stopgap in some cases, as you point out.

To hijack our own thread: there was a lot of discussion on HN last week about whether Checkout (our drop-in payment form) should support disabling the Remember Me functionality[1].

That day -- and over the week since then -- we had several long internal discussions about it. We've decided to go ahead and add the ability to disable it. This is now documented at [2].

We want Checkout to be simple, and we didn't want to add too much customization since doing so would go against the grain of the product. The whole point of Checkout is to provide a merchant with the right defaults and to improve over time. But we decided that Remember Me is a special case because there's the appearance of potentially misaligned incentives: someone could argue that Remember Me exists for Stripe's benefit and at the merchant's expense.

This is exactly the opposite of what we're trying to do -- the goal is to increase conversions for businesses using Checkout and to get better at doing that over time. But we're adding the opt out to emphasize that we're not trying to force anything.

If you do disable the checkbox, users who stored their accounts elsewhere will still be able to pay on your site in a single click. (This seemed like the most merchant-friendly option to us -- this way, you can still take advantage of the network.)

Thanks for all the feedback!

[1] https://news.ycombinator.com/item?id=7349607

[2] https://stripe.com/docs/checkout

We'd never betray the trust of our users by doing something crazy like that. We're as puzzled as the OP.