Hacker News new | past | comments | ask | show | jobs | submit login
Stripe Connect v2 (stripe.com)
332 points by pc on Mar 23, 2015 | hide | past | web | favorite | 134 comments

I mean god damn stripe has some great front-end engineers.


It looks modern yet very readable thanks to great typography. Loads fast. Fully usable on mobile as well. E.g. Gets a hamburger menu on Mobile. The featured client animation is simpler. The spinning globe icon is replaced by a static image. They have absolutely top notch front end engineering talent.

This is in huge contrast to the current trend where they want to hijack browser's scrolling behavior for absolutely no gain to the end user.

Some tradeoffs though; this is what it looks like on IE9 http://i.imgur.com/EkH81zN.png

Stripe's product is for developers. I highly doubt there are developers using IE9. It's an audience Stripe can comfortably choose to ignore.

Whilst that sounds logically. You're replying to someone on HN, who is presumably a developer and detected this bug in IE9.

More than likely that developer checked it in IE9 after seeing the great front-end design, and does not primarily browse the web in IE9 (what sane person would?)

Edit: he commented below saying it was IE11 with the IE9 emulation enabled.

It's working properly in our IE9 VM. Are you getting JS errors? Any other debugging info would be great.

IE11 has a feature, Emulation: Document Mode = IE9. No JS errors, so I assume it's a difference of how the "Document Mode = IE9" fails to actually emulate true IE9. Sorry for the false positive.

I recommend you look at image optimization. Loading the /nl flag page from NL takes > 9 seconds. On a connection with 20Mb/s down with one of the best ISPs available.

There are 3MB of images on the page; the problem seems to be the high-res map, which weights in at 1.5MB. This image is 2290x798 and it's in an element of 1145x399. I've halved the resolution and converted it to a JPEG, now it's 0.2MB. To make it even easier for you to show the designers I've uploaded it here: http://imgur.com/XcGllGz.

EDIT: it's worse, almost every image in the carousel is double-sized and unoptimized.

Otherwise it's pretty.

You are talking about the home page, right? Images are double size for retina displays. Your JPEG version is pointless, the flags are placed on top of the background and need an alpha channel. The page is indeed a bit heavy but not enough to impair the experience, first paint is still under 3s. Remember the audience for this page is 90% software developers, with powerful machines and high bandwidth.

I tend to use a combination on pngquant and optipng on most png based graphics. I'm sure there are builds for OSX out there (probably homebrew recipes even).

This will bring the color palette down to less than 256, some images will work better than others, in this case I didn't notice a difference and the size went from 434KB to 133KB in size using the batch file I normally use for this[1]... I haven't checked recently to see if there are newer tools/versions for use, I keep several utils inside my dropbox for windows usage.

[1] https://gist.github.com/tracker1/e41d6b7dc55f962d85a3

> flags are placed on top of the background and need an alpha channel

Ok, that explains the huge PNGs; can't they be rendered as-is (i.e. include part of the background in the foreground picture?

> first paint is still under 3s

That's really slow. The jankey animation (yay Apple) and rasterized image rendering is horrible; it's a throwback to the late-90s internet.

> the audience for this page is 90% software developers, > with powerful machines and high bandwidth.

I.e. me, and I find it horribly slow. I'm using a year old rMBP and I have a pretty good internet connection (20MB/s, 10x what I could get in the UK and I actually get pretty close to the max all the time; for a comparison: http://www.webanalyticsworld.net/2014/08/internet-speed-gap-...).

Sure, I'd love fiber, but that's not exactly broadly available (though if I could move my house 1km to the east I'd have it).

I'm on a late-2013 rMBP running Yosemite. The page looks nice and animates smoothly in both Chrome and Safari. There may be some deeper problem on your system.

The page looks beautiful, but the animation is janky on my FF36

A wild guess, but maybe they target retina displays.

I believe the current trend is designed around an Apple-esque disregard for what the user thinks they want.

typography...usability...graphics... They do have great design talent :-)

