Upgrade to Google Play's new subscription model and APIs #1338
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tjmw
approved these changes
Feb 2, 2024
tomwadeson
force-pushed
the
tew/google-api-migration
branch
from
15ef975
to
ba7a276
Compare
tomwadeson
force-pushed
the
tew/google-api-migration
branch
from
ba7a276
to
682a52a
Compare
4 tasks
tjmw
added a commit
that referenced
this pull request
Jun 10, 2024
Use the purchases.subscriptionsv2 [1] endpoint to retrieve data about Android Feast subs, instead of purchases.subscriptions v1 [2] (which we use for the live app). The reason for the migration is that when using the v1 endpoint, we rely on being able to map a product ID to a billing duration. This mapping is defined here [3]. This isn't very robust (in the past, new products have been added in the Play store, but not reflected here, meaning we get rows without a billing period). Furthermore, the was the Feast app has been configured in the Play store, it's not actually possible to map things this way. Instead, if we use the v2 endpoint, we can retrieve the billing period using Play store APIs. Some back story on the v2 endpont: Tom Wadeson did some work to implement the v2 endpoint. In prod there's a test which uses the v2 endpoint in parallel with the v1 endpoint for x% of requests to the subscriptions endpoint. There's a draft PR #1338 to use the new endpoint everywhere, but not merged yet. Using this for Feast feels like a nice step in the migration path as we're using it for real but in a focused context. [1]: https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.subscriptionsv2 [2]: https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.subscriptions [3]: https://github.com/guardian/mobile-purchases/blob/bb1632ea1e53d0fb2ca0e870b67677558a4ea2b9/typescript/src/services/productBillingPeriod.ts#L4
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this change?
This PR migrates us to Google Play's new subscription model (and associated APIs.) See here for more details: https://developer.android.com/google/play/billing/compatibility
Outstanding
subscriptionIds from the Real Time Developer Notifications https://developer.android.com/google/play/billing/compatibility#real-timeHow to test
This is a good question!
There is an existing absence of test coverage for the affected area of the codebase due, I suspect, to the difficulty (impossibility?) of automating any useful/non-trivial integration tests:
To test this manually requires access to the Google Play project; a user account that has license testing privileges (and potentially in the right state—i.e., having not already taken out a subscription, or having not previously benefited from a free trial); and a debug build of the Android app that is configured to surface the underlying
purchaseToken. Testing the lifecycle of subscriptions also has slow feedback loops as we must wait for subscriptions to progress through their various states of activation, renewal and expiry etc. without having the means to control this programmatically.We have conducted many manual tests of this migration effort (and refined the implementation as a result of edge cases that we've encountered), but I suspect that to be entirely confident of this change prior to pushing it live, we would want to run it in parallel with the existing implementation to compare (hopefully) like-for-like.
How can we measure success?
Have we considered potential risks?
Images
Accessibility