I’m currently implementing IAP’s for our game. I’ve got Google IAP’s working perfectly with additional logic running in “RegisterAfterValidatePurchaseGoogle”.
Now I’m trying to do the same with subscriptions but dealing with a few road blocks.
Issue 1: I don’t seem to have an equivalent to “RegisterAfterValidatePurchaseGoogle” but for subscriptions. I.E.: RegisterAfterValidateSubscriptionGoogle. As such how would I be able to know the user just subscribed?
Issue 2: What value should we use for iap.google.notifications_endpoint_id?
I’m pretty confident we have the setup from google play done correctly as I can see the messages when pressing pull in the Google Cloud Pub/Sub webpage.
The subscription name given by google has the following format (I anonimized these values):
The value provided in the Nakama documentation is as follows:
I see no overlap in either of these and end up having no idea what to use as notifications_endpoint_id.
Should it be:
I tried both but had no success in having nakama identify the renewal of a subscription.
I’ve even added the iap.google.package_name and set the iap.google.refund_check_period_min to 1 in the config.yml but that doesn’t seem to fix anything either.
I’d really appreciate some help/guidance. We’re using Golang for the backend logic in Nakama 3.14.0 as we had to downgrade from 3.15.0 due to this bug.
To clarify, here is an anonimized version of the relevant part my current config.yml:
private_key: "-----BEGIN PRIVATE KEY-----\nA_REALLY_LONG_AND_SECRET_KEY=\n-----END PRIVATE KEY-----\n"
On issue 1: those hooks were omitted by an oversight on some versions of the server, I believe they are included in 3.15 but I see you had to downgrade, we’re close to releasing v3.16 which should solve the issues you’re having.
Issue 2: You can use whatever string is URL safe, the idea for the terminating URL path to be configurable is just so that not all Nakama deployments have the same endpoint set up automatically, and also act as a toggle to expose the endpoint. You could use a randomly generated string, or something like “notifications”. The full URL will be printed in the logs after server startup if the configuration is present. The full URL is then what you should configure in the Google console. Your current configured value of ‘MASubs-sub’ should work .
Unfortunately, while v3.15 introduced the regression you mentioned, it also fixed a lot of bugs around notification handling, which is likely why you aren’t seeing the renewals. As I mentioned, stay tuned, v3.16.0 should be out really soon. Alternatively, you can build the master branch from source.
Also bear in mind that the server will only handle renewals that have been previously validated using the corresponding API.
Hi sesposito, first and foremost, thank you for getting back to me.
I’ve been focusing on a different project waiting for the release of Nakama v3.16 and finally was able to focus back on the project I was having the issues with.
Issue 1: Solved by upgrading to v3.16. Great job guys! Thanks for all the effort!
Issue 2: I’m finding it very difficult to know if I have everything set up correctly and the feature isn’t working or if the feature is working but I didn’t configure everything correctly.
In my mind, I would ideally be able to run a piece of code when the subscription gets renewed. Perhaps this is not the way the system should work but I cannot find any further information on this topic anywhere else.
Long story short, how can I test if subscriptions are being renewed and can I run a piece of code when the server detects the renewal? At the moment I’d simply like to run a debug log in order to know that things are indeed working as expected.
Thank you very much for your time and attention.
Thanks for the kind words @juliobds,
If you run the server in
debug, it should print a log when a notification is received (but it won’t specify whether a subscription was renewed or not).
The best way right now would be to see the
expiry_time be updated for a given subscription after a renewal happens. You can see the current value of the expiry time in the Nakama console under a given account who has an active subscription (which was previously validated using the related API). The docs are a bit outdated so the
subscriptions tab is not present there but you should see it in your Nakama version.
We haven’t yet implemented custom hooks for renewals, there are a few reasons for this, the main one being that it’s hard to streamline the API so that it’s the same for each provider, since the notifications are much different between them. However I’d suggest you create a Github issue with a feature request in the Nakama repo for it and we’ll consider it in a future release.