#NewtReyes - Oauth
covert helm
Hello. One moment
No unfortunately not
Can you clarify what you are trying to do exactly?
loud shuttle
@toxic mural are you still around?
toxic mural
@loud shuttle Yes
sorry
was having issues with my computer
We would like to know if a customer will have to create a new Standard Account or not to use OAuth with our Platform account.
Having 2 different standard accounts is not something that they will take lightly
So knowing in advance may help us manage their expectations
loud shuttle
https://stripe.com/docs/connect/oauth-changes-for-standard-platforms you want to read this. If they have an account and used another platform they will have to (unless you app is allowed to do the different behaviour we talked about last time, but it wasn't right?)
so mostly always assume they will get a new account, that's the new normal, that's just how it is
toxic mural
Can you remind me what the "different behavior" was?
outer reef
Hello! Taking over and catching up...
The different behavior as in how it worked before the changes linked above?
If so, the way it worked before a single Standard account could be connected to multiple read-write apps/platforms. This caused a lot of issues because different operations from the different platforms would be mixed together, sometimes conflict, etc. Now there's a 1:1 relationship between a Standard account and a read-write connection to a platform.
toxic mural
Makes sense
Problem is, OAuth will require, in most cases, a new Standard Account with no way to migrate the data from the old one into the new one.
So for the most part, users with a legacy Standard account will not want to OAuth.
Does that make sense?
outer reef
Keeping data isolated for each use case is the intention. Can you provide more specific details about why you want to migrate the data?
toxic mural
The idea is that clients could OAuth using our platform account so that we could get our slice of their fees while continue to use their Standard Account.
outer reef
That makes sense, but I'm still not clear why you need to connect to an existing account vs. a new account.
toxic mural
But if they will get a new one, we won't he able to do that
outer reef
Why?
toxic mural
Because having 2 standard accounts to manage will complicate their business processes
outer reef
How? I'd like to help you, but I need a lot more details.
I'm still not clear on the actual problem you're facing.
toxic mural
For example, Customer info, payment methods, etc will be left on one account so customers using the new one will need to recreate them
Right?
Reports will be split in two accounts
outer reef
Let's back up. Can you tell me what your platform does?
What kind of data do you need to access on your connected accounts and why? What operations do you perform on your connected accounts?
toxic mural
In general, we understand why we want them to OAuth but it's hard to justify why now they will need to manage 2 accounts instead of one.
Give me 5 and I will
Back
So, we have a product that helps our clients connect their Salesforce orgs to different payment processors. One of them is Stripe.
They usually bring their standard account, enter their public and private Stripe keys into our "package" configuration (Salesforce add ons are called packages) and they can start processing payments right away. They keep using their Standard Account without any other issues.
Now, we want them to OAuth instead of bringing their API Keys because once they OAuth using our platform account, we will get our slice of the collected fees.
But for our clients, the value proposition is not going to be clear if instead of bringing their Keys and continue using their regular Standard account, they have to OAuth and then they get a totally new Standard account without their customer information, their payment methods, etc.
outer reef
So these accounts are already connected to another platform prior to wanting to connect to yours?
toxic mural
Not necessarily.
But sometimes, they will.
Clients may not be aware that when they OAuth'ed, they connected their Standard Account to a Platform account forever.
outer reef
It's not forever, they can disconnect at any time.
toxic mural
Ahhhh, interesting
We were told that once a standard account OAuth'es using a Platform account, they were connected forever.
From there on, if they wanted to OAuth using our Platform account, the only way to move forward would be for them to create a new Standard Account.
outer reef
We were told that once a standard account OAuth'es using a Platform account, they were connected forever.
Can you expand on this? Who said that? What was the context?
toxic mural
Are there any docs on how to disconnect a Standard Account from an Platform Account once they have OAuth'ed?
We've talked with lots of people. Not sure when this came up.
outer reef
There's a page in the Dashboard where you can go to disconnect from the platforms you're connected to: https://dashboard.stripe.com/account/applications
toxic mural
Can you access that page from your side for a specific account?
outer reef
To what end?
I can't verify your identity here, and this is a public chat, so I can't reveal any information about a specific account I might find.
toxic mural
No worries then
I can show you from my side
we created a new Test Standard account a couple of days ago
This is the ID: acct_1KTaAYC433BEDSLz
This is the page you gave me for that account
Correct me if wrong, but this shows me that this account has not OAuth'ed in the past using another Platform Account, correct?
outer reef
Technically it means they aren't connected to a platform right now, not that they've never been.
toxic mural
Right
Now, yesterday we tried to OAuth into that account using a Test Platform account that we have
The system created a new Stripe Standard account.
outer reef
What do you mean by "we tried to OAuth into that account" exactly?
Are you talking about this process? https://stripe.com/docs/connect/oauth-standard-accounts#connect-users
outer reef
Okay.
So during the connection process it sounds like the option to create a new account was selected.
toxic mural
can you verify that on your side somehow?
We were surprised that a new standard account was created
we were expecting the "old" standard account to be old
outer reef
Verify what exactly?
toxic mural
So during the connection process it sounds like the option to create a new account was selected
Can you verify if that was what happened?
outer reef
That must have been what happened if a new account was created, yeah. This step, specifically: https://stripe.com/docs/connect/oauth-standard-accounts#connect-users
Have a look at the screenshots there.
toxic mural
Well, I wasn't there to confirm or deny that
outer reef
Can you try again and go through the flow yourself?
toxic mural
This is once the process is done
But when I log in using the same user and password, this is the account I get into
What's on the next page?
outer reef
Hang on, let's back up. What do you see immediately after you log in?
outer reef
And on the next page?
outer reef
Yeah, that's an issue.
toxic mural
Ok
outer reef
Hitting skip this form creates a new account.
toxic mural
Sigh
ok
Now, if I try to continue the process, it starts asking me for real data
Ex
outer reef
Yep.
outer reef
What would happen in live mode is you would log in using your existing Stripe account and then in this flow you would be given the option to connect to the existing account or create a new one.
toxic mural
Yes
That we have seen already
we have this code already deployed on some production org
But what worried us is that if we deploy this to our client's orgs and they were connected to another platform org, then they will be forced to create a new account.
Now you are telling me that they can just disconnect from that previous platform account and connect to ours, right?
If they disconnect and OAuth, they won't be forced into creating a new account
Am I getting that right?
outer reef
Yes.
Assuming we're talking about accounts created by people and not other platforms. I don't know if an account created by a platform can disconnect from that platform, but if the account was created by going to Stripe.com and signing up there then yes.
toxic mural
Assuming we're talking about accounts created by people and not other platforms.
Awesome
Is this the page they will have to use to disconnect from the previous platform?
outer reef
Yes.
toxic mural
@outer reef Still around?
Got more questions for you
It looks like you really know this part of the platform
wanton crow
Rubeus is away at the moment but I am happy to help. I get how sticky this part of Standard Connect can be
toxic mural
Oh, man
😄
Ok
So, here's my question: we implemented our OAuth logic following this documentation:
Now, on an internal response from the Stripe representatives we work with we got the following answer:
We are recommending that you choose to make your Standard Connect integration a Stripe Extension. We have confirmed that you'll be able to connect with OAuth to accounts that already have other active or previously active connections and that you'll have read_write access. We've confirmed there are no limitations on revenue share with this approach. The underlying mechanism that powers the integration is still a Connect platform application.
To begin the process as an extension, you'll navigate to the developers tab in the Stripe Dashboard, click "Extensions", and click "Get started": https://dashboard.stripe.com/extensions
Here are the steps in our documentation from there: https://stripe.com/docs/building-extensions
To be sure, there is no impact to what you can do with their integration. The difference is that you will be able to connect to accounts that are already connected to other platforms. This does not limit read_write and does not limit revenue sharing.
Now, as far as we can see, what we implemented is pretty close to what's described on https://stripe.com/docs/building-extensions
except for this:
We are sending a Bearer Token that uses the OAuth Secret Key we receive instead of the extension account secret key and the Stripe-Account Header
Does that make any difference?
Should we stop using the Bearer Token and move to use the extension account's secret key?
wanton crow
I am not immediately sure what difference that might make. So far the calls are working, you are just wondering what the difference is?
toxic mural
Yes
We want to make sure our code is not doing something it is not supposed to do
and then find out later on that because of that, revenue sharing won't work
Also, what's the extension account secret key?
Is that the platform account secret key?
or is it the same OAuth Secret Key we receive during the OAuth process?
wanton crow
Yes it should be your platform's key. If you provide that with the connected account ID you should be able to make your calls on this successfully
