I want to create a platform which will provide a digital service where the customers and connected accounts will be from around the world. Clearly Stripe Connect is the Stripe product to use.
Because many of the connected accounts will be overseas this straight away rules out the use of transfers - unless I explored setting up separate platform accounts in the different overseas countries. (https://stripe.com/docs/connect/capabilities-overview#cross-border-transfers)
So I am left with destination charges where I choose the connected account as the settlement merchant via the on_behalf_of parameter. This means the charge goes against the connected account but I can still make money by charging an application fee.
As the connected account will be invisible to the end customer on the platform it seems inappropriate for the connected account's details to show on the customer's bank / credit card statement. Instead I want the platform's details to show.
Stripe support have assured me it is possible to have only the platform's details. Indeed this part of the API suggests I can control the statement descriptor which shows - https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-payment_intent_data-statement_descriptor
But another article - https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-payment_intent_data-statement_descriptor - seems to almost contradict this. It explains
Any additional information that’s displayed on a customer’s statement
is also provided by the same account that provides the static
component (business address, phone number).
Can anybody clarify? Many thanks in advance.
Update
This article appears to settle the matter - https://stripe.com/docs/payments/connected-accounts
Guess I will just have to inform users on my website with a connected account that their details will show on the bank statement.
Related
I'm hoping that someone here can assist me with this issue. Stripe support has been underwhelming thus far.
We have a Primary Stripe Account setup in the US
We have customers that will be based out of MX that will connect to the US accounts.
From what we understand here: https://stripe.com/docs/connect/cross-border-payouts there are 2 main criteria that need to occur
We need to make these accounts "Custom"
We need to use the "recipient" option for the account's service agreement.
We also cannot request any other "Capabilities" such as "Card Payments" when setting this up.
Moreover, we have noticed that the moment we use the "Custom" option with Recipient agreement, customers do not have the ability to "Sign In" to their existing Stripe accounts even if they have one. The system always forces them to go through a "new" account setup process. Per Stripe, we are responsible for managing everything including verification of the customer and the customer is NEVER aware of the Stripe account's existence. This has been a hard pill to swallow for some of our larger customers who already have a Stripe account.
Say, we overcome that objection, and say people create new accounts. Now, we're running into a whole new series of problems.
We understand that Stripe requires us to perform separate charges and transfers. Great, we use transfer groups and transfer destination.
However, we also want to use the on_behalf_of parameter so that we attribute the transaction to the connected account for reasons explained here: https://stripe.com/docs/connect/charges-transfers#on-behalf-of
This is where the fun starts. It appears that if you use on_behalf_of, you cannot use "Automatic Payment Methods".
If you specify "card" as a manual payment method type, it will tell you:
You cannot create a charge with the on_behalf_of parameter set to a connected account with transfers but without the card_payments capability enabled.
However, the kicker is that we cannot request card_payments capability for the custom/restricted accounts. So this is a catch22.
So now, we cannot use On Behalf, and essentially, we're acting as the account of record, which is raising alarms in our accounting department.
In addition to that, our customers want to use OXXO, understandably so. This works fine in DEV mode, but when we enable Production, it tells us:
This payment method (oxxo) is not activated for the account specified in on_behalf_of. You can only create testmode oxxo PaymentIntents. You can learn more about this here https://support.stripe.com/questions/i-am-having-trouble-activating-a-payment-method
So, essentially, we are unable to use OXXO w/ or w/o on_behalf.
This makes us think if there are better ways to resolve this issue. We have been trying to get through to Stripe support and their responses have been circular, almost meaningless as they keep pointing us to the documentation and we keep poking holes in their documentation.
Am I missing something here? Looking to see if someone else has had these issues.
Cross-border Payouts as a feature allows US platforms to transfer funds around the world in more countries than Stripe officially in. For example you can accept payments from a customer on your platform and then sends funds to a connected account based in South Africa or South Korea even though Stripe doesn't (at the time of this answer) support those countries for payments.
The overall feature relies on a different type of "agreement" between you and the individual/business you are sending funds to. To do that you have to explicitly set recipient as the service_agreement parameter.
When you go down that path, you can not use on_behalf_of at all. Using on_behalf_of changes a lot of things such as where the payment is being "made from" which Stripe documents here. For that to happen in South Korea or South Africa, Stripe would have to be able to operate and accept payments there. But they can't, and that's why Cross-border Payouts exist in the first place: to let you send funds in countries where Stripe doesn't yet operate. So not using on_behalf_of is entirely expected.
Now, if you don't use on_behalf_of, what you are really doing here is accepting payments yourself, on your US account, through the US. So this limits you to the payment method types that Stripe supports for US accounts. This means you can not use Oxxo for Mexican customers or Konbini for Japanese one. This is a limitation that Stripe likely will lift over time but it's not available today. For example you can accept a lot of European payment methods from the US now which wasn't possible in 2019. In the future, those things will get easier, it's just not the case now.
What I don't fully understand, is why you would go down that path. You clearly say you don't want to be the "merchant of record", you want to do local acquiring, etc. My read is that you simply want to use Destination charges with on_behalf_of. This is supported from US platform to a MX account already. This is something Stripe already supports by default with the "default" services agreement.
While I tried to help with my knowledge, this is really something you have to discuss with Stripe's own support team. They are the only ones that can look at your account details, discuss your business model and understand if they can support you.
I want to use Stripe Connect to provide multiparty payments, in my website.
I have a platform. User A (customer) will pay User B (which is the service provider) on the platform and as a platform, I want to get some amount percentage in the middle.
So, I'm following this guide
https://stripe.com/docs/connect/collect-then-transfer-guide
But, when it comes to testing creating those standard connected accounts, I need to fill real information like phones and emails.
However, I found this guide to fullfill my problem:
https://stripe.com/docs/connect/testing#using-oauth
But, I'm not sure how can I use this guide?
How can I create a stripe account for my user B (who will accept payment through my platform) and got that account_id in testing (and later production)?
There are multiple points to clear:
There are Standard, Express and Custom account types. There are also
3 fund flows of Direct Charge, Destination Charge, or Separate
Charges and Transfers. See comparison from Stripe Doc (this is important)
If you decide to use Standard Account, you should go with Direct
Charges
There are 2 ways to onboard a Standard Account. OAuth is a
legacy integration. Account Link is preferable.
But really, Express + Destination Charge would be easier. You should also use Account Link to create express accounts
I am collecting a payment using Stripe, and want to keep a portion, and send the rest onto another account from another organisation.
Stripe have told me that I have to connect an account. I have done this, Stripe gives me a link which the other organisation pastes into their browser, and all works. I can create a transfer linked to a payment intent.
But, when the link is pasted into the other organistions browser, this message is shown.
______ will be able to see your account data (such as all payment and payout history), including any data created by other business you've connected. They'll also be able to create new payments and take other actions for you.
This seems crazy - I just want to pay them some money, not ask them for full access.
Am I missing a trick?
Stripe Connect is a product/tool that allows accounts to work together to provide goods and services to end customers. There are a few different approaches to how this is configured based on your use case as well as whether you would be acting as the Platform (the one in control) or the Connect Account.
You should review the different Connect Account Types and determine what best matches your use case. Some questions to consider are as follows:
Who is interfacing with the end-customer (you or the other account)?
Who is providing the product/service?
Is this other account providing a service to you in exchange for a cut of the revenue?
On what account should the transactions and customers be stored?
It sounds like, based on the warning message, you were creating the other account to be the Platform and you would be Connect Account. In that cases the other account could make API calls on your behalf using your account token. This would be normal if the other account is providing a service to you like funneling customers to you in some way. A good way to quickly review what approach makes the most sense for your use case is to review the Funds Flow diagrams for the different types of Charges
Direct Charges
Destination Charges
Separate Charges and Transfers
I'm building a platform where content creators can setup a subscription service of which I'll take a fee (think Twitch.tv, Substack, OnlyFans, etc.)
Content creators will setup a Stripe Connected Account on the platform. I'll operate the Platform Account.
Customers that subscribe to a content creator might want to subscribe to others so it makes sense to keep both Customers and their PaymentMethods on the Platform Account. Customers must be able to manage all their subscriptions and have their credit card details pre-filled, if already available.
I can't, for the life of me, understand how to share these Customers and their PaymentMethods with the content creator's Connected Accounts.
I followed the clone customers across accounts guide unsuccessfully. It errors out while creating the Token, saying that the Customer must have an active payment source. I read somewhere that this guide doesn't work with PaymentMethods but I don't really know if that's true.
Then I found this other guide. It seems, though, that I would have to create a Customer, per User, per Connected Account which will make me duplicate information and make subscription management harder.
Could anyone, who has experience building a similar service, give me some pointers?
Thanks
Instead of cloning PaymentMethods to your connected accounts (for which this guide is the correct one) you could create subscriptions using destination charges. The idea being that the customers and payment methods stay on your platform account. When an invoice is paid its funds (minus an application fee set by you) are automatically transferred to the connected account.
So when I run a charge, I'd like to be able to have 15% go to a secondary bank account of mine. What's the preferred way to do this now?
I found a great article on exactly this, using recipients and transfers (https://unicornfree.com/2013/using-stripe-to-divvy-up-revenue), but that's been deprecated and replaced with Managed Accounts. But those docs don't offer a clear way to do what I need.
Anyone seen a working example out there?
It sounds like you're trying to setup a "marketplace" type scenario, in which you would use the Stripe Connect platform and have the application_fee parameter in your request which to collect your 15%.
In that scenario, you create a charge request for $100 from customer A, you can specify an application_fee of 1500 (stripe requires the value in cents) in the API call. Documentation on this can be found here.
The result is that the $85 goes to your recipient, and $15 goes into your personal stripe account, and can be transferred to the bank account of your choosing. On hidden "gotcha" to this is that the stripe processing fee will be taken out of your application fee that you charge, so you won't be getting a true 15% from the transaction.
Note, you will need to have a connected or managed account registered through your connect account in order to properly setup the transaction. A general overview on the pros/cons of connected vs managed can be found here.