Always looking for more :-) — gdb@stripe.com.

IMO: It's just awful.

1. Forced waiting for transitions everywhere. For a page I'll probably only ever visit once. You want to ease-in to things. I get it. But you shouldn't hide them. If you want a dithering transition as you scroll, do that. Don't fade-in. There's almost never an excuse for that.

2. What's the point of the "meteor"? To look cool? Is there any point at all to the businesses scrolling in it? Because I don't know how many there are. There's no link to view them all. There's no points to click to go back a pin and re-read one that caught my eye.

I don't know. It just feels like people are obsessed with having the coolest Flash splash screens again.

Forced wait is definitely an irritating practice in web today. Not only is is distracting and usually valueless, it's delays what is important: information transfer.

I am not sure why i need to scroll through 6 screens to see the price instead of just being able to click an icon on the first screen and jump to where i want to jump to.

Maybe there is a way that I just couldnt figure out. Why is it folks would never today implement a 6 or 7 step wizard with a bunch of next buttons. but its considered a good idea to do so with scrolling is involved...

would also like to see a big down arrow or some kind of standard indicator when a desktop page has this scroll behavoir... i was waiting a the starting screen for quite a while and then clicked on the 4 little icons before i figured out i just had to scroll down forever.

There's a pricing link at the top of the page right where it belongs...

It's running at 5 FPS for me on Chrome. 2013 MBP driving 2 non-retina monitors, lid closed. Seems to work a fair bit better on Safari for whatever reason.

The only thing most of us were thinking, scrolling down that site. I definitely missed some text as my eyes glazed over...

I recently implemented a site with a feature similar to the spinning-globe in the International section[1]: a video element overlapped by text in an adjacent element. I ran into a vexing problem in some browsers where the the text that intersected the video appeared somewhat degraded, as if it were a lighter weight than what was actually specified. In Firefox, only the text directly overlapping the video was affected. But in Safari all text in the entire intersecting div showed this effect, even that not over the video. AFAICT, this is some kind of compositor bug, but I haven't been able to dig up any decent information about it.

I do note that Stripe's page isn't exhibiting this issue, but don't see anything that appears to be a workaround or otherwise unconventional.

Anyone have any color on this? Is this a font-specific rendering issue, e.g. so Stripe's fonts don't exhibit this problem? Or perhaps the presence of a background image on the li tags forces the compositor to behave? TIA!

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

Usually happens when the text is above a section of the page that's being hardware accelerated. The browser basically rasterizes the text, which changes the aliasing properties.

Either move the text off to a separate sister div, or move the animation to a div with a higher z-index. Or you can set -webkit-font-smoothing: anti-aliased - that will set all of the text to same antialiasing settings as GPU accelerated text.

I was waiting for half an hour thinking that image will change and tell me something more. Then I figured out that I can scroll down. Stupid me.

Then it occurred to me that we do the same thing on our home page: we have animation which makes people (stupid like me) wait a little thinking that we will tell them more info - even that info is available only if you scroll down. Stupid me x 2.

Took an unusually long time for everything to load and it didn't load from top to bottom, mixed everywhere.

But, it is very nice and well formatted. 10/10 would refresh again.

The engineers are good, the designers less so.

The whole page is slow to load, solutionyogi must benefit from different optimisations, but on an ipad it seems to get the worse of both worlds.

Even after the page is loaded, the sections are mostly blank until the animations kick in.

Their features page [1] in comparison has a similar concept but is much clearer, simpler and very fast to load and navigate.


It's pretty cool. The entire meteor animation is done on canvas using javascript.

Looks very good. I just don't like how mesmerizing the meteor animation is. I wasn't even paying attention to the content. Also it could use a navigation bar once you start scrolling?

And back-end as well. Their API is so easy to set up and use.

Whenever I see one of their products, I always think "if it's that good on the outside, imagine how good it is on the inside".

