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.
We’ll be adding the ability to redirect after successful / failed payments from the initiate purchase action soon - however, we really want to avoid this capability being used for load bearing things like writing to the database (thats what the backend events are for). We are also addressing a handful of bugs that have come up from early usage quite soon so you should see more reliable behavior from the backend events and IAP in general
Thanks @nick.carroll I’m already using the backend workflows to assigning usage rights to users. Looking forward to when I can use a Go to View following a successful transaction.
