CODEWITHSUNDEEP
androidlaravelfirebase-cloud-messaginggoogle-cloud-pubsubin-app-subscription
ShaRy
ShaRy

Reputation: 87

How to setup Google RTDN and Pub/Sub Properly with Backend and Android App?

Can anyone guide me on this regarding Pub/Sub and RTDN. I have an app with in-app subscription, So when users take any subscription my app unlocks some features for them, and meanwhile on the go, I am sending this data to my server. Now the supposed users have canceled or paused their subscription and my app didn't know about this also there's not enough information available in the queryRecenterPurchases method. So here according to google docs. they've provided and want us to use Real-time Developer Notification with Pub/Sub.

So up till now, I managed to understand all this and how it's going to work BUT now i have some questions in my mind and want to know if I am mapping it the right way. Also, can any buddy suggest or recommend to me the best third-party in-app subscription model and will it be safe to use?

e.g: Pusher, Purchasely, Namiml...etc

Or I can do all this without this using. e.g: Firebase Messaging Service (FCM) and OneSignal.

So, at this point, I know how can I sync google in-app purchases with my server BUT how can I notify my app about these changes? My backend is in Laravel. Remember, I don't want notification but some sort of messaging mechanism so whenever the user opens my app gets a notification message from my server or whatever that this user has an opt-out from the subscription.

Idea!

Upvotes: 0

Views: 1467

Answers (1)

jfgrang
jfgrang

Reputation: 1178

<disclaimer> I created Purchasely </disclaimer>

Your architecture schema is perfectly fine. I'd like to add some informations:

  1. The endpoint https://my-app.com/subscription_cancel will receive a LOT of different events and not just the cancellation events
  2. Cancellation doesn't mean that you should block the users' access, it just means that the user cancelled the renewal and that it will expire at the end of the period. Until then he should still be able to use its subscription.
  3. What you receive from Google isn't as clear as handling a state like "cancel", "expire", "refund" … in fact you got to infer them by watching several variables you will receive in the payload of the Pub/Sub notification (expiryTimeMillis, paymentState and autoRenewing)
  4. There are 6 different states that you should handle but that list might / will probably change in the future as the Google Billing evolves.
  5. Doing the same thing with Apple S2S is completely different even if it ends up being the same thing for you.

So your endpoint is a sensitive thing here and handling subscriptions status is complicated even with just one platform (Google).

Most apps check the subscriber status on app launch or before accessing the paid feature / content. If you want to act in real time, once your have received the notification from the store, analysed the message, you can use Pusher / One Signal / Firebase for real-time alerting.

<promo> If you don’t want to handle that part yourself, don’t hesitate to reach us (we even have a Firebase extension for your app to be notified in real time with 0 backend development).</promo>

Upvotes: 3

Related Questions