Subscription Backend service?

Solar2D General Questions/Discussion
#1

We have been working on converting one of our apps to subscription. As part of the effort, we realized that we need a backend that can help us track the subscription status… We looked around, but didn’t really see anything that supports Corona. 

I am curious if others have run into the same problem and how have they solved it. We ended up building one ourselves. It took a lot of work, and we seem to be always spending time expanding its functionality. 

Really interested to see how others have solved the problem? 

#2

@akao - I asked a similar question a few days ago but I was asking about two specific services - playfab vs. gamesparks

I know developers have had success with both of these so I wanted to understand why you would choose one over the other - specifically, which features attracted developers.

#3

@akao You should be able to do that and more with Coronium Core. It’s built specifically for Corona, and has been around for many years. It even has its own sub-forum here https://forums.coronalabs.com/forum/643-coronium/

Learn more here: https://develephant.github.io/coronium-core-docs/

I’m available here for live questions and support.

-dev

#4

Yes, I second that!  Coronium is what I use now and it’s great.  I’ve been exploring the features of playfab and gamesparks for some potential future projects that would take too much time for me to manage myself.

#5

We checked out playfab 2 years ago for a project, while it seems like a really good general purpose game backend, it doesn’t have what we need the most which is the Server-to-server integrations that we need with Google/Apple. These S2S integrations allow us to capture user cancellation & renewal events so that we can properly calculate things like churn, LTV, etc with the goals of being able to respond to these events at some point. 

We have already started building out a server using Azure Functions. However, the complexity of the integration, and the difficulty of testing through all the edge cases is very time consuming…

#6

We’re also working on this exact problem right now.  Handling receipt validation for Google and Apple subscription, and receiving server to server notifications from Apple and Google Pub/Sub for the subscription lifecycle.

After searching we couldn’t find a good solution so built our own NodeJS backend.  It includes user creation from the web and mobile so they can login and transfer subscriptions across platforms.  I’m not a great web developer but Node has been pretty fun to work with, I just started in December and now have a full subscription website where you can play all of our games via HTML5 Corona builds.  The subscription payment there is handled by Stripe.

The plan right now is to launch subscriptions via Google Play in late February and if that’s successful follow with Apple in the Spring.

You can checkout our website now if you’re curious: www.rosimosi.com

Let me know if you have any questions about the receipt validation and server to server notifications, since I’m neck deep in both right now.

#7

@kbradford Sounds like we are coming from the other direction.

We actually have spent the past few months building the subscription backend for iOS/Google first, and is now looking at expanding into the web. We first hired it out and had something built using NodeJS. We ended up scrapping that, and rebuilt it using Azure Function when we brought it in-house. (We are more comfortable with c#, and also prefer not having to worry about maintaining a server). Since we are trying to do some UA, so we ended up adding lots of integrations to attribution, analytics and other systems to make it work. It’s been a shocking amount of work with too many gotchas. You can check out Wonster Words to see what we have. 

We are looking at the web, but frankly fearful of what lays ahead. 

I would be interested to connect to share notes if you like. Sounds like we could both benefit. 

#8

Sure, drop me a line anytime.  We did the web stuff first to get all the user management stuff in place.  It also helped learning about the subscription lifcycle from Stripe which has amazing documentation and examples.  Then going to Apple/Google requires the same mindset, but their documentation is much messier and examples are all in native code.

Not to mention, if I have a user subscribe via Stripe I pay like 3% instead of 30% commission!

#9

@kbradford - I like your site!  That’s a cool idea.  Keep us posted on your journey.  

#10

Hi @akao @kbradford,

How did you find the journey to building a user + payment backend system? Appreciate any pointers to do or avoid.
I’m currently contemplating adding web access to our apps + option to register and purchase subscription directly from our website.

#11

You realise that breaks all the store policies? Just look at Epic.

#12

Hi @anon63346430, We have no intention of dropping apple main payment scheme. This is aimed for schools registration and other platforms where there is no other payment mechanism available.

#13

For schools, you should take to look at Apple’s Volume Purchase Programme for Education.

You can use external payment schemes as long as your product/service isn’t delivered or accessed via the app itself, e.g. a food delivery or a ride hailing app. If you are delivering the educational content via the app, then you need to use what Apple provides you with or you’ll likely get kicked off the App Store.

#14

Hi @XeduR,

Thanks. This however is not aimed for Apple store.

#15

@rune7 Hey, our system has been running for about a year now and we’ve had some hiccups but overall it’s been very successful. We handle subscriptions from Apple, Google, Amazon, or via our website using Stripe. If you have any specific questions I’d be happy to help.

Do note what SGS said, if your app lets you purchase a subscription outside of the App Store then you’re going to get in trouble. As in, if your app opens up a web browser and you pay via that, then you will probably get kicked off the app store.

We do sell our software via our website too, but just don’t link to that or provide it as an option inside the app. The users would have to find that on their own, via Facebook, or our email marketing.

#16

For those curious about Apple’s policy on purchasing via other sources, here’s the relevant guideline:

3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.

#17

Hi @kbradford,

Thanks. I’m mainly curious if you chose to build your backend from scratch or to use an existing solution and what technology stack you have chosen to use.

#18

We did it from scratch using Node/Express/MongoDB. First phase was just a website with our games exported from Corona using HTML5 builds, and users could pay via Stripe to access it. This gave us the basics of a user management/subscription engine, and then we added code to handle Google, then Apple, then Amazon.

Each app store has its own design and system for managing subscriptions so it’s no small feat. All in it took me 3-4 months to build the basics and we’ve continually fine tuned and improved and fixed the system over the last year.

#19

Thanks @kbradford,

Thanks for sharing your tech stack. I’m a bit unfamiliar with Node but will give it a go.
I also started the journey last year, but more cautiously - first going with subscriptions (long overdue). Now looking to expand it outside the app store. HTML may be something I’ll consider too down the road, however initial tests I did a year ago were not so successful.

#20

@kbradford,

BTW, why did you opt to go with MongoDB vs traditional SQL? wouldn’t it be easier to manage users state in regular table?