During our efforts to design InApp Billing for our Android App, we came up with the following scenario;
Customer has rooted/manipulatable device (so Market app + my app can't be trusted)
Customer purchases a product
Purchase state 0 (purchased) is send to our backoffice (all is checked and ok), we give credits.
Customer refunds that purchase
Customer has manipulated our app or the market app to locally confirm the refund and thereby prevent the refund notification to reach our backoffice server.
Is this scenario possible? How can we fix this?
It's been 7 years since this questions was asked but still I will provide an answer as it might be useful to some.
The part that is missing in your diagram is your BackOfficeServer to perform server side validation before granting the credits (goods) to the user. As nothing on the client side can be trusted (neither your app nor the app store) your only solution is to integrate your BackOfficeServer with the Purchase Verification API that Google provide. Only when you receive a response from them stating that the purchase is valid should you grant the goods.
The same would apply for refunds. If the user issues a refund you would need to revoke the goods. For this you again can only trust your BackOfficeServer. Google provide Real time Developer Notifications and Void API that can fulfill that requirement.
First: if the user asks for a refund you receive also an email.
Second: the purchases on in-app billing are not refundable directly by the user. If a user wants a refund, he must contact you and then you can proceed manually to refund with your google wallet account.
So i think that your scenario neve happen.
Secondly if possible i suggest you to use managed purchases, in that case if the user asks for a refund, google market will remember it, and you can use a RESTORE_TRANSACTION to check if some refunds occurred (but again: you must grant a refund).
Related
I plan to use non-renewing subscription on SaaS app since apple doesn't allow auto-renewable for SaaS.
Apple also requires us to provide a server side mechanism to track the subscription with multiple devices.
But, based on my research, apple also seems to reject app if registration is mandatory, so such user registration must be made optional.
My app can be used without registration at start, so registering is optional at this point. But, if users want to buy non-renewing subscription, registration is mandatory to track the subscription.
Does apple reject this approach?
Related links:
app rejected.how to track user non-renewing subscription
*UPDATE
I checked the session video of WWDC2012, and it seems it is ok to ask user to register with your server BEFORE purchase for non-renewing subs. I will post an answer once they really approved this method.
*UPDATE
I got an reply from apple through Resolution Center.
The bottom line is we should allow user to buy subscriptions without registration anyway.
This is the answer from apple review team.
It would be appropriate to make registration optional. You may provide
an alert stating that the user will not be able to track a
subscription on multiple devices without registering. However, you
should provide the option to register and track a subscription after
the subscription is purchased as well.
I don't have a definitive answer but my understanding (not just a guess) is that you must permit them to purchase the subscription without making an account. You can warn them that if they don't make an account, their subscription won't be portable to other devices, but you still have to let them move forward without an account if they want.
From a technical perspective, you could treat this as "you must allow the user to make an account without any personal information"; they might have an account on your server for receipt validation, etc, but it's not tied to their name, email, udid, etc. The issue is one of privacy, so as long as it's not personally identifiable info you're storing, it's fine to keep track of the subscription so you know when it expires, etc. (It's nice to later let them enter their email if they want so they can make the subscription portable.)
Of course, what Apple approves or not changes over time and varies for other reasons, so YMMV.
In my android application I want to let users to authenticate with google or facebook account.
I've implemented sign-in with google already.
I'll try to implement sign-in with facebook soon.
I've read about IAP in android:
https://developer.android.com/google/play/billing/billing_overview
https://droidmentor.com/inapppurchase-subscription/
at least what I understand it is about google account authentication.
So I wonder is it possible to make IAP in android application if the user is authenticated with facebook account ?
I cant find examples or explanations by now.
Any good examples/explanations about IAP with google is also very appreciated because I still don't have a clear vision on IAP.
fyi: In my app user will be able to buy "virtual tickets pack" (e.g.: 10, 15, 20 tickets) and to add them to their profile. and later they will "consume" tickets one by one.
Best Regards
My understanding is that you already have a user system that you are using to provide a Google login to your customers. When you add Facebook login, you'll probably want to match both Google and Facebook logins with your own custom user ID. It's always a good idea to have a custom ID of your own so that you can map it to different types of logins.
When purchasing through Google Play Billing, the purchase gets associated with the user's phone Google account and you can also provide an optional way of associating a purchase with your own user account system. In order to do that, when building the BillingFlowParams, call setAccountId and pass your account's system custom ID.
To provide the best experience persisting purchases during installs or across devices you should also be saving the purchases on your server's database. In order to do that in a secure manner, you will also have to implement server-side receipt validation. If you want to avoid most of these headaches, I recommend you to use a service like RevenueCat.
IAP can only be done through the user's google account, as that is what one needs to use any part of the Play Store. The user's google account is also where the credit card/other payment methods are stored for each user.
In spite of the above, the way users log into your app has nothing to do with them using the IAP system. When a user will choose to use an IAP, the google account data will be provided by the android device/Play Store, not by your app (Off subject:the process is similar on iOS if you ever get to try there).
What your app needs to do, is receive the confirmation of purchase from the IAP sdk and then mark on your server that this particular user has purchased this item. Basically for any purchases (no matter the payment provider) you would usually mark in your DB the following:
what the user has purchased
how much did he pay
when did he pay
provider's id of the purchase, so you can later match the accounting reports with the payment provider's report
where he payed from (IP can be a good indicator, although in the age of VPNs not necessarily 100% acurate)(this can be useful for your marketing decisions)
mark that this user now has access to the item he purchased and if it is a time limited item, mark when it expires, so you are able to later check if he still has the right to access it.
Disclaimer:
I have not used the android IAP system directly before. I have implemented mobile app payment systems before using iOS IAP and on android Braintree payments. But the process is most likely very similar with android IAPs as well.
I have a significant problem concerning the billing APIs of Apple and Google (i.e. iOS and Android).
My app has its own user account handling so that the user can switch the device or have multiple devices with data in sync. If it's important: it's a cordova app, but I think the problem is of more general nature.
Now the user can purchase an auto renewing subscription which is (of course) implemented using the APIs of Apple and Google.
The problem is the following situation (for the sake of simplicity only described for Apple, but issue is the same for Android):
User with AppleID X signs in with his account A.
He purchases the auto renewing subscription (obviously with AppleID X) while being logged into his account A. Now account A has the benefit of the subscription.
Now he uninstalls the app and reinstalls it.
He logs into another account B and restores the purchase. Now also account B has the benefit of the subscription.
How can I avoid this which is a major flaw? How can my server identify which AppleID (or Google ID) is linked to which purchase?
A simple way would be to read out the UUID of the user but I know this is not allowed.
Do you have any experience on how to fix the issue? Any help is highly appreciated!
Thanks in advance.
I didn't find any definitive answer for my situation as all of this kind of questions revolve around server-side verification, which is irrelevant to me.
I'm trying to implement in-app billing in my app in order to offer the option of a premium upgrade. I've followed the guides in the developer documentation and done most of the work.
The problem is purchase verification:
The documentation suggests I shoud pass a developer payload to each purchase to uniquely identify the user - but my app doesn't have or need a user system - how can I uniquely identify a user without requiring user input or extra permissions?
Further and more important problem:
When the user makes a purchase, or opens the app after making a purchase in a different time, I need to verify this purchase - I don't have a server where I can send the purchase data to so it can verify it itself or using the Google Developer API.
It is my understanding that I shouldn't verify the purchase locally on the device (using the Google Developer API).
What is the best way for my situation to verify in-app purchases?
Is there a way to do it without a server? (I do not have the knowledge nor resources to have my own server)
I do not know how you would go about verifying a digital purchase without a network connection. Thankfully though, you do not need a user account system nor do you need the knowledge and resources to have a dedicated server because that is what Google Play services is meant for.
After setting up Google Play services; each user will be signed in through their Google Play account and be able to use their registered payment methods within your app when you implement the In-app Billing API. And you can test and manage all of this information from the Google Play Developer Console.
Does InApp billing (V2 or V3) works for a user who uses several accounts and makes the purchase with an account that isn't the primary one?
PD: Some explanation required, no simple Yes/No
In App Billing support multiple accounts reported as a bug in code.google, have a look at it
According to Mr.Sergej (posted in G+ android dev community) in-app products purchased with the first account won't be active anymore while using multiple user accounts!.
InApp billing just charges the user and tells your app whether it was successful or not. It is up to you to figure out how to give the user what they purchased.
You can...
toggle the SharedPreferences of the app to save their purchase. Obviously multiple people can use the same app on the same device with the purchase.
provide login functionality to save a purchase to a server, in case the user deletes the app or gets a new device.
Use one-time purchases to check whether the user has purchased previously. This won't carry over to several accounts on different devices/multiple-accounts-per-device.