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).
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?
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
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.
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.
Inherent to Stripe processing BTC is the fact that you are now a foreign exchange broker. Here's a small sample of why you're going to have to do a lot better than "we only charge 0.5%" to convince me that adding FX risk into my payment processing stack is a good idea:
Pricing neutrality is hard to enforce and can lead to price inflation (c.f. interchange), but we'd be game for something along these lines. Part of Stripe's raison d'être is making pretty advanced payment infrastructure — only available prior to those with considerable means and past experience — available to anyone. We're obviously not there yet (witness the limited number of countries, payouts only being available in the US for now) but that's where we're trying to get to.
Don't know why this isn't higher up, it shows a consistent position on these matters, and displays a pretty mature context to the original post that set up the comparison. The question was an honest one, and as someone mentioned earlier such legislation might actually be super favorable for Stripe.
For a BRL charge the transaction will still be to a US merchant, rather than a local merchant. You're right that in some countries like Brazil, this can be a bit hit-or-miss.
Both have been up and running in Australia longer than us, actually. And we want to launch multicurrency support in Australia properly: as a default part of every Stripe account with no paperwork. We could probably get a half-baked version out the door faster, but I don't think that's fair to our Australian users either.
Can you elaborate further on what restrictions are preventing multi currency support? If I'm not mistaken NAB are your acquiring bank, surely they would be able to assist you as they did for pin?
