I’ve forwarded this request to our team and they will disable these permissions
As for request purchase status - we only return a response from the Store. We recommend that you increase the pause after the action.
As for the workflow shown above, they will run parallel to each other, so there is no problem.
Please note that this could be made only by you. Please check the documentation and in case of some difficulties, contact the Stripe Team for more information regarding the disabling collection: https://stripe.com/docs/js/element/payment_element?type=card
Actually those 2 parameters would have to be set by the developer (you). I contacted them. But “auto” would only not show the address request if the user already had an address stored with Stripe. Therefore it is not possible to remove it.
Another issue I am having is with Apple Purchase. Several (4), but not all customers apparently click several times to start the process. For this customer for example the log shows that the app store has been requested to process 7 times.
This causes to send several emails and show several error messages (sendgrid).
The log also shows that the workflows do not process the actions in a coherent sequence but apparently clustered/random. Unfortunately there is no way to download the log in order to show you, But there you can 7 requests to the app store.
Below you can see that the subscription gets scheduled 7 times in the backend.
Here is another example:
Since there is no way to reproduce this I do not know what happens and how to handle such an issue.
Allow me to provide you with all the responses below:
Currently, we are using the “getAvailablePurchase” method, which returns all the purchases.
However, we can’t see the verification of the status step on your side. Thus, we would like to advise you to separate this workflow. Here is an example of the required steps:
Run check subscription is an active action;
Add a pause;
Trigger after a pause a custom event. Please create a custom event and in this event save data from the plugin state.
Here is also the screencast from our devices, so you can see that it works on our side: Loom | Free Screen & Video Recording Software
This issue could be only in case your responsive settings for exactly this screen resolution is incorrect. Please check your settings for the resolution, which would be the same as on your phone device.
In case you already checked it, please reach the Bubble Support Team, since this issue is not related to the Air Native wrapper or default template. All layout issues could be reproduced for the reason of the Editor’s changes.
Can you please let me know which Stripe Plugin you are using in your app? By default, we use the Bubble Stripe plugin in our templates.
So, in case you are willing to receive any additional parameter, you should add it by yourself.
Our team can’t improve the plugin, which was created not by our team. Thus, please let me know which plugin you are using ( you can just send me a screenshot).
The processing can take some time and unfortunately, there is no way to stop it. The only thing you can do is try to set a limit on the number of clicks or sending mails.
Now there is completely different approach. This is VERY frustrating and is causing a lot of issues since all scheduled subscription checks (AND cancellations) depend on this function!!
I changed it as you said, but now instead of updating to “yes” both test accounts, it just deleted both entries (pause is 5000ms). Before they were NO instead of YES.
What I also noticed that when the page is loaded as per log there is no pausing before “make changes to…” therefore IAP check returns no status I guess.
The necessity of this change is related to the fact that your Pop-Up and element, which is placed in this Pop-Up are not visible on the page load, thus, the plugin just avoids this step.
For this custom event, we also recommend you to use not the AirNative a PopUp up Purchase, but from the same element where the action is proceeded ( in your case, it is the Apple Login element).
Unfortunately, it is could not be separated. Please note that this action is server-side action. Is used for validation of purchase and acknowledgment of Android purchase. This action can be found in the “Payment” tab.
ok. got it. Thanks. What you’re also saying that I should combine the two actions into one? Or is it ok like this? (It seems to work at the moment)
from your example it is not clear, since you have two actions separeated by OS (ONly when…).
But the popup shows both ios and android fields filled out.
Your request regarding Deep Linking has been taken into work. However, our native team doesn’t receive any requests regarding SDK. Please let me know when and where it was requested.
No, you don’t need 2 steps. Moreover, you don’t need to use “Only when…”. Please check this screenshot:
Our Native team did not see your request because you sent it to our support team email. Thus, you didn’t receive a response from them. Now, we forwarded your emails to them, but please make sure that in case of necessity, you should reach the Native Team.
Yes, the cancelation is required only one action ( both for iOS and Android OS). The only difference is the necessity of completing these fields for the Android OS:
We will check it internally, however, all is working well on our side with the same settings. Thus it is pretty confusing and seems like the issue is in another workflow.
I will let you know once any update will appears.
Best regards,
Seems like the root cause of the mentioned issue - is your device does not recognize the item on the mobile devices (responsive settings).
We just checked the code and the element is not visible for the page:
For the desktop - the element is visible and information could be received, but the mobile view app doesn’t recognize it.
Please try to play around with the settings
I need to limit clicks for Apple Signin as well, since it is slow and double clicks can make the button unreactive for days (!!!).
Unfortunately there is no option fo the SigninWithApple element “This element isn’t clickable” to choose from conditions.
Therefore the counter cannot work.
