When using the Initalize In-App Purchase workflow action, what’s your recommended next step? In the web app editor using the Stripe plugin you could basically ensure that the workflow would only proceed past the in-app purchase action if the checkout was completed. What’s the equivalent for native mobile?
What I’m finding is that Go to View proceeds in the background while the user looks at the Simulate Purchase modal.
It depends on how you’ve setup your app / where the paywall exists. For example, one common pattern is to have the upgrade CTA on an account tab that changes to showing plan information when the user has subscribed. In this instance, the UI of the account page will change conditionally based on the user’s subscription status. This type of setup doesn’t require any sort of automatic redirect.
Does your app layout require a go to view as the next step?
Yes if I need to change the view, for example if the in app purchase is part of onboarding. What do you advise?
My working solution is to have a Do when condition is true checking for change on Current User’s Subscripted to…
Would you advise something different?
@nick.carroll Do you have any recommendations?
I had a similar scenario for a web app using the Stripe Marketplace JS component. What I did was add a success/fail parameter to the redirect URL after Stripe redirected back to my app, then used conditions on page load to check for those parameters and handle redirects accordingly.
If you’re using Stripe, I’d recommend making all database update functions happen in backend workflows triggered only on successful payments. Not sure if the native in-app purchase has the same options, but hopefully this gives you a framework to work from.
Hey, I don’t know if this is what you need, but there’s this backend workflow action the only triggers after the specific in-app purchase event.
Currently this kind of backend workflow is not triggering on my app, I have a ticket open and I’m waiting for them to fix it, but hopefully it works in yours.
Then you could set it up like “subscription created → Go to view”
Thanks, I have also found the in-app purchase event backend workflow to be buggy.
Just in case it is useful I’ve also found they do not run as Current User, as if front end user triggered them, but you can easy access the subscription-owner user from the Subscription item.
