Cancel subscription - time remaining

[floripaolo]

@Serg

No they still persist although Google payment settings are correct now.
But “randomly”. Some payment show as active (yes) some not.
Some subscriptions show they are active others not.
In the screenshots all subscription with a platform entry should be active.

Unless:

1. a cancelled subscription during the free trial period leads to an inactive IAP Active Purchase check.
2. After a payment the index page does not get reloaded and the user does not open the app again (pretty unlikely).

Can you tell me if this is the case?
Because if this is the case I will have to adapt the workflows accordingly.

Thank you.

[Serg]

Hi @floripaolo, thanks for reply.

@floripaolo

But “randomly”. Some payment show as active (yes) some not.
Some subscriptions show they are active others not.

This issue appears due to the fact that Bubble registers the custom state in the database too early (right after the check active purchase action), considering and registering the initial empty state as “no”.

In fact, the check active purchase request passes the following path: bubble → native app → google/apple → response from store → native app → bubble, so it requires a bit of additional time.

A solution in your case would be to add a pause (1-2 seconds should be enough) after the “Check Active Purchase” action, which would be enough to get the required information.

Hope the provided hint will help. Please let me know how the app works after the workflow change.

Regards,

[floripaolo]

Excellent.

Just to clear up a doubt:
But the next time this user opens the app (index page is loaded) the status should be YES, correct?

What should the status check result be, if the subscription got cancelled, but there is still some time left?
e.g. Cancellation after 5 days on a monthly subscription will still give an active status until it expires 25 days later?

Thanks

[Serg]

@floripaolo

But the next time this user opens the app (index page is loaded) the status should be YES, correct?

I’ve passed this question to the developer team for investigation. Once any feedback will become available, I will let you know asap.

Thank you for understanding

Regards,

[floripaolo]

thanks @Serg

I am wondering the implication of this statement for my use, since it is definitely data modification.

[Serg]

@floripaolo

But the next time this user opens the app (index page is loaded) the status should be YES, correct?
Hi @floripaolo, thanks for your patience

What should the status check result be, if the subscription got cancelled, but there is still some time left?
e.g. Cancellation after 5 days on a monthly subscription will still give an active status until it expires 25 days later?

The action “Check Active Purchase” will return yes in the following cases:

• subscription is active
• subscription is canceled but a certain period of monthly subscription remained unconsumed yet (the case you’ve mentioned above).

Note: if a subscription is canceled during the trial period - once it is canceled, on the next page load it will return the “no” state.

@floripaolo

I am wondering the implication of this statement for my use, since it is definitely data modification.

The Bubble will consider this workflow as influencing the screen content, so the pause action before “Change a thing” will be considered too.

Regards,

[floripaolo]

Hello @Serg

I cannot find the “Result of step…” concerning the “Check Active Purchase” action in order to change directly a custom field in the database. Without having to setup 2 separate “only when” actions for yes or no.
Is this how it is supposed to be?

[floripaolo]

Two more issues @Serg

1. I would like to redirect users which signed up on a browser (Stripe), but try to cancel on the mobile app, to our browser app.
   But setting up as you see below, the user will be redirected inside the native mobile app.
   How can I redirect to open the link on the mobiles browser app? Is this possible?

2. Resetting the password from the native app sends an email. But by clicking the link in the email the user gets forwarded to the browser. This creates confusion.
   Is there a way to redirecting back to the native mobile app?

Thanks!

[Serg]

@floripaolo

I cannot find the “Result of step…” concerning the “Check Active Purchase” action in order to change directly a custom field in the database. Without having to setup 2 separate “only when” actions for yes or no.
Is this how it is supposed to be?

Yes, because “Result of step” data are available only on plugin server-side actions and API calls, regretfully, it is not related to this particular action.

@floripaolo

I would like to redirect users which signed up on a browser (Stripe), but try to cancel on the mobile app, to our browser app.

@floripaolo

Is there a way to redirecting back to the native mobile app?

Currently, our plugin doesn’t support such features. It is planned to add them in future plugin updates.

Regards,

[floripaolo]

@Serg

OK:
So how is someone supposed to reset the password from native app?

How exactly is the process meant to be?

Thanks.

[Serg]

@floripaolo

So how is someone supposed to reset the password from native app?

Considering current plugin functionality, this implies using the web version of the app to reset the password.

Regards,

[floripaolo]

Hello @Serg

So the same thing would apply for email confirmation on signup I suppose?

thanks

Paolo

[Serg]

Hi @floripaolo,

@floripaolo

So the same thing would apply for email confirmation on signup I suppose?

Yes, this is right.

Regards,

[floripaolo]

Do you have some infos on when this flaw will be resolved?

Thank you.

[Serg]

@floripaolo

Do you have some infos on when this flaw will be resolved?

I’m afraid that there are no preliminary time limits established when this feature will be added. Once any news in this regard will become available, we will announce them in the official thread

Regards,

[floripaolo]

Hello @Serg

Is there another way to avoid signups with fake emails which would work with wrapped native apps that you are aware of?
Thanks

Paolo

[Serg]

Hi @floripaolo, thanks for your question.

@floripaolo

Is there another way to avoid signups with fake emails which would work with wrapped native apps that you are aware of?

This question mostly relates to the Bubble functionality itself. A possible option for mail verification might be to use the [Mailboxlayer - Verify Emails Plugin for Bubble].(https://zeroqode.com/plugin/1524736005126x840967383868506100)

Hope the provided hint helps. Drop a message if any questions will arise about our products.

Regards,

[floripaolo]

Excellent @Serg

1. Is there a way to change the placeholder to something more appealing? Or just “Email”.

2. When I am using my own API key from apilayer.com the checks do not work. If I am using your API key from your demo page it works.

My free subscripition with my API key

Your API key from your demo page.

Thanks

[Serg]

@floripaolo

Is there a way to change the placeholder to something more appealing? Or just “Email”.

Sure, on our demo page is it shown just as a placeholder example, that can be changed/deleted freely.

@floripaolo

When I am using my own API key from apilayer.com the checks do not work. If I am using your API key from your demo page it works.

We will check this moment and reply asap.

Regards,

[floripaolo]

I really do not understand where to set the placeholder…
It looks like, it depends on the API key.
As soon as I enter your API key I have the same placeholder as in your demo page…