Stripe Marketplace Plugin - Destination Charges

[founders]

Hi @Ecaterina,

We’ve had 25 accounts get disconnected since inception of integrating your plugin. Now Stripe has come back with a root cause analysis that points to you:

Essentially the OAuth Token was consumed twice, which disconnected these accounts from the platform. Platforms such as Squarespace, Shopify or Baremetrics use Stripe Connect to make API requests on behalf of their users. To do this, the user has its own Stripe account and connects it to the platform via OAuth.

Now that the platform was authorized on the connected account, it can make API requests on its behalf. Sometimes though, those API requests will stop working. In most cases, this happens because the account was disconnected from the platform.

Sometimes, the user will be adamant that they did not disconnect the platform themselves. It’s important to know that there are three things that can cause a platform’s access to be revoked:

** The user explicitly revokes the platform access in their account settings.*
** The platform explicitly revokes their access to the connected account via the API.*
** The platform mistakenly re-uses the authorization code they get during the OAuth flow.*

In most cases, the issue comes from the last one as this is an integration issue on the platform’s end and no one really wanted that connection to be revoked. To understand what’s causing this, we need to explain a bit more what happens during the OAuth flow:

** The user is on the platform’s website and signing up for their service*
** The platform sends the user to Stripe to sign up for an account or log into the existing one*
** The user signs up or logs in and we ask them to confirm if they want to let the platform get access to their account.*
** The user is redirected to the platform’s redirect URL with a unique authorization code ac_XXXX in the URL*
** The platform retrieves that code and calls our /oauth/token endpoint with that code and their platform API key to finalize the connection*
** We connect the account on our end and return the account’s id and extra information documented here.*

The authorization code is unique and can only be used once for security reasons. If someone tries to re-use the code, the connection should be revoked immediately (per the OAuth specification) and that’s what Stripe does.

This relatively common scenario is sometimes caused by page refreshes with the oauth code in the URL: python - Stripe API; {'error': 'invalid_grant', 'error_description': 'This authorization code has already been used - Stack Overflow

So please fix the issue on your end and prevent reuse of OAuth codes.

This is critical. Not only is the plugin not working for checkouts on mobile but it also disconnects dozens of our connected accounts systematically.

It doesn’t sound like it, but please let us know if this is something we can affect.

Thanks,

[Ecaterina]

Hello, @founders
Thanks for all this information.

I need to note that such an issue occurred for the first time since this plugin was published.
No one from all our users complained about disconnections of any accounts from the platform.

Firstly, we will investigate the issue with checkouts on mobile devices, at the same time, I will pass the information from the Stripe team to our developers.
It can take time for investigation, since, as I mentioned, we have never encountered such an issue.

Best regards,

[founders]

Hi @Ecaterina.

More from Stripe’s integration and development support team:

The analysis here can be broken down simply as to how an Express account can be onboarded and subsequently disconnected.

For onboarding Express accounts, Stripe supports two approaches:

- Create Account + Account Link via API:

Using Connect with Express accounts | Stripe Documentation

- OAuth (legacy approach):

Using OAuth with Express accounts | Stripe Documentation

Looking into a sample of your existing Express accounts, these were onboarded using the OAuth flow. The important part of the root cause analysis it to look at the last step of the OAuth onboarding flow here:

Using OAuth with Express accounts | Stripe Documentation

In this step the integration will pass an API request to complete the connection as shown in the example code snippet. This is done using the authorization code which is returned in the URL once the user completes onboarding (see Step 3 in the above documentation). Once this request is made, it return success if the connection is complete, or otherwise an error message.

The most common reason an Express account then disappears as explained in the analysis is that the platform mistakenly re-uses the authorization code in another request for whatever reason. When this happens to an already-connected Express account, it will disconnect the account.

As for why this happened, unfortunately this would be up to zeroqode to debug and investigate as their integration would have triggered this disconnect unless somehow you had access to the authorization and did so yourself (which I assume isn’t the case!).

In the context of the new integration your developers are building, they should use the aforementioned Create Account + Account Links onboarding process as it’s the recommended approach.

That said, after catching up on the existing thread you have, I notice that the originally flagged issue in was in regards to accounts that Stripe were rejecting accounts rather than accounts being disconnected. To make sure I’m aligned fully on the issue, are both outstanding issues in that accounts are disappearing (being disconnected) as well as accounts being rejected? Account rejection falls outside of scope of what ISD can assist with, however I can definitely bump this with the team if that is a separate unresolved issue.

Hope this helps you troubleshoot.

[Ecaterina]

Hello, @founders

By this message, I would like to notify you that the issue with checkout on a mobile device was fixed.
As we assumed from the beginning, the SCA element, which should be visible on the page load, was placed in the Floating Group, which becomes invisible when the page size is less than < 768 pcs:

Once we removed the element from this group, everything worked properly.
Thus, there are no bugs in the plugin, but just incorrect settings of the element.

Hope it would be helpful for you.
Best regards,

[Ecaterina]

Hello, @founders

During the investigation of your application for checking the root cause of blocking user accounts, we defined that you are using the API calls for performing the payment and creating accounts.
For example, when I run your app as one of the existing users, on checkout I can find this action:

However, I need to mention that this action is performing not through our plugin, but through API.
If this was created or changed intentionally, please let me know, since it absolutely influences our investigation.

Also, it seems to us that the user is not created correctly.
Before registration on Stripe, you already set the seller id and do not complete the registration (screenshot 1). On our demo page, we first register and then complete it and assign the seller id (screenshot 2):

If we misunderstood some of your settings or you changed anything, let us know.
Best regards,

[founders]

Hi @Ecaterina,

We have spent the last two weeks integrating Stripe Connect natively in our web app via APIs as the Zeroqode plugin evidently wasn’t dependable. Hiring developers to do this for us has cost hundreds of dollars not to mention the months of lost time documenting the shortcomings of your plugin if you look at the lapsed days since we raised the issue with Destination Charges in November last year.

For those reasons we would like to request a refund. Let us know if we need to send an email to your support team in order to process it. We thank you for your efforts but hope you understand that we need functioning software to run our business.

Best regards,
Founders

[Ecaterina]

Hello, @founders
I’m sorry to hear that and sorry for your experience with the plugin.

@founders

Hiring developers to do this for us has cost hundreds of dollars not to mention the months of lost time documenting the shortcomings of your plugin if you look at the lapsed days since we raised the issue with Destination Charges in November last year.

Please allow me to mention that the “Destination changers” action was added by your request to the plugin, so firstly, some issues appeared, when we tried to achieve the required result However, in the end, everything worked properly and our communication was constant on this matter.
The last issue you encountered was investigated by us, but we haven’t heard back from you.

@founders

For those reasons we would like to request a refund. Let us know if we need to send an email to your support team in order to process it. We thank you for your efforts but hope you understand that we need functioning software to run our business.

Please note that all the sales are going through the Bubble platform, so in case you want a refund, you should reach their support team for that.

Best regards,

[laila]

Hi Ecaterina,

We also bought the Uplance platform with the idea of using direct charge but we noticed that the Stripe fee’s are coming to use as a platform and not to the vendor. How do we change this?

FYI also began a new query: Stripe Direct Charges