I applaud your enthusiasm, but... seriously?

* and designers.

In retrospect, the global P2P marketplace that we've launched in 2010 on top of PayPal's API may have been 5 years too soon. Requiring all our buyers and sellers to have a PayPal account was detrimental to our brand. But, we concluded that we "didn't want to be in the nasty business of dealing with fraud, ID verification and international payments" so it made sense back then to leave that up to PayPal. But I would have given anything for a white label solution such as Stripe Connect. Also makes me wonder why PayPal wasn't able to come up with this in 5 freaking years. The technology, the platform and ecosystem was clearly there, just not the insight.

It's likely this was a conscious business decision; PayPal derives value through its brand, which is lost to consumers (buyers) using the platform if the platform becomes a white label solution.

PayPal wants customers to know they can pay with PayPal at business/merchant X, not just their credit card.

Indeed, Paypal doesn't want you to pay with your credit card, and won't let you change your default PayPal payment method. You have to go through a process to select it Every.Single.Time, if you remember, and if you overlook to do it - well, what do you know, PayPal just saved the CC fee...

PayPal does have something quite a lot like this though the business model is a little different.

The kids these days call it eBay.

Kudos for the great explanation here: https://stripe.com/docs/recipes/on-demand-app

However I still have one question: is it possible to delay payments to service providers? In other words to do escrow.

Here is our use case: a client books a service (maybe with 30 days in advance), we need to charge the client at that time, but we won't pay the service provider until 24 hours after the service has been provided (so that we've made sure everything went fine).

> However I still have one question: is it possible to delay payments to service providers? In other words to do escrow.

Yes: "You can control the transfer schedule for your recipients, which should effectively cover what you need to do. (Sorry this isn't clearer in the docs.) Feel free to email us, too. I'm patrick@stripe.com."

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

I assume you need to file a 1099-MISC with the IRS for each managed account that's setup on the system?

If so, you might want to make this reporting requirement more visible in your documentation.

Actually only if account does 200 txns and $20,000.


We will, by default, send out 1099-Ks to the managed accounts. We'll likely provide some flexibility here depending on what the platform would prefer, but we're still talking to platforms to find out what's ideal for them.

If Stripe is charging 0.5% of funds paid out to managed accounts, does this mean you’re “double dipping”?

We're getting rid of the $0.25 transfer fee and replacing it with 0.5% of funds paid out to managed accounts. We do more work (and incur more cost) if you're using managed accounts, so we think it makes sense.

Seems like it would require the same amount of work to pay out $10,000 vs. $100,000.

Why scale the fee?

Does this apply to marketplaces/accounts migrating from Balanced? There was an assurance that Stripe would honor Balanced's pricing. https://www.balancedpayments.com/stripe/faq#will-our-pricing...

If you require marketplaces to use managed accounts then it's an extra tax, no?

> Seems like it would require the same amount of work to pay out $10,000 vs. $100,000.

We want our pricing to align with the best product experience, and a flat fee would encourage marketplaces to pay out less frequently. This pricing makes it easy to do daily transfers. In addition, there are actually reporting obligations and such that kick in at higher volumes, so it's not completely scale-independent.

> Does this apply to marketplaces/accounts migrating from Balanced? There was an assurance that Stripe would honor Balanced's pricing. https://www.balancedpayments.com/stripe/faq#will-our-pricing....

No; we'll grandfather both Stripe Transfers API (the old system) users and Balanced users. That said, this works out to be cheaper for most people -- most users aren't doing $100k payouts.

> If you require marketplaces to use managed accounts then it's an extra tax, no?

We don't require that they use managed accounts. Over time, I think standalone accounts will become the better option, since it's much less work for the marketplace.

Thanks for the response, Patrick. We run a platform with a large average transaction value, large enough that 0.5% is very meaningful. We would love to take over the onboarding process and entire user experience, but 0.5% is too much to swallow. Braintree provides us with the same functionality and a flat $0.25 payout fee, which is a better alignment of incentives for us.

