Appsheet new app user registration, onboarding, credit card payment workflow

[Wally_Young]

I have an Appsheet app that I'm wanting to now make public for general consumption/use including deploying to the Apple AppStore. However, I'm challenged with understanding how to create a new user registration request form to enable someone to sign-up to use (and buy) the app as a paid subscription model. By securing the app (Require User signin), this does enable me to control which people (users) can use the app. However, I'd like the workflow to function whereby a new person can request to use the app by initially entering their info (name, email) which then verifies that they are a new user, and if so then requests their payment info to purchase access to the app after an initial 30-day free trial use of the app. The whole front-end user sign-up process doesn't seem possible since Appsheet initially would require the user to sign-in to the app via the Appsheet oAuth Sign in process. 

I've considered disabling the Require User signin option for my app, which then poses the issue of having to manage new user sign-ups and username/password form to capture this info but not securely. And then having to somehow store the user credentials which seems highly unsecured and not best-practices.

Any ideas or recommendations? Otherwise I'm faced with migrating the whole app to a native iOS app + web version and move entirely away from Appsheet to better manage overall control for workflows, etc. Thanks in advance! 

[MultiTech]

One thing I've done is to create two versions of the app:

• A public one, where anyone can get to it and use base functionality that doesn't require knowing who the person is (read: sign up for stuff, information seeking, etc.)
• A secure one, where it's access is controlled - but it has way more functionality.

I did this with my Answer Portal app:  www.MultiTechVisions.com/answers - once you sign up for secure access, there's more you can do because you're using a different app. 

• Both apps use the same tables, the secure one having more tables than the public one (since the public app doesn't need so much since it can't do much); since they're tied, any updates made in the secure app (record data wise) are reflected inside the public app.

This makes for a nice little way to push things to the public app in an easy workflow environment through your secure app, where you can build all sorts of advanced workflows and bots.

----------------------------------------------------------------------------

Hope it helps!

[Wally_Young]

Thanks for the suggestion and idea! So after reviewing your answer portal, the workflow looks like it works by sending a payment email for the selected pay-for tier, which also includes the Stripe link for payment processing. Without completing that (yes I’m kinda cheap that way!😬), am I assuming that upon successfully completing the payment, you’re collecting that payment info (including the selected/paid-for tier along with my email I used for my profile), and then does that provide the user with a link to the more secured version of your app that they use to login to and use going forward? And does that more secure version still use the Appsheet built-in OAuth protocols for requiring the user to sign-in, and that version also enables the Require User sign-in option?

Lastly, after reviewing your answer portal app, I realized that’s you that’s also behind one of the key Appsheet support videos you published re: automating some multi-record write functionality that helped me significantly! Thanks again!

[dbaum]

Your use case would be facilitated by using domain authentication so that you don't have to allow everyone to sign in and can automate creation and enabling/disabling of user accounts. For example, see  Manage app user access with AWS Cognito and Google... - Google Cloud Community .

For an outline of a basic Stripe integration, see  In-app purchases - Google Cloud Community . 

[Wally_Young]

Thanks for the recommendation, but Enterprise pricing starts making my app overall to not be cost effective to market/sell broadly…

[dbaum]

While it's a challenge to make contact with AppSheet Sales staff, if you can do that it's worth having a conversation about your use case. It may be possible to structure your account with an Enterprise license just for you and any other co-developers, and an external license for end users that's less expensive than Core or even Starter licenses.