Faster In-App Billing Subscriptions Testing

Monica Curti
4 min readAug 7, 2017

--

At Memrise, we have been using Google Play In-App Billing subscriptions for almost two years now to sell our Pro features with recurring billing. In this post I will explain how Memrise has contributed to simplifying the payment testing process for In-App Billing subscriptions.

To give you a bit of background, here at Memrise we have quite a straightforward release process of weekly releases, which involve half-day regression (checking all features in a given build) to test new and key features in our app. Once the regression is completed, the candidate build stays in beta for one week before getting released to production the week after.

We have opted for weekly releases to assure high-stability and introduce a form of quality control. However, while it has allowed us to get our crash-free user rate above 99% across all devices, it has also driven the need to reduce friction in our process as much as possible. Prior to improving the In-App subscription testing process, we had to create builds to enable our QA team to test payments for every weekly regression!

Requirements for testing payments prior improvements

For some of you, these requirements might be well-known so I’d suggest you skip this section and go straight to “Improved In-App testing — New Process” below. However, I still feel it might be good to give a quick overview of how the process has evolved, what our main obstacles were, and what to expect.

So if you have implemented In-App Subscriptions before, you probably know that to test payments and avoid running into the following message shown below, we had to set versionCode and versionName of our testing build identical to our Production build. (Note that the same error message is triggered when your productId is not active yet, but this is out of the scope of the article.)

To avoid running into the issue below, the build also needed to be signed with the release certificate.

While the new process will allow you to get rid of the two steps described above, whoever is responsible for testing the payment build will still have to enable the testing access to their primary account (the first gmail account configured on your device) on the Play Console to avoid being charged for payments. See the image below for reference.

From Settings > Account details, go to the License Testing section, add the addresses to Gmail accounts with testing access field.

Unfortunately, more often than not we have seen issues surfacing while testing payments during regression.

To be able to debug those payment issues we (developers) had to run a debuggable build, while changing versionName, versionCode, and sign the APK with the release certificate (you could use a flavour for that).

Once the issues were fixed, we had to resend the payment build to QA to test it. This led to another potential issue: since the new build with the fixes had the same versionName as the previous ones, there might be confusion as to which was the latest build and which needed testing. On top of that, if you counted the time that gradle requires to build your APK simply because you needed to change versionName and versionCode, this amounted to a long drawn-out process.

Ok, enough talking about issues and endless requirements, let’s get to the fun part!

Improved In-App testing — New Process

Last year, my team and I had the opportunity to present suggestions for improvements and solutions for the Google Play Console. Our first point was to highlight the things I’ve described above, the endless steps needed for testing payments thoroughly. We then explained how our process at Memrise could become much quicker if the “Testing access account” was used not only for regulating the payment charge, but also for fully regulating the payments availability.

As result, the Google Play team implemented the solution we suggested and recently released it: now there is no longer a need for a signed build, you can just use your debug build to test payments directly. The days of figuring out which versionName and versionCode needs to be associated with the build or how to track the build versions are also gone.

As long as your device’s primary account has testing access in the Play Console, you can test payments in any builds straight away.

And the best outcome from this — our QA team no longer needs specific payment builds, which saves a significant amount of time from building the apk.

We are thrilled to see this great improvement on the Play Console, which has allowed us to remove further frictions from our release process.

For further info, check the Google docs here.

Memrise is Best App of 2017 at the Google Play Awards, and selected as one of Android Excellence Apps.

Thanks for all the Memrise reviewers, in particular Nick, Stefano, Josh, Kristina, Beatrice and a big shout out to the Googlers for their support.

We are hiring!

Monica Curti

Lead Android Developer @Memrise

Sign up to discover human stories that deepen your understanding of the world.

--

--

Monica Curti
Monica Curti

Written by Monica Curti

Lead Android Developer @Memrise

Responses (3)

What are your thoughts?