If we were to use Stripe managed accounts we would start bearing all transaction risk plus a 0.5% fee. As a result our payout frequency would decrease drastically as we'd implement a huge delay, only paying out once we were positive the transaction was risk free.

Is Stripe's preference for platforms to continue to use standalone accounts vs managed account long term? We have a strong affinity to Stripe as a fellow YC company, but struggle with this offering.

Specific to your case, if your transaction volume is very high you should contact us. We're certainly open to volume pricing depending on your specific situation, and would love to learn about how to best serve/price your specific use case. sales@stripe.com is the best contact there. bkrausz@stripe.com also works :).

More generally, international KYC and compliant payments are quite hard, and our pricing there is very competitive. Domestically we saw that many companies were already paying similar rates on our fixed-fee pricing, so we weren't actually hurting customers in the US (on the contrary, we were encouraging more frequent payouts for the same rate, which would help everyone by making a more efficient system). We felt that the benefits of consistent pricing were worth it here.

Re standalone vs. managed accounts: our preference is that we make standalone accounts such a great and easy-to-use experience that everybody starts using them, because dealing with things like information collection and tax reporting is annoying. However, we're letting our customers dictate that. If managed accounts become immensely popular, it means we haven't made standalone accounts easy enough to use, or we've made an incorrect assumption about the world (likely a combination of both). Regardless, we intend to support managed accounts for a very long time, and have already had them around in some less-built-out form for quite a while.

> We want our pricing to align with the best product experience, and a flat fee would encourage marketplaces to pay out less frequently.

I don't understand how increasing pricing from a flat fee to a percentage encourages marketplaces to pay out less frequently. The cost is so nominal that it far outweighs any percentage fee.

> We don't require that they use managed accounts. Over time, I think standalone accounts will become the better option

Better for whom? [edit] My customers are not tech savvy and only want to deal with one fintech vendor, exposing Stripe to my customers seems like it's Stripe's best interest.

> I don't understand how increasing pricing from a flat fee to a percentage encourages marketplaces to pay out less frequently. The cost is so nominal that it far outweighs any percentage fee.

Our goal, as Patrick said, is to allow people to pay out more frequently. A flat fee ties your costs to number of transfers, which seems unnecessary in a lot of cases. If a seller just earned $10, they should get their $10 (at a cost of a nickel).

> Better for whom?

For customers and platforms. If we do our job right, standalone accounts should be so easy to use and user-friendly, even for non-tech-savvy customers, that it's clearly the better option for everyone.

That being said, it's not like we'll kill off managed accounts: there'll always be a good reason to have a fully customized experience. Making standalone accounts good enough to be the better option more often is a goal we strive for, but that's for our customers to decide.

Stripe isn't a monopoly, if you can get better value/pricing elsewhere you should switch, irrespective of the "real" reason for the change.

Lots of great changes that make a world of difference for marketplace builders. From someone who used to use Authorize.net and spent a lot of money building tools around it... I love Stripe. So simple, so smart. Best YC company yet.

The final piece of the puzzle - for me at least - is the ability to collect money as a business, then pay out my service providers through Stripe.

There's a temptation to just let the money sit in my Stripe account, then payout using a "Special Case Transfer" https://stripe.com/docs/connect/special-case-transfers

But this approach seems non-compliant.

How long before we can payout service providers so the charge is seen as coming from my business, instead of from my customers? (This appears to be the compliance issue.)

An ACH "source" is potentially a good solution (and apparently in beta), but I imagine I'll incur additional fee. Perhaps using my own bank account as a source will be free, but using others will be paid? (Kinda like managed accounts)

Do you mean a situation where the service provider is not directly providing the service to the customer, like paying out a caterer for your office lunch? I'd love to better understand exactly what you're trying to use this for.

The short answer is that we're also really excited about the "many-to-many" use case of moving money around. There are many hurdles to getting there, and we're checking them off one by one. This is a leap towards that eventual world.

