August 13, 2014 at 13:09Errors in checking Android-iOS internal payments and their solution
Disclaimer . This post is based on a report on SQADays'15. You can also watch a video presentation or browse through the presentation . I draw your attention to the fact that the report was an entry-level one, that is, the post will be interesting mainly to managers and novice testers. And also the fact that the author is a fake welder and in some places makes rather rough roundings.
My name is Alena, and I'm a release manager. The department of i-Free company in which I work is mainly engaged in applications for iOS and Android. We also support Tizen, Windows Phone, alternative parties, but in this post we will talk about the Apple iOS Appstore and Google Play.
In both markets, in addition to paid and free applications, it is possible to conduct internal payments - in-app (In-App Purchases).
Why am I talking about in-app testing? Because I can!
As a release manager, I usually participate in projects at the beginning of development and at the end of those iterations that end with a calculation in the story. Before starting the project, I give the keys and certificates to the developers, and by the end of the work on the version, the developers give me builds for release. But between these points there is a moment when you need to make internal payments - in-ups and issue test accounts to testers. And at this stage, sometimes something strange happens when the developers think that they are doing well, and the testers - that everything is bad.
To begin with, I will briefly recall how payments are made in mobile applications and what is needed to test them.
So, in one form or another in both markets there is:
The standard scheme for buying in-app in mobile stores:
Paragraphs 3 and 4 are relevant only for multiple purchases - they should be, but this does not always happen. Details will be below.
To begin with, in the case of Google Play, we are dealing with a half-sandbox. We will use real accounts that are marked as “test” in the development account. At the same time, a bank card should be attached to the account, but in fact there will be no deductions from it. Well, thanks to the openness of the platform itself, we have full-fledged logs and easy installation of builds.
So what you need:
When we click on the in-app, we see a window with the signature "this is a test payment." The purchase is almost instantaneous and completes successfully; money is not debited from the card.
In the application, we are accrued the required benefits
You can test payments only on the build of the same version as in the admin panel. But since testing was introduced not using draft builds, but through a beta test, this error should occur much less frequently.
What to do:
If, in fact, everything is fine with the Internet, it is almost always treated by switching from 3g to wi-fi or from wi-fi to another wi-fi.
The promised retreat. In many markets there is a difference between one-time and reusable in-app. It was also on Google Play, but since February 2013, version 3 billing was introduced . Since then, in-ups have been “managed by Google” and “managed by the developer”, and whether it is possible to buy them several times depends on how the developer processes them (a concise or not).
In fact, the user should never see this error. If this happens, either the developer uses the one-time in-app as reusable, or Google twisted the purchase between Google Checkout and Google Play, you need to wait a couple of hours and / or reboot.
This is usually a buyers problem due to an incorrectly configured Google Checkout.
What to do:
Or Google said that the payment was successful, but the application said no.
It is important to understand that in this case the problem is on the application side. That is, if Google replied that the payment was successful - it always sends exactly that answer. But the application must still be able to process it!
You can also remember the words license key . The fact is that a small line of numbers and letters, which certifies in-ups, paid applications and the downloading of additional content, is now unique for each application. And if for some reason you make two versions of the application (into the Russian and international markets, or the paid and free versions, for example), there is a chance that someone will forget to change this line somewhere. The words spoken in time “are we all right with the license key?” Can save a few claps with one palm on the forehead.
But Apple is waiting for us a full sandbox. But does this mean that it will be easier for us?
So, no real cards and real accounts. At the same time, the test account is tied to the store of a certain country, this is important. You don’t have to upload builds to the admin area yet, so with the exception of issuing test accounts, this part goes without my participation.
But it’s not so simple - they are enlightened! Roughly speaking, these are lists that list which developers have the right to build an application with a specific identifier, and on which devices you can put the resulting build.
Well, two admin areas - Tunes Connect for promotional materials, Member Center for developers.
When you click on the in-app, a window appears with the signature [Enviroment: Sandbox].
This is a completely non-existent account, but e-mail should be unique among both test and real accounts. He does not need to enter credit card information, and the date of birth is entered once at creation in the admin panel. If the test account on the device asks to enter something other than the username and password - you broke it. Absolutely. It is necessary to make a new one.
If you press the “continue” button on such a plate, you will be asked to enter information about the payment instrument. This means that you incorrectly linked the test account. It can be attached to the device in only one way:
All other methods will not work and will break the account, you have to make a new one.
Also an error related to the account. What does this mean:
A very strange mistake, there is no such restriction. But you may come across a similar one with persistent testing of subscriptions. Personally, I haven’t met, the only advice is to be careful when testing iOS subscriptions :)
It may appear on the device with a jailbreak or with an extremely poor Internet connection. Personally, I haven’t met, advice - if possible, do not test on devices with jailbreak. Unless, of course, this is not part of your target audience.
The report was read on April 18, since then the situation has not changed much, with the exception of the way the builds of Google Play are laid out for testing. It used to be easy to get the build as a draft, but now you need to publish it in beta, which, on the one hand, increases the number of necessary materials at this stage (you need to have an icon, screenshots and description right away), but on the other hand, it makes it easier to update the build to those who are interested in the development, but do not go deep into testing. For example, PM or designers, they simply get the push “new version” as from a regular application.
If you met any other mistakes of the store itself when making internal payments, it will be interesting to read about them in the comments.
My name is Alena, and I'm a release manager. The department of i-Free company in which I work is mainly engaged in applications for iOS and Android. We also support Tizen, Windows Phone, alternative parties, but in this post we will talk about the Apple iOS Appstore and Google Play.
In both markets, in addition to paid and free applications, it is possible to conduct internal payments - in-app (In-App Purchases).
Why am I talking about in-app testing? Because I can!
As a release manager, I usually participate in projects at the beginning of development and at the end of those iterations that end with a calculation in the story. Before starting the project, I give the keys and certificates to the developers, and by the end of the work on the version, the developers give me builds for release. But between these points there is a moment when you need to make internal payments - in-ups and issue test accounts to testers. And at this stage, sometimes something strange happens when the developers think that they are doing well, and the testers - that everything is bad.
General information about in-app testing
To begin with, I will briefly recall how payments are made in mobile applications and what is needed to test them.
So, in one form or another in both markets there is:
- Sandbox for testing payments
- The mechanism of test accounts, so as not to spend money
- Test builds and test devices
The standard scheme for buying in-app in mobile stores:
- First, the user clicks on the "buy" button and enters the password. The purchase itself goes through, the site mechanisms work
- Purchase information is transferred to the application
- Consumption of purchased in-app (consume)
- In-app becomes available for re-purchase
Paragraphs 3 and 4 are relevant only for multiple purchases - they should be, but this does not always happen. Details will be below.
Test specifics of Google Play In-App Purchases
How to test and what you need for this
To begin with, in the case of Google Play, we are dealing with a half-sandbox. We will use real accounts that are marked as “test” in the development account. At the same time, a bank card should be attached to the account, but in fact there will be no deductions from it. Well, thanks to the openness of the platform itself, we have full-fledged logs and easy installation of builds.
So what you need:
- Developer account with test accounts declared in it
- Test account with a card attached to it and participating in a beta test
- App build published in beta test
- Test device logged into the test account. Download the build from the beta test on it.
What it looks like when everything is fine:
When we click on the in-app, we see a window with the signature "this is a test payment." The purchase is almost instantaneous and completes successfully; money is not debited from the card.
In the application, we are accrued the required benefits
What can be when everything is bad?
Error -№1 build version mismatch
You can test payments only on the build of the same version as in the admin panel. But since testing was introduced not using draft builds, but through a beta test, this error should occur much less frequently.
What to do:
- check if versions match on device and admin panel
- wait - the just downloaded version may not be visible to the application for two or four hours.
Mistake # 2 - Bad Connection:
If, in fact, everything is fine with the Internet, it is almost always treated by switching from 3g to wi-fi or from wi-fi to another wi-fi.
Error No. 3 - buy purchased:
The promised retreat. In many markets there is a difference between one-time and reusable in-app. It was also on Google Play, but since February 2013, version 3 billing was introduced . Since then, in-ups have been “managed by Google” and “managed by the developer”, and whether it is possible to buy them several times depends on how the developer processes them (a concise or not).
In fact, the user should never see this error. If this happens, either the developer uses the one-time in-app as reusable, or Google twisted the purchase between Google Checkout and Google Play, you need to wait a couple of hours and / or reboot.
Error No. 4 - [letters and numbers in square brackets]
This is usually a buyers problem due to an incorrectly configured Google Checkout.
What to do:
- standard rituals: reboot and wait a bit
- last resort - clear Google Services data
Everything seems to be fine, but in-app did not accrue
Or Google said that the payment was successful, but the application said no.
It is important to understand that in this case the problem is on the application side. That is, if Google replied that the payment was successful - it always sends exactly that answer. But the application must still be able to process it!
- What to do? Wait for programmers to fix it
- This is critical, such in-ups disappear without a trace!
- Most likely, this is a server error related to the signature
You can also remember the words license key . The fact is that a small line of numbers and letters, which certifies in-ups, paid applications and the downloading of additional content, is now unique for each application. And if for some reason you make two versions of the application (into the Russian and international markets, or the paid and free versions, for example), there is a chance that someone will forget to change this line somewhere. The words spoken in time “are we all right with the license key?” Can save a few claps with one palm on the forehead.
IOS Test Specifics
How to test
But Apple is waiting for us a full sandbox. But does this mean that it will be easier for us?
So, no real cards and real accounts. At the same time, the test account is tied to the store of a certain country, this is important. You don’t have to upload builds to the admin area yet, so with the exception of issuing test accounts, this part goes without my participation.
But it’s not so simple - they are enlightened! Roughly speaking, these are lists that list which developers have the right to build an application with a specific identifier, and on which devices you can put the resulting build.
Well, two admin areas - Tunes Connect for promotional materials, Member Center for developers.
What you need for testing:
- The "skeleton" of the application in iTunes Connect, only after that you can start in-ups
- Test account of the country where the application is registered
- Member Center Test Device
- Properly assembled build installed on the correct device
What happens when everything is fine:
When you click on the in-app, a window appears with the signature [Enviroment: Sandbox].
What to do when something is wrong?
First of all - important information about iOS test accounts
This is a completely non-existent account, but e-mail should be unique among both test and real accounts. He does not need to enter credit card information, and the date of birth is entered once at creation in the admin panel. If the test account on the device asks to enter something other than the username and password - you broke it. Absolutely. It is necessary to make a new one.
Mistake # 1 - you need to enter payment information
If you press the “continue” button on such a plate, you will be asked to enter information about the payment instrument. This means that you incorrectly linked the test account. It can be attached to the device in only one way:
- All real accounts must be untied from the device
- Go to the app
- Tap on in-app
- And enter the login password
All other methods will not work and will break the account, you have to make a new one.
Mistake # 2 - you cannot make this purchase
Also an error related to the account. What does this mean:
- Installed application is not available in the country of the test account
- Application and test account belong to different developer accounts
- You are using a real account
Mistake # 3 - limit on the number of purchases
A very strange mistake, there is no such restriction. But you may come across a similar one with persistent testing of subscriptions. Personally, I haven’t met, the only advice is to be careful when testing iOS subscriptions :)
Mistake number 4 - but you are not a test user!
It may appear on the device with a jailbreak or with an extremely poor Internet connection. Personally, I haven’t met, advice - if possible, do not test on devices with jailbreak. Unless, of course, this is not part of your target audience.
The report was read on April 18, since then the situation has not changed much, with the exception of the way the builds of Google Play are laid out for testing. It used to be easy to get the build as a draft, but now you need to publish it in beta, which, on the one hand, increases the number of necessary materials at this stage (you need to have an icon, screenshots and description right away), but on the other hand, it makes it easier to update the build to those who are interested in the development, but do not go deep into testing. For example, PM or designers, they simply get the push “new version” as from a regular application.
If you met any other mistakes of the store itself when making internal payments, it will be interesting to read about them in the comments.