Hello, @founders
Glad to hear that it’s working on your side.
I will discuss this with our team if it is possible. We need to see how feasible it would be for us.
I’m afraid I cannot provide you with any estimates on this matter.
Best regards,
Hello, @founders
Thanks for your patience.
By this message, I would like to note that we’ve added a “Description field” for the “Creating destination charges” action.
Please update the plugin to the latest version and give it a try.
Best regards,
1 Like
Thanks @Ecaterina !
An issue however, that we just encountered: For some reason, when we try to test the checkout on our mobile phones, we get these error messages. On desktop, everything works perfectly.
Android:
iOS:
No idea how to troubleshoot this either. What can we do here?
Hello, @founders
I’ve just tested this workflow on our test page and it works properly.
Thus, please let me know if you are testing it in a native application or browser on each of these devices.
in order to provide you with a more details, I need to understand all your steps before this issue encountered.
I assume that this could be related only to the compatibility of the Stripe with mobile devices.
Best regards,
Thanks @Ecaterina,
We are simply checking out exactly as we do on desktop but using our mobile browsers (Chrome and Safari).
Did you try on mobile, too? This has never been a problem in the past with the “Create a session” action module. Now, after migrating to using the “Creating destination charges” module, it suddenly is a problem. So I’m pretty sure we can rule out Stripe incompatibility.
Please note that we have checked multiple different Seller IDs and none work with the new version of the plugin. This is rather urgent for us to solve as the vast majority of customers will access our web app from mobile.
Many thanks,
Hello, @founders
Yes, I tried this from a mobile device, what’s why I asked you about the native application.
It’s still working on my side.
In order to test this and define the root cause of this issue, please add our Support Team as a collaborator to your application and provide me a ling for it.
We will check this from your end and will be able to define the next steps for you.
Looking to hearing from you soon.
Best regards,
We have added the zeroqode support email as a project collaborator again. Not sure what link you need (you didn’t ask for one last time). This is what we use: wishlist.fund | Bubble Editor
But simply try to gift e.g. www.wishlist.fund/me/beatrice on mobile and see it fail on Android and iOS with the error messages we shared previously.
Let us know what you find and thanks again,
1 Like
Hello, @founders
Thanks for adding us to your app.
I was able to reproduce the issue you are talking about.
I will forward this to our dev.team in order to check the root cause of this behavior.
I will revert to you once will receive an update from the team.
Best regards,
1 Like
@Ecaterina hi, any updates you can share?
90% of our users can’t checkout when mobile isn’t working so just checking to see how the debugging is going. If it will take until next week then we will revert to direct charges / look for another solution.
Many thanks,
Hello, @founders
Please note that our team is not working during the weekends, so this is the reason I haven’t shared any updates with you.
Our team is still testing your application, but it can’t be done immediately due to overloading.
I suppose that we will have an update for you Tomorrow. Thanks for your patience 
Best regards,
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,
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,
1 Like
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.
1 Like
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,
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,
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
Hello, @founders
I’m sorry to hear that and sorry for your experience with the plugin.
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.
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,
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
1 Like