InApp Purchase Design

I am new to IAP designs and I would like to bounce my design off others for suggestions. I have an app that includes InAppPurchases. There are (2) options for non-renewable subscriptions: coach and student. The student provides account access for a single student profile for a year. The coach provides unlimited student profiles for a year. Then, there are (2) consumables that can be used to provide additional features. One is to add additional student profiles to a student level account. And, the other is a reference school to allow adding additional schools to a given account (coach or student).

Now, I have setup the app w/ a back-end service to store the credits that an account has for profiles and reference schools, as well as tracking the account type (coach or student). I am using the ngStorekit plugin to add the ability to support InApp purchases. My current design is as follows:

I have wrapped the ngStorekit features into an angular service, StoreSvc. This has an init() method that is used to init the store w/ products (2 non-renew, 2 consumables) and wire up the watchPurchases promise to a “then() handler” that broadcasts messages on the rootScope for purchase and restore events. Then, there is a generic purchase method that takes a product id and specific utility methods to purchase student profiles and reference schools that use the generic purchase method w/the product id already provided.

The user account details are wrapped into an angular service, AccountSvc. The service has an init() method to pull the status of the logged in account including type and credit counters for profiles and reference schools. Then, there are methods to increment the profile credits and school credits. On the back-end, whenever profiles or schools are added, these counters are decremented.

The account controller wires everything together for the Acct view that is setup as a tab in my prototype app. This view is configured as one of the app states in the app.js following the Ionic tabs app design. Anyway, the controller injects the AccountSvc and StoreSvc. This allows me to get the account status and display the count of credits available for adding student profiles and reference schools. Then, the StoreSvc is available to allow the user to execute an IAP to add credits. The controller “listens” for the rootScope broadcast of purchases sent by the StoreSvc and executes the corresponding addCredit method on the AccountSvc.

Thoughts on this design?

1 Like