I have an app on Apple and Google play store with subscription in-app purchases. I've noticed on the Apple App that people are able to order the subscriptions for less than $1 while the actual cost of purchase is around $40.
The order numbers also seem weird. A normal order number would look like a 10-12 digit number like 9999999999999. But these are like 999999999999999.9999999999
I'm unable to understand where these are coming from. Does anyone have any experience with this?
This is only happening on the Apple app and not the Android app. They both use the same scripts for logging orders to the database. I'm totally baffled by this.
I can manually delete the orders and that will disable the user's upgrade, but that's not a long term solution.
Related
I have currently an app that through in-app purchases a user can unlock content on the app. What I have noticed is that some users "abuse" of this by logging with their Apple ID in multiple devices and I'm currently looking into possibilities on how to limit the use of the content to the device where the purchase was done. I understand that Apple doesn't allow that, so that means the payment system should go away from the app.
Therefore, introducing logging will help me to be able to identify the person that is using the app against a backend but still, I need to be able to limit on a device. As far as I know, the UUIDString of the CurrentDevice is not really a way anymore. What other options are?
I saw this library, which seems to promise unique identification:
https://github.com/fabiocaccamo/FCUUID
Another solution probably would be to create a licensing system, so one license can only be used at the time.
Thanks!
I will describe our experience with using same account on different devices (VOD):
User is able to use application on how many devices he want, but he able to watch content only on 5 uniq devices.
Each time user try to watch content, app check if device registered with some UUID, if not then try to register. UUID is uniq per installation, it mean that if user will watch content, then delete app, download again and watch, then he basically lose 1 device.
In same time user able to unregister device via web, but he had only like 25 unregistrations (I don't know what happened if user use them all).
We don't use in-app purchases and accounts are cross-platform (android, iOS, web, tvs, etc), so not sure if it helps you.
AFAIK, Apple does not have limit on how many devices you can user Apple Id. You can have 6 family members so number of devices could be lot more.
I feel it is bias how Apple's guideline talks about limiting music, movies, shows and books to 10 devices but does not say anything about Apps!
Apple - Family Sharing
If your family has purchase sharing turned on, music, movies, TV shows, and books can be downloaded on up to 10 devices per account, five of which can be computers.
I have not seen any application limiting IAP on devices. You could run into risk of Apple rejecting your app, potentially on every update you submit. I would reach out to App Store or if your company have Sales rep contact and get their suggestions/buy-in before spending lot of time and money.
Also, create issue/radar and give specifics about issue. More people request this feature, has better chances of it getting added.
One way you can achieve this is to keep track of receipt you get for IAP and check how many users/devices using that receipt. You would need to build entire flow to educate user about device limitations. Like updating App Store page, warning before purchasing, option to add/remove device and more...
If you are planning to implement device limitation, please beware of the rejection risk.
I am planning to make an app on iOS. The app will be free. This app will work without the internet. The app should not be able to query my database if the subscription is not paid.
However the app will still receive "notification" or RSS links even without subscription. The subscription will be monthly minimum.
I did some research but some people are saying it is not possible and some are saying this has been changed by apple and it is now possible.
Edit
I would like to add that the app will be as much secured as possible. I will have an SQLCypher database inside - so the key will be stored there too (hidden).
Here is the problem that someone told me: The user can use the app only if it paid the monthly/annual subscription, so the key has to be revocable. It seems not compatible with that because the app will have the database deciphered with the key. And if it is deciphered one day, then it will be deciphered next month too.
Why exactly people tell you is not possible?
The only problem I see from what you write is if the free version of your app doesn't do anything. As a general note Apple doesn't allow "demo" versions (even if that concept is not always clear or enforced consistently): a free app must do something not trivial (and of course lots more if the customers pay).
Why should you?
A simple example:
1. free app, only local app with, no community records, with ads and a low number of lives but with in app purchase option to buy more lives
2. a paid app, global app that you can see your records against every one else, no ads and double the amount of lives as the first app, but users asks also to be able to buy more lives if they finish what they get in the begging.
so, in conclusion, there are some cases when you need the flexibility of paid app that allow user to buy more things in the app even when they paid for the basic app.
Can it be done? I Couldn't find anything about it, only about freemium apps or free with in app purchases.
10x
Yes, paid apps can include in-app purchases, including one-time purchases and subscriptions.
I am now setting up IAP in my app and all is running fine in the sandbox environment.
The products in my app are consumable products. Users will post ads on my website once the purchase is successful. The ads on my website has a limited time (I.e. It will expire after 20 days).
If users purchase the products in my app and the ads are posted on my website, after some days, say 14 days (I've heard that users can request a full refund in the first 14 days without specifying any reasons), they request for a refund from Apple. Then this undoubtedly affects my apps revenue and Apple seems to provide no measures or policy to protect the developers.
How can this be prevented?
Due to a range of legal requirements in various countries, Apple are required to provide a "change of mind" refund on both App and In-App purchases. As an App vendor, you're agreeing to this in the various documents you "sign" to become so. That basically means you have to absorb any loss that may occur from this (such as you describe). Luckily this doesn't seem to currently be a major issue, and as long as your IAP pricing is reasonable, you shouldn't expect to encounter this on a regular basis. I suppose in some ways you can consider this the digital equivalent of shoplifting. It's something that will probably happen to a very small degree, but if your prices are good, and the environment is friendly, it's far less likely to happen.
Is there a way to offer a purchase free of charge for in-app purchases? I'd like to give a free download as a promotional item and not charge the normal price that is listed in iTunes.
You have to code for this in your app. In my app all purchases are registered on parse.com and sync'd between user's devices. I can add a purchase to the class on parse.com for a user and then they get the IAP for free when the data sync's to their device.
Apple don't have any mechanism for this like they do with app purchases unfortunately. The best way I've found is a custom URL scheme, so you can generated a code/string of your custom URL type ://myApp/123456promoCodeFooBar12999 etc, then your app, in response can connect to your server and check this code off against your database (confirming that it has not been used before, and can't be used again on a diff device) before unlocking the feature. This circumvents needing to get UUID's off people etc (which you can't do in code anymore to check against anyway), you just need an email address, send link, user clicks in it, your app opens and away you go :)
edit addition 28 Feb 2014..
an alternate approach might be to submit an separate paid version of the application in which all upgrades are unlocked because they are paid for upfront at purchase time. You may choose to keep this off the iTunes shelf but occasionally put it up, perhaps at a prohibitively high price, $1000 etc, because you can get the normal promo codes off Apple for this one to give to journalists etc, just explain what you are doing to them in your cover letter and I'm sure they'll be more than happy to play ball