pc

21 ms·

1. 271.▲
   by pc 13y ago

   We actually haven't figured out how the pricing will work yet. (We want to make sure we have the product right first.)
2. 272.▲
   by pc 13y ago

   We have it in beta. Email amber@stripe.com!
3. 273.▲
   by pc 13y ago

   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.)
4. 274.▲
   by pc 13y ago

   Yes; the timing of payouts is entirely up to you.
5. 275.▲
   by pc 13y ago

   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 .
6. 276.▲
   by pc 13y ago

   Yep, for Connect as well.
7. 277.▲
   by pc 13y ago

   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?
8. 278.▲
   by pc 13y ago

   Not yet, I'm afraid. We're working on launching it across Europe, Canada, and Australia. (You can use Connect in those countries, though.)
9. 279.▲
   by pc 13y ago

   This is good feedback -- thanks. (The 7 day transfer delay is going away.)
10. 280.▲
    by pc 13y ago

    Yeah, a lot of this page is about clearing up confusion -- turns out many people didn't know that we had these APIs.
11. 281.▲
    by pc 13y ago

    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.
12. 282.▲
    by pc 13y ago

    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, t
13. 283.▲
    by pc 13y ago

    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.
14. 284.▲
    by pc 13y ago

    Yeah, that dynamic would be concerning. Having only YC issue the visas would be much worse than having a broader entrepreneurship visa.
15. 285.▲
    by pc 13y ago

    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 founde
16. 286.▲
    by pc 13y ago

    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
17. 287.▲
    by pc 13y ago

    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 t
18. 288.▲
    by pc 13y ago

    > 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
19. 289.▲
    by pc 13y ago

    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
20. 290.▲
    by pc 13y ago

    We'd never betray the trust of our users by doing something crazy like that. We're as puzzled as the OP.
21. 291.▲
    by pc 13y ago

    Definitely not. That would be dishonest and stupid.
22. 292.▲
    by pc 13y ago

    Hm, we did send an email to all Checkout users. If you didn't get one, please let me know. (patrick@stripe.com.)
23. 293.▲
    by pc 13y ago

    I agree. I'd go further: even if we were running some kind of crazy ML on a per-merchant basis, I still don't think we could cater to every single use case. I don't think that any UI we build -- no matter how many knobs a
24. 294.▲
    by pc 13y ago

    I don't think that "talking" and "analyzing" is a dichotomy. (As shown by the very helpful feedback on this thread.) We've been watching the numbers closely, and we'll continue to do so. If we find that th
25. 295.▲
    by pc 13y ago

    Yep.
26. 296.▲
    by pc 13y ago

    Yes, this could be the right approach -- we should perhaps have something like HEAD and STABLE.
27. 297.▲
    by pc 13y ago

    I'm sorry that it comes across this way. Checkout is an optional product. I've tried to explain that 1) we'll remove it if we find data that suggests it's bad, and 2) we're in no way strongly opposed to removing i
28. 298.▲
    by pc 13y ago

    Hm, could you email me? patrick@stripe.com. I suspect that this is an anomaly, as you say (almost all small samples will randomly skew in one direction or another), and our data strongly suggests and testing suggests that this increases sal
29. 299.▲
    by pc 13y ago

    Thanks for the long and considerate comment. To briefly respond -- > So, we’re planning to dump Checkout for a few reasons, but first among them is that Stripe changed our users’ experience for the worse, without our knowledge or consen
30. 300.▲
    by pc 13y ago

    Any interest in coming by Stripe for lunch/dinner? I'd love to chat about this more and figure out a good way to accomplish this. (I.e., a product you'd be happy integrating that we iterate on over time.) I'm patrick@str