"like paying out a caterer for your office lunch"

Pretty much. But it's a little hard to envision at that scale.

Think instead about a large company with a set of approved vendors. Execs submit purchase orders to the vendors. The vendors get paid out by check.

Instead, you can payout the vendors through Stripe.

Edit: As I think about this more, I don't think it should be free from my own account, but it's hard to reason what ACH pricing should be. I can send an automated check for $1.50 with Lob today.


It'd be great to be able to do with Stripe what we can do with POs. Here are Three POs for three vendors associated with this purchase (80%, 10% & 10% respectively).

And then directly push the funds to each with separate transactions, without having to have a 'master account' that pulls in 100% (and takes the full fee structure on the nose), then internally/itself pushes out 80% and 10% to others.

We want to create a service that allows us to ship items on behalf of vendors who just upload artwork. Similar to CafePress. I've been trying to find out if Stripe's "special case transfer" could possibly be used for this but am not having much luck.

(i.e. Accepting a $30 charge for a customer and doing two transfers using source_transaction, one for $10 to Vendor 1 and one for $20 to Vendor 2)

I know that it would be compliant if we setup a Stripe account for each vendor and created the charge directly with their Stripe account but we want to be able to have customers checkout with items from multiple vendors.

Does anyone know if Stripe have plans -in the rather short term- to come to Asia? Japan, or maybe Singapore?

I know this question always comes up so it must be getting obnoxious, and I apologize for asking it yet again, but it's a testimony to how great Stripe is. I'd go further: I think it is a competitive advantage for a startup to be in a country supported by Stripe vs others.

