The logic of the app.
You register with login password. Then if you doesn't have subscription (checked by server) you go to "Buy subscription page".
Problem.
I register user1. buy subscription. token1 goes to server.
I register user2. as he doesn't have subscription he goes to "Buy subscription page", clicks "Buy", apple says "You already bought subscription" and gives token2 (why does it give different token?)
var receiptUrl = NSData.FromUrl(NSBundle.MainBundle.AppStoreReceiptUrl);
return receiptUrl.GetBase64EncodedString(NSDataBase64EncodingOptions.None);
token2 goes to server. As a result we have 1 bought subscription but 2 users that use the same subscription.
Is there any way to identify itunes of user? to save along the token and be able to check if that itunes user already bought subscription for some server side account
This is a fundamental problem in StoreKit receipts and I think most developers don't realize it.
The problem is that Apple doesn't give developers a way to identify which iTunes account a receipt belongs to. This makes it trivial for a user to share their iTunes credentials with other users and unlock subscriptions.
The correct way to handle this is to, in your database, store the actual transaction_id from the Apple verifyReceipt response, and ensure it is unique in your database. This is a lot of work, so it may not be worth it.
It is further complicated by the fact that sometimes, you want an iTunes account to be usable with different app side accounts. For example if a user creates an account and purchases a subscription, lets the subscription expire, then later creates a new account and tries to purchase again, it should be permitted, even though the same receipt is now being used by multiple accounts.
If you don't want to deal with it, I have a service that handles all these edge cases automatically.
Related
I'm developing an app with non-consumable products. My app need to register and log in for service.
I figure out that the products that user has bought are tied with Apple ID. If user use same Apple ID but different accounts from my server, how will I verify them whether the account buy the product or not?
I have used original_transaction_id to validate it.
Steps-
When any user make a payment, validate the receipt on server.
If a valid payment then update paid in your database and store
original_transaction_id of that receipt.
Next time if the user use same Apple ID, after validating the receipt, check if the original_transaction_id exists in the database or not. If already
exists means user is using same Apple ID for other accounts too,
else its using its Apple ID to make payment first time.
I am developing cross-platform mobile app and using InAppBiling Plugin for my app's in app purchase feature but I have a question about below scenario on iOS:
Scenario:
User A gets the subscription with his app credentials and his Apple ID.
User B uses User A's device and login with User B app credentials but uses User A's Apple ID to buy a subscription.
Currently, it allows that User B to purchase this item but it says that there is a subscription with this user and asks for a permission to modify this subscription.
My question is how to prevent User B to modify User A's subscription? I could not find any solution before the receipt creation. I do not want to allow User B that modifies User A's subscription. I want to inform User B about using different Apple ID to continue to buy a subscription.
Thanks in advance
Your question is related to this one
You have to have backend that is your source of truth about subscriptions.
The situation that you have provided would look like this:
User A gets the subscription with his app credentials and his Apple ID.
You send receipt to your backend to validate it as described here
Your server stores information about subscription and link it with user A
User B uses User A's device and login with User B app credentials but uses User A's Apple ID to buy a subscription.
You send that receipt to your backend as in point 2
Your backend responds that this subscription is already connected with user A
Edit:
As mentioned in apple docs:
Send a copy of the receipt to your server along with some kind of
credentials or identifier so you can keep track of which receipts
belong to a particular user. For example, let users identify
themselves to your server with an email or user name, plus a password.
My original plan for the iOS app I'm developing was to make it free for all users except for administrators of "organizations" stored in a cloud database. These administrators pay a monthly subscription fee to maintain these organizations, and free users join them. An organization's administrator is the only one who can accept new users and set user permissions.
However, I realized that I have no way to check whether an administrator's subscription has expired from the point of view of another users, meaning it may be possible for an administrator to get a free trial, set up an organization, join it from an alternate account, set up permissions, cancel the subscription, and continue using the app as normal without paying. Currently, the only case that the app can handle is if the administrator tries to log into an organization after the subscription has expired.
I planned to avoid this issue by having "active" and "inactive" states for organizations stored in the database, but I still need a way for the app to recognize that a subscription has expired and deactivate the organizations associated with the user in question. I'm not sure how to do this, other than from the point of view of the admin, who could simply stop using the account before the subscription expires, and/or delegate management of an alternate, non-admin account to someone else.
I also realized that this specific setup might violate Apple's policy on in-app purchases, since I am effectively indirectly taking functionality away from free users due to paid users' subscriptions expiring. If this is the case, I'll have to rethink the payment structure of my app entirely. Am I allowed to handle subscriptions this way? If so, how can I a) reliably ensure that my app disables an organization when its admin's subscription runs out, or b) check whether an admin's subscription has run out when another user in the organization tries to log in?
I have uploaded an app for review in iTunes Connect. The apps login procedure is as follows:
User enters his/her mobile number. If the mobile number is new and not in the database, an One Time Password(OTP) is sent as an SMS over the phone to the user and he/she may login.
If the number is already in the database, the user gets directly logged in.
My question is that what should I mention in the dummy account details?
I have mentioned a mobile number that is already in the database so that the reviewer may login and browse my app.
Should I mention the details about an entirely new user as sending OTP to US won't be possible?
Kindly guide.
here is an solution, if apple reviewer can't send OTP then just use this simple trick.
if app reviewer has a login ID/PASS but the OTP is required any of case then just create account for apple reviewer and set Static OTP on this particular account.
tell them ID/PASS and OTP. just simple
I think if you add some registered phone number in "username" section of submit for review form, it will be approved for that procedure.
I have integrated paypal sdk in my application. The app get rejected from apple review team. They want information about account information, including passwords, in the Review Notes section of iTunes Connect App Information. Should i provide my paypal account details in Review Notes? Secondly if they use my paypal account to test , amount will be deducted from my paypal.
If you really need to, create a PayPal account for Apple to test with. You can deposit some minimal amount if need be. Once your app is approved, change the password.
Since the amount will be deposited in your merchant account, you wouldn't really loose the money. (You can also log in to your merchant account and refund the transaction if need be.)
NOTE: Do NOT give out your merchant account info; The transaction will fail if buyer == seller, and you really don't want to give anyone else access to your core business account anyway.