In-App Subscriptions - need help on how best to maintain

Solar2D Monetization (in-app purchases, ads, etc.)
#1

Hi,

Have any of you used in app subscription and can provide some help on how to maintain them?

So far we’ve only used regular IAP (consumable and non-consumable), which are fairly easy to control.

however, to our understanding, we need to maintain and validate a user’s subscription on the app every time he/she opens it. that means that we need to track the start of the subscription and inform the user when it near its end. we also need to take care somehow for multiple devices using the same apple Id, handle restore scenario etc. we see a lot of potential pitfalls that regular IAP don’t have.

Would really appreciate if someone who used this can give us some tips.

Regards,

Adi

#2

no one use subscriptions? 

Corona staff, perhaps you could help?

do you provide additional fields in the transaction that corresponds to subscriptions?

#3

I don’t have any experience with Subscriptions.  I would assume you would have an online database somewhere and a way to track the user by username/password and when you get the purchase event you would store the date and time it expires in your database and on each run of the app, you would check with your database and calculate the time left.  If it’s under a certain threshold, then alert them that it’s about to expire.

Rob

#4

This is my thinking as well, but at the time, when we started with regular IAPs, there were quite a few pitfalls which we learned to avoid. I assume there are new ones here, which I’d like to catch before launch.

in the meantime, I found out that auto renew subs are not available in most store fronts, so this is not an option any more for us as this stage. 

The manually renewable subs seems to behave very similar to the regular IAPs, so we may be safer here.

Thanks for replying.

Adi

#5

We have successfully used subscriptions in the Play Store and the Amazon store(and pending Apple’s approval in the AppStore).
Rob has summed it up pretty well. 

A few pointers though : 

  1. In the play store,
        * you will be provided with an access token, which expires after some time. So you have to manually check for token expiration and renew the expired token by making a request to Google’s server. Apparently this refresh request is expensive(at-least thats what their docs said) so do this as and when necessary
  2. For Amazon,
         * you have to Install the RVSSandbox app in your server which acts like Amazon’s server during the duration of your testing phase. 
         * If the subscription is valid, Amazon won’t tell you how much time is remaining.  So you will have to check everytime your user enters the app(onApplicationStart or onApplicationResume)
  3. For Apple,
         * Apple’s subscription testing is the easiest and most straight-forward of the three… with very less stuff to set up. 
         * You need to give the sandbox server even after you submit the app for review. Only after it becomes live, you will need to switch to production server(Our app got rejected twice because we used production server… We pinpointed the issue only after that).
        * You can’t use auto-renewable subscriptions unless it is a periodical or a magazine(or something like that). We got rejected once, and the review team asked us to use non-renewable subscriptions
  4. Have a copy of the receipt details locally in the device and also stored in the database. One never knows what might happen. 

Hope that helps. 
Drop in a comment here if you have any doubts! :) 

#6

Hi Satheesh,

Thanks for these tips. I was not familiar with the differences in Google and Amazon stores and will have to check for them. 

I’m currently not planning to use server side auth for purchases, at least not for launch, so its all in the client. since this is an educational app for kids, I do not expect to get much interest from hackers.

This is our first go at subscriptions. our main fear is how parents will respond to them when most freemium apps are flat rate only.  guess we will have to check and see.

#7

Server side is authentication, while it keeps out hackers, also allows for more flexibility. 
Never mind about though. 

Do have a look at this library I wrote some time back : https://developer.coronalabs.com/code/validation-auto-renewable-app-purchases
It helps validate susbcription receipts (server-side and client-side).   It is iOS only though. 

#8

yes, auth is authentication. that’s a nice sample.

#9

@Satheesh

Were you able to get auto-renew subscription working on Google? We are in the midst of giving it a try, and whenever we make a store.purchase(subscriptionProductID), we get the following error. The same code works fine for none-subscription productID. If you have any suggestions, that would be most helpful. Thanks!

I/Corona (24366): DEBUG: txn.state failed I/Corona (24366): DEBUG: txn.date nil I/Corona (24366): DEBUG: txn.identifier nil I/Corona (24366): DEBUG: txn.productIdentifier nil I/Corona (24366): DEBUG: txn.receipt nil I/Corona (24366): DEBUG: txn.originalDate: nil I/Corona (24366): DEBUG: txn.originalID nil I/Corona (24366): DEBUG: txn.originalReceipt nil I/Corona (24366): DEBUG: txn.errorType -1008 I/Corona (24366): DEBUG: txn.errorString IAB returned null purchaseData or dataSignature (response: -1008:Unknown error)
#10

@akao Yes, we did manage to get auto-renewable subscriptions working in Play Store.

I never got the error which you have mentioned above,though.  So sorry, I have no idea

