In apple's document, it says developer can use the applicationusername to Detecting Irregular Activity，but i don't know how to use it.The document just says hash a userId,but how can i detect the irrgular activity? Does the apple's server have a server API to notify me ?
Here the link:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/RequestPayment.html#//apple_ref/doc/uid/TP40008267-CH4-SW6
Let's day your app uses an account system so each user has an identifier (email, username etc) which we refer as appId here and the app store login as appleId
Scenario:
Say user purchased a subscription with a trial period (txn123) with appId usr123 having appleId appl123
Later she unsubscribed the subscription.
After few months she changed the AppleID for some reason.
Again she wants to purchase the subscription.
She will login into the app using same appId, usr123.
As she already has used trial with that appId, your app will recognise her, and will show buy button to her.
When she will click on the Buy button, Apple UI will show that she is eligible for Trial, and will be charged after 7 days.
If you had passed the applicationUserName field in the payment(payment object) in the both the transaction user makes, apple will recognise that and may take a remedial action (like actually charging the user instead of offering a second trial period).
At this point I am not sure, how Apple is going to inform your app/ecosystem about this irregular activity. I have not tested this scenario myself as yet, will update the answer once I have done so.
Several things may happen:
Apple declines the second purchase because it detects the irregular activity of the same user purchasing the trial period again. But how would Apple know if the user is intentionally trying to make the purchase now after trial has expired. Anyways, apple can say that this user seems to be associated with some other apple id also which has made a purchase in the past, thus not allowing the transaction with the pair.
Apple may actually charge the user, since they are trying to buy after a trial but in this case Apple will be offering a Apple Id user without a trial period in their name.
Apple may allow the transaction with trial period offering and may resolve this through other/offline channel.
Related
We have a app with a auto renewable IAP for which we offer a initial trial period to the user and charge once the trial period has expired. Our app maintains user account management(user login) and all features (including the IAP) are accessible only when the user is logged in.
There are two scenarios to consider:
Case 1: A new user(app user) opts to purchase the subscription for trial period on a device where she's logged in with her apple id. She later(post expiry of the trial period) installs the app on another device and signs up with a different app account but uses the same Apple Id. Since Apple Ids are opaque to the app, the app has no way to know that this user has already purchased trial, so the app UI presents them an option to start with a trial period. Since the Apple Id used is same, the user will be charged.
Although, this scenario is rare and can be justified on the pretext that the same Apple Id is used so the user is supposed to be charged, but it is fallacious on part of the app to suggest that trial period is available for the new app user(different login id)
Also, the user might not be intentionally doing it to avail a second trial period, but might have forgotten about the previous purchase and may use an alternate email next time they sign up.
How do you prevent the user to be charged if they have already used up the trial for the same Apple ID, or if there's a way to know if the current user(Apple ID user) has already made this purchase in the past, so that you do not show them trial option anymore. Would restore purchases help in that regard?
Case 2: The same app user may intentionally change the apple id on the new/same device to avail multiple trials. While your app will detect the user has already purchased the trial, you may choose to let the user not show the subscription purchasing UI but if you do the purchase workflow on part of Apple would still consider it to be trial period(new apple id) and not remit you the payment for the same.
How do you circumvent these conditions or if there's a flaw in my understanding where these situations would not occur at all.
For case 1: maybe the following may work, but not sure:
Whenever there's a new login to the app, the app should either refresh receipt or ask to restore transactions to the user(this can be frustrating for actual first time users) and the receipt validation should be performed to check if the user had previous purchase and if the transaction id is linked to some previous user. This is basically a kind of self managed restore. But still in this case, the new user will not be able to get the trial period, you can just prompt that the current apple id is already used for trial.
Please suggest if my understanding is correct.
Background:
I am trying to implement In-app purchasing for my iOS app. The app allows the user to be able to log in to multiple accounts and register multiple accounts. Each registration will require the user to pay a subscription fee (unless a free plan is selected). When the registration is complete the account will be linked to the Apple ID that paid for the subscription.
Question:
If already have done a registration with my current Apple ID(Account A) with a $0.99 subscription every month and then do another registration with the same Apple ID(Account B) with a $1.99 subscription every month. Both accounts have purchased a subscription with the same Subscription Groups. In that case will that Apple ID just be paying for the subscription of Account B since it would be considered an upgrade from Account A.
I can make it so that when an account is created with an Apple ID that have been used, we link the new account with that Apple ID and disable the older one. This would however provides a bad user experience and only ever one account will work with one Apple ID and probably isn't the solution I want.
I did try to set the ApplicationUsername for SKPayment object in hopes that it will appear on the other side when the notification API is hit by Apple but it don't seem to use it for that and is used to detect fraudulent activity.
I am trying to find some documentation on handling this case but to no avail. I'm not too sure how to get around this issue and have a feeling that my app's implementation is not aligned with how Apple expects us to implement it. Maybe I have misunderstood some documentation but any insight to this would be greatly appreciated.
I'm working on an iOS app where a user must sign up/sign in to an account for my app. To be able to use my services I want users to pay via in-app purchases (auto-renewing in my case). This would then tie their IAP to their account (they created with us) to be able to use on any other iOS device.
Case 1:
For example if a subscription was bought on phone A for an account, when signing on to phone B (using the same account) shouldn't make the user pay again.
Case 2:
Or if a subscription was bought for account A on a phone, when signing up for account B on the same phone should make the user pay for account B.
Basically I want an in-app purchase to tie to my account (rather than a apple device/Apple account which is how it works to my understanding.)
I understand that their are receipts which is probably part of the answer to my question. Or if this a limitation to in app purchases what other ways can this be done (other than using Apple's IAP)
The answer to the title of the question:
When a purchase is made there is an update received in the app, the next time it is launched which contains a transaction_id (original_transaction_id for renewals), you should associate this transaction id with your app user id.
Case 1: Apple provides an option to "Restore Purchases" in your app. Since, the same account is used, your app servers would already know that a user has already paid and the app shouldn't prompt the user to pay again. However, in order to receive the upcoming renewal updates on phone B, you must "Restore Purchases" which would let Apple link the previous purchase on this device as well. Once the restore is done, the users purchase receipt will be available on the device and all subsequent actions should be taken based on the content validation of the receipt.
Few points here:
Apple will reject your app, if it doesn't provide this option to the user.
Even if your app is buggy, and you failed to restore purchases, user wouldn't be charged again. The purchase would fail saying you already have purchased this.
The above case is completely based on the assumption that the user is using the same Apple Id on both the devices(same application user id doesn't matter).
Case 2: I am not sure if that is anyhow possible. Since it's the same device, the user uses the same AppleId(unless he signs out and changes apple id in App Store) and Apple will restrict the repurchase. At best you may restrict the account B with the subscription content but if your application allows multiple accounts on the same device use case(e.g Instagram), I am not sure if there's a provision for the same.
I tested the same scenario for a music service app I use. Have an active subscription, logged out and signed up with other email (app), but the purchase was denied alerting I have already purchased. However, it was allowing me upgrade and downgrade options. I didn't opt for testing them so not to mess up my account.
P.S: There are a lot of other caveats/gotchas to take care of. Some of them:
In case 2, apple restricts the repurchase but it doesn't restrict if the user chooses an option other than the current active subscription, which will upgrade/ downgrade the subscription. Based on how you have implemented things, it might even change the subscription for user A immediately or next time the user logs back in or on next renewal thereafter.
In both the cases discussed here, user uses the same Apple Id, but consider the cases - same Apple Id different app id AND different Apple Id and same app Id. (See this)
For case 2, you should always refresh receipts or restore purchases(if there's no receipt available) for a fresh user login. The receipt has a original transaction id which you should have linked the first time the purchase was made with user A. Based on the receipt, you can either choose to let user B access the content or restrict. However, you cannot let the user pay for the new account(I suppose so).
Helpful Links:
Restoring Purchases
Receipt Validation
Situation:
- User makes an IAP and is awarded some content, we store the users device id to ensure they can access this content whenever they want.
- User decided they do not like the content, so they call Apple and get a refund.
- User can still access the content, even though they have been refunded for their IAP
Problem:
We don't want the user to be able to access this content anymore. This could become a loophole that they would take advantage of. (unlock content, then get refunded and keep their access to said content)
Question:
Is there any way for us to check if a user has been refunded for an IAP with either their transactionId, transactionReceipt, or any other information we may have?
For Reference, I've read the StoreKitGuide, it did not mention this case.
No. There is no way to revoke access to content if they have been refunded. I believe this is by design. It is the same with App Store refunds; if someone buys an app and then asks Apple for a refund, Apple does not stop the user from continuing to use the app.
No. you cannot stop user to access. Apple does not stop user to use that feature after refund
Below a recent answer from the overbearing Apple!!!
At April 11
Hello Joe,
Thanks for your quick reply at first.
I think there were some misunderstandings. We understand that you must protect the user information. And we do not require any user info. We do not require any user's information---- iTunes account, User Name, email address and other information about himself/herself.
We require only one data----- transaction id (named "transactionIdentify" in your code), for example "1000000033409668" (this transaction id is a record at March 13).
A user buys a product from IAP, you will generate a "transaction id" and send it to us. This transaction id is stored in our database then. Now he/she gets refunds from you, so please send the transaction id to us. Let us know which one in the game canceled the IAP.
When a refund occurs, we think you should provide the transaction id to us. With these data, we could make a more fair service for all players. If you do not do it, more and more players will use your refund mechanism to get game items without real payment. You and we will lose money then. We think it is very important.
Regards,
Baibo
At April 12
Hello Baibo,
Thank you for following up with me regarding the refund transaction data.
We will not be able to provide you with the refund transaction data you have requested as it is not a feature or benefit provided to you per the contracts you have agreed to.
To view your paid applications contract and review your membership benefits, please access the contracts, tax and banking module within iTunes Connect:
http://itunesconnect.apple.com
If you are not happy with large refunds, you may want to consider adjusting the price of your in-app purchases as we will not be able to provide you with the refund transaction data in the future.
According to an answer one of my users received from Apple, refunding an app means they will no longer receive updates to the app, but doesn't remove the app from the device. IAP appears to work the same.
I am wondering if there is not a way by using restoreCompletedTransactions to check for the iAP purchase, but this would pop up a request for the user's iTunes password, so its use is limited.
I am implementing a digital magazine project for a client. Auto-renewable subscriptions for a period of 3/6/12 months have been included as a feature. My question is while using in-app purchase, is there any way for the server to map the user?? Anyway to identify a particular user is using it? I have done extensive research and know that apple doesn't allow the user's apple-id to be mapped?? Is there any other way to identify a particular user?
The problem arises for subscription. If an user has undertaken a subscription for let's say 3 months, then my app has to show DOWNLOAD button for all the 3 months instead of the regular BUY button. But when a new magazine is launched on to the storefront, how would the app know that this person is subscribed or not and convert the BUY to DOWNLOAD?
When a user buys a subscription, you should store the receipt on your server. This receipt, in a way, becomes your way to identify the user's account. Whenever you want to check the status of an account, send that receipt to iTunes for verification and it'll respond with the latest receipt for that subscription, along with the expiration date. Since you've made a note of which specific device that receipt came from, you can provide the proper UI to that user.
Now, if the user installs your app on a new device they can tap a Restore button that you've provided in your app. That button will call restoreCompletedTransactions which will send all the Auto-Renewing receipts for that user's Apple ID to the device.