I have a Japanese tea subscription service (https://tomotcha.com), so my business is anchored in Japan. Yet because there is no acceptable payment system here I take payments abroad with all the tax headaches that it entails... It's ok for now because Tomotcha is pretty small, but when it grows I will have to switch.

I'm looking forward to the growth of course, but not to the switch...

Check out Webpay for payments in Japan. Their API was originally supposed to be a clone of the Stripe API, but have gone off with their own API updates based on the JP market. https://webpay.jp/

I know webpay, but it only issues payments in JPY while I charge my customers either in USD or EUR... It's great for Japanese companies targeting the Japanese market, but my customers are mostly in North America and Europe.

Either Stripe itself or something like Stripe needs to open in Korea. Payments are a major pain here. :(

Cool service, how many subscribers are you at now?

Did you just merge "Connect" and "Marketplaces" so that there is no "Marketplaces" anymore? I saw that stripe.com/marketplaces is a redirect to stripe.com/connect

Yes, they're the one product now. We didn't want divergent products for similar use cases. One feature we think is neat is you can mix-and-match standalone accounts (where the seller uses a regular Stripe account) and managed accounts (where the seller never goes to Stripe).

Is this a change in price for $0.25 per transfer, to 0.5% per transfer? I guess there's additional value-add from tax management.

Yeah, the $0.25 transfer fee is going away. We didn't want to penalize platforms for transferring earnings to their sellers more frequently.

If you're paying out on a $10,000 job, the fee is going from $0.25 to $50.00? Is there a way to keep the flat-fee pricing?

I'd love to use managed accounts to white label my onboarding, but I don't think my users will be able to absorb the 0.5% and our margins are far too low to do it for them. I don't really need control over the transfer schedule, is there any way to get the white label benefits without the cost? Or is standalone my only option for now?

You know Stripe attracts great talent when an API company has some of the best front-end work you've seen.

All of the links on rotation images and company text go to DoorDash for me. Also, only a short line of text is shown and the rest is cut off. "Lyft uses connect to Create an integ"

This is on IE10 Version: 10.0.9200.17267 (work machine).

Screenshot: http://imgur.com/lddIlhz

Thanks for the heads up, we're looking into it!

wow some people still use IE on HN.

Wow, some people on HN access the site from work where corporate IT policy may limit the software that runs on their machine.

Heads up, another broken link. On this page: https://stripe.com/docs/connect/connecting-to-accounts#manag...

There's a link to learn more about managed accounts: https://stripe.com/docs/connect/managed-accounts

Which just shows "An unexpected error occurred" http://cl.ly/image/3V2k333n0d32

Sorry about that! Should be fixed now.


I'd like to be able to capture someone's credit card for a given amount (deposit), and then charge it later (manually) if certain terms are met. Is this possible under this new system?

Yes, I believe you've been able to separately auth and capture (up to 7 days) later for a while


Seven days isn't helpful.

I've been looking at performing this functionality with utilizing a free trial; setup a subscription payment of one year with a three month trial.

If the client meets the requirements, let the subscription charge after three months (then cancel all subsequent subscription payments). If they fail to meet terms within the three month window, cancel the "trial" all together.

Feels hacky.

If you attach the card to a customer object[0], you can create one off charges whenever you'd like. Stripe will even update the card's details on the customer if the card is reissued[1]. You can then create charges against the card manually through the dashboard (which seems to be what you were looking for based off of your original comment).

[0] https://stripe.com/docs/tutorials/charges#saving-credit-card...

[1] https://stripe.com/blog/smarter-saved-cards

Does there always have to be an initial charge (in the example $1.00)?

No. Creating the customer will charge the card $0.00 or $1.00 (depends on country/bank) and immediately refund the charge to verify the card itself, the CVC, the address, etc. In most cases, this tiny charge won't be noticed because of the refund.

Does this require people who want to be paid to sign up for accounts on stripe? Or can the application initiate bank transfers to the seller, on behalf of the buyer or from escrow.

You have two options: you can have sellers link a Stripe account (and we'll do all the downstream work, like collecting their bank account info and verifying their identity). Or you can create a managed account via API, where the seller does everything from within your app and never needs to go to Stripe.

Can you do the following (in this order): 'Provision' a standalone account with just an email address (with zero work by the account holder to-be) > Initiate a charge (to a buyer) that will ultimately be paid out to that standalone account > Have the seller setup their standalone account (so it's then capable of receiving funds)

I'm trying to figure the work flow that has the least toing and froing for both parties.


Also of note:

Setting up managed accounts, including international accounts, ID verification, and 1099-Ks, costs just 0.5% of funds paid out.

Transfers to standalone accounts are free.

Is there any plan to offer some kind of in-between option where the seller links their stripe account, but the application is "sandboxed" in a way that prevents the user for creating, updating and deleting resources like cards, customers,etc? I like the idea of users linking their own accounts, and Stripe taking control of the identity verification, etc, but I don't like keeping all my data in sync with stripe via web hooks.

Update: Works for me when I log out of Stripe. Nevermind.

The managed account page appears to be down: https://stripe.com/docs/connect/managed-accounts

Doesn't appear down for me.

What does this mean for those of us who already use Stripe Connect? Do we get support for more countries automatically - do we have to change our code - will the v1 API stop working soon? Please send out an announcement current to Stripe Connect API users with upgrade information!

The new site is very pretty, but also very sluggish in Firefox.

Existing Connect integrations will still work: no changes are necessary. Connect has always allowed you to connect directly to accounts in other countries, so no major changes there either.

We're getting some emails out now with more specific "what can I do not"-style information.

Any stripe engineers here to explain how the new multi-party payments work? The documentation has a new "destination" field but doesn't explain if it can be used as a third party in a normal Stripe Connect charge.

I see a new Stripe-Stripe programmatic transfer, but is that the only way to do multi-party setups?

Should clicking on the companies (lyft, Kickerstarter..) open in a new tab instead of navigating away from Stripe?

I was just looking at Connect a few days ago and had one issue - the fact that the customer account needed to bear the fees. Very happy to see the option for the platform account to bear the fees. Much simpler for the customer to understand!

How much of this decision was based upon regulatory / payments compliance pressure?

So the blog post on connect says "Managed Accounts" are available to anywhere that stripe is supported. However, on the docs, it says that it can only be used in the US and Canada. Which one is it?

You can create managed accounts anywhere Stripe is, but your platform needs to be in the U.S. or Canada. Sorry if that wasn't clear.

OHHH! That makes SO much more sense. Okay, yeah you guys should clarify that, that's a huge selling point. Thanks for the response.

> ...our platform can support sellers anywhere Stripe operates (18 countries, more coming this year).

Asking from New Zealand, any hints on the "more coming this year" countries?

probably OT: Is it possible to link Stripe to a credit card so I can perform an online shopping transaction on behalf of my customer without handling their credit card data?

What's your use case? You can't use cards stored in Stripe on non-Stripe sites, if that's what you're asking.

What I was imagining is stripe issuing a credit card that my system can use to perform credit card payments on any generic webshop (either manually or some web scraper) and have that linked to a payment into my stripe account by a specific customer. I am not aware of anyone offering this service.

Why on Earth would you need to be able to do that?

Sounds like an extra layer of card fraud protection might be a use case.

Automating some shopping cases might be another.

One question that came up when browsing thru the api doc. What are the advantages of "Charging through the platform" vs "Charging directly"?

Charging through the platform has you pay all of the fees and take on chargeback liability, whereas charging directly passed those on to the managed account. This also affects the default statement descriptor and contact info on statements.

Hmm correct me if i'm wrong, but it doesn't seem like it would be that advantageous to take on the chargeback liability just for the statement description unless 'charging thru the platform' also provides a escrow system for the safety of the buyer.

When you charge through the platform we issue the charge on behalf the connected account, so you are never actually in the flow of funds.

Re: chargebacks, there are 2 situations where this becomes relevant:

- With managed accounts, you're responsible for losses in the end anyway. This mostly dictates which account balance the fee comes from.

- Generally if you're providing the customer support it can make sense to take on liability. Take Lyft for example: they don't debit driver bank accounts if they get a chargeback.

What is the name of the person that created this design?

Philipp Antoni made the gravity header - https://twitter.com/phlntn

Does Stripe support all the EU countries yet?

In our defense, they keep adding new EU countries. But no, we're not in all of them yet. We're in 13 EU countries, Norway, and Switzerland: https://stripe.com/global

> In our defense, they keep adding new EU countries.

Best progress response I've seen.

If it helps, they seem to also be on the brink of losing some. Congrats on the launch!

Pluses: Stripe increases EU coverage

Minuses: global financial earthquake

Hmmm.... :)

Not really adding any new ones for quite some time now.

I've quickly developed a page to view the progress: http://0xff.lt/stripe-spread.html

Still more than 50% of EU left. And Switzerland does not seem to be moving anywhere, hehe.

Nice colours. Keep those paintbrushes handy! We're on it...

I wish!

I've quickly sketched a website with the current supported countries: http://0xff.lt/stripe-spread.html

You have? Wait I remember reading about this somewhere... ;)

That is not how orbital mechanics work...

Any timeframe on when managed accounts are expanding beyond US/Canada?

I work at Stripe. We're looking to expand as soon as we can in the 18 countries we support (https://stripe.com/global), but no ETA yet I'm afraid. If you're interested in helping us test a private beta, shoot us a note at connect@stripe.com.

How does it look with transfers for other countries than US?

current balanced customer who is soon to be a stripe convert.

very thrilled about this and being able to payout internationally as a marketplace!

This is great! Well done!

Love it, awesome stuff.


I want to start a code marketplace using Stripe connect. someone posts a job, people bid on it, someone pays the person doing the job, I take the payment and release it when the work is confirmed to be done.

Is there an existing script that I can use and integrate stripe connect with?

Dat landing page tho

Registration is open for Startup School 2019. Classes start July 22nd.

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