A quick google seach gave this.   
Maybe this is a Corona thing? What build are you using? 

#11

@Satheesh 

Yes, I think the issue you pointed to is indeed the issue. I got a response back from Corona support on this issue:
 

http://docs.coronalabs.com/daily/plugin/google-iap-v3/migration.html

The parameter for the store.purchaseSubscription is just a string for the item’s id.

Again we do not officially support this functionally so any issues you run into may not be resolved.

I was able to confirm that the purchaseSubcription API does work! Just beware, per Corona, support for the API can’t be depended upon.

#12

no one use subscriptions? 

Corona staff, perhaps you could help?

do you provide additional fields in the transaction that corresponds to subscriptions?

#13

I don’t have any experience with Subscriptions.  I would assume you would have an online database somewhere and a way to track the user by username/password and when you get the purchase event you would store the date and time it expires in your database and on each run of the app, you would check with your database and calculate the time left.  If it’s under a certain threshold, then alert them that it’s about to expire.

Rob

#14

This is my thinking as well, but at the time, when we started with regular IAPs, there were quite a few pitfalls which we learned to avoid. I assume there are new ones here, which I’d like to catch before launch.

in the meantime, I found out that auto renew subs are not available in most store fronts, so this is not an option any more for us as this stage. 

The manually renewable subs seems to behave very similar to the regular IAPs, so we may be safer here.

Thanks for replying.

Adi

#15

We have successfully used subscriptions in the Play Store and the Amazon store(and pending Apple’s approval in the AppStore).
Rob has summed it up pretty well. 

A few pointers though : 

  1. In the play store,
        * you will be provided with an access token, which expires after some time. So you have to manually check for token expiration and renew the expired token by making a request to Google’s server. Apparently this refresh request is expensive(at-least thats what their docs said) so do this as and when necessary
  2. For Amazon,
         * you have to Install the RVSSandbox app in your server which acts like Amazon’s server during the duration of your testing phase. 
         * If the subscription is valid, Amazon won’t tell you how much time is remaining.  So you will have to check everytime your user enters the app(onApplicationStart or onApplicationResume)
  3. For Apple,
         * Apple’s subscription testing is the easiest and most straight-forward of the three… with very less stuff to set up. 
         * You need to give the sandbox server even after you submit the app for review. Only after it becomes live, you will need to switch to production server(Our app got rejected twice because we used production server… We pinpointed the issue only after that).
        * You can’t use auto-renewable subscriptions unless it is a periodical or a magazine(or something like that). We got rejected once, and the review team asked us to use non-renewable subscriptions
  4. Have a copy of the receipt details locally in the device and also stored in the database. One never knows what might happen. 

Hope that helps. 
Drop in a comment here if you have any doubts! :) 

#16

Hi Satheesh,

Thanks for these tips. I was not familiar with the differences in Google and Amazon stores and will have to check for them. 

I’m currently not planning to use server side auth for purchases, at least not for launch, so its all in the client. since this is an educational app for kids, I do not expect to get much interest from hackers.

This is our first go at subscriptions. our main fear is how parents will respond to them when most freemium apps are flat rate only.  guess we will have to check and see.

#17

Server side is authentication, while it keeps out hackers, also allows for more flexibility. 
Never mind about though. 

Do have a look at this library I wrote some time back : https://developer.coronalabs.com/code/validation-auto-renewable-app-purchases
It helps validate susbcription receipts (server-side and client-side).   It is iOS only though. 

#18

yes, auth is authentication. that’s a nice sample.

#19

@Satheesh

Were you able to get auto-renew subscription working on Google? We are in the midst of giving it a try, and whenever we make a store.purchase(subscriptionProductID), we get the following error. The same code works fine for none-subscription productID. If you have any suggestions, that would be most helpful. Thanks!

I/Corona (24366): DEBUG: txn.state failed I/Corona (24366): DEBUG: txn.date nil I/Corona (24366): DEBUG: txn.identifier nil I/Corona (24366): DEBUG: txn.productIdentifier nil I/Corona (24366): DEBUG: txn.receipt nil I/Corona (24366): DEBUG: txn.originalDate: nil I/Corona (24366): DEBUG: txn.originalID nil I/Corona (24366): DEBUG: txn.originalReceipt nil I/Corona (24366): DEBUG: txn.errorType -1008 I/Corona (24366): DEBUG: txn.errorString IAB returned null purchaseData or dataSignature (response: -1008:Unknown error)
#20

@akao Yes, we did manage to get auto-renewable subscriptions working in Play Store.

I never got the error which you have mentioned above,though.  So sorry, I have no idea

A quick google seach gave this.   
Maybe this is a Corona thing? What build are you using?