In order to be able to better estimate the revenue income of our app, we implemented a Database function that reliably (we tested it in Sandbox mode) increases a subscription counter for the subscription that was made by one once a subscription has been made.
This function is only triggered once an in-app purchase has been successful (i.e. when we receive the feedback from StoreKit to enable the Premium functions). Now, we have found enormous discrepancies between the data we observed and the data App Store Connect gives us.
For the past two days, upon confirmation of purchase via StoreKit, our app has 13 times enabled premium functions on a monthly subscription basis, and 14 times on a yearly subscription basis.
However, App Store Connect tells us we had one yearly subscription and 5 monthlies.
Furthermore, for the one premium subscription that generated sales of $5.60, Apple has added proceeds of $3.73 - but that's more than 30% commission. That's almost 35%.
The sales that Apple has not accounted for amount to more than $70.
Can anybody explain to me what's going on, why Apple is not showing us subscriptions that definitely happened and takes more commission than agreed?
My bet is that you are not aggregating the prices correctly on your database side. It is extremely complicated thing to do, despite superficially seeming simple.
The second guess is that ItunesConnect revenue is delayed by day or three (they were experiencing delays).
If you want to see know the revenue calculation is done correctly, I recommend hooking yourself to RevenueCat (quite simple process), and to double check numbers.
Regarding the price, don’t forget their is also sales tax/VAT that is deducted too. Eg. Any sales made in the UK will have 20% vat removed, then Apple takes 30% and you get the rest.
Related
I want to offer a free trial and the option to BUY (Non-Consumable In-App Purchase) on my ios app. I can see that I can offer a trial and then SUBSCRIBE (Auto-Renewable Subscription), but I personally don't like having to pay over and over for a simple app, but I do want to try it first. Is there a way to achieve the same thing when setting the option to buy? I realize I could track the first usage after download, but this presents a couple of issues:
Will Apple now approve apps for a trial period - previously they have been rejected, but that was before IAP and subscribe was available at all!
How do I prevent the user deleting the app (and any data I might store to know they have activated a trial) and then downloading again?
Or do I have to succumb to the pernicious "subscribe" model or release a "light" version with an upgrade? The last time I went "light", Apple insisted I make so much functionality available, I may well have not bothered with the full version - but that was a while ago.
Apple now allows you to add a free trial for Non-Subscription apps. It's a 0 price plan for fixed days. After this trial expires, you can show the non-subscription plan for purchase. The downside is user need to do a purchase again after trials end. But offering a free trial is a good user experience.
Non-subscription apps may offer a free time-based trial period before
presenting a full unlock option by setting up a Non-Consumable IAP
item at Price Tier 0 that follows the naming convention: "14-day
Trial." Prior to the start of the trial, your app must clearly
identify its duration, the content or services that will no longer be
accessible when the trial ends, and any downstream charges the user
would need to pay for full functionality.
Dont prevent the user from deleting the app. Just store the data online when user hits the trial button, you can store a flag in the web services which can be zero or one based on the user.
One way you could do this if you only care about iOS 11 is using the new DeviceCheck API. It's pretty limited in functionality (it lets you track 2 bits, or 4 cases, total) but should persist between install.
I have an application that has a requirement for a user to be able to purchase an e-card. This is a digital image. The user is then permitted to share this e-card as many times as they wish within a 48 hour period (So, the card is visible in a 'My Cards' menu) It then disappears.
I'm looking through the apple documentation for IAP, and cant figure out if this should be a consumable, or a non-renewing subscription. I currently handle all the persistence and expiry myself within the app.
The problem with the latter is that it seems every card would need its own ProductID (Rather than me just having a product for 'A Card' and the app being aware of which one it is. There's over 200 cards so this doesn't seem feasible, but the methods one must implement don't seem to work like this. For example, a user may have 10 cards, all purchased at different times.
Does anyone know the correct type of purchase this should be, and the best way to implement it?
This answer Floored by new rejection on non renewable subscription type in app purchases in iphone? , rather old (2012), claims that subscriptions must last for at least 7 days. Apart from that, iTunes Connect has no problem with 200 different products.
A non-renewing subscription might work but the 7 day issue is a problem for you. A non-renewing subscription can be purchased many times so there is no problem with duplicate cards - as long as you keep track of that.
A consumable would work except a consumable can't 'expire in time' it can only 'expire when used'. So if I purchase a card as a consumable I must be allowed to keep it on my device for a long time until I want to use it. You could let the user do that - they keep the card but can't use it. When they want to use it then it gets consumed and for the next 48 hours they can use it as often as they want. You may need to explain to App Review that this is a consumable that does not expire but that can be used for a continuous 48 hour period once it finally gets consumed.
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.
I'm about to take my first foray into In-App purchases, and I'm not quite sure how to handle my situation. At top is my situation, with some actual questions in bold at the bottom. Any advice would be appreciated.
I'm designing an app that will have a LOT of in-app purchase content. Every day, around 20 or 30 new items will be generated for sale. 3 or 4 days worth of items will be for sale at any given time, and after that they go away.
So we're talking a lot of items. Way too many to add to submit to Apple for a unique ProductID each day.
Of all these hundred items, there are actually only 4 or 5 different types of item. So I'm thinking I'll need to make 1 SKProduct for each type. Under the hood (and invisible to the user) the will actually be buying a credit good for 1 item of type X. After the transaction goes through, I send the receipt AND the requested item to our server. Our server stores that and sends the file back. If they want a 2nd file, they need to buy a 2nd credit and repeat the process. Of course to the user it will be presented like they're buying Item 1, Item 2, and Item 3 directly.
To make this even more complicated, we also want to offer a 3 month subscription (at a significantly higher tier) for those who don't want to buy their items ala carte.
1. Does this sound like a good approach?
Will Apple be okay with this? If not, what possible alternatives do I have?
2. Optimally we'd like to allow people to re-download items they've already paid for.
Would a good approach be to make each credit non-consumable, and since I've already stored the receipt info on the server I can match it to whatever item they should get? If this is too complicated or against Apple's rules, we may just make the item consumable since the item is only good for a few days anyway...
3. Is there anything else I'm overlooking here?
Thanks for any insight you guys can provide.
Take a look about what the iOS Development Program License Agreement says about treating In App Purchases like credits:
2.1 You may not use the In App Purchase API to enable an end-user to set up a pre-paid account to be used for subsequent purchases of
content, functionality, or services, or otherwise create balances or
credits that end-users can redeem or use to make purchases at a later
time.
2.2 You may not enable end-users to purchase Currency of any kind through the In App
Purchase API, including but not limited to any Currency for exchange,
gifting, redemption, transfer, trading or use in purchasing or
obtaining anything within or outside of Your Application. “Currency”
means any form of currency, points, credits, resources, content or
other items or units recognized by a group of individuals or entities
as representing a particular value and that can be transferred or
circulated as a medium of exchange.
Correct me if I'm wrong, but if your approach does not unlock/add functionality or change the behavior of the app by buying an In App Purchase, my guess is that this could be problematic when trying to get Apple's approval.
Hope this helps,
From the StoreKit guide:
If the user attempts to purchase a nonconsumable product or a renewable subscription they have already purchased, your application receives a regular transaction for that item, not a restore transaction. However, the user is not charged again for that product. Your application should treat these transactions identically to those of the original transaction.
This presents a huge problem in an app I am working on. We have licensed a large body of content from a publisher for sale through in-app purchase. They require that every time we sell a piece of this content (i.e. user pays us), our server calls an API on their servers to report the transaction. This is for accounting purposes and ultimately used to determine how much we pay them at the end of the month, per our agreement with them.
I have read several suggestions on SO and elsewhere about calling restoreCompletedTransactions rather frequently and maintaining a local understanding, on the device, of what the user has already purchased so they cannot be allowed to purchase it again. This to me seems like something that should be able to be implemented on the server side. However, the receipts that we are getting back from the Apple servers are exactly the same for a buy and a re-buy, as promised by the StoreKit guide.
If payment callbacks from StoreKit cannot be trusted as a valid accounting mechanism in this kind of situation ("you got paid" vs. "you didn't get paid"), what other real-time insights into transaction traffic are available? I don't think the publisher we are working with is going to be happy if we tell them we have to wait 45 days after the end of the month to get the REAL paid dollar amount out of iTunes Connect.
I have recently looked into the same problem. In my case, I wanted to implement accurate revenue tracking using Mobile App Tracking to track revenue generated from different customer acquisition campaigns.
Fortunately enough, there is a way to do it. It should be noted that SKPaymentTransactionStatePurchased vs. SKPaymentTransactionStateRestored solely depends on the initating action, e.g. whether you initiated a restore or a (re-)purchase, so that doesn't work.
What does work instead is checking for SKPaymentTransaction.originalTransaction which will be != nil for restores and re-purchases. The latter is unfortunately undefined behavior (docs). I'd consider a null check fair enough though.
Another option is to validate the transaction-receipt of transactions with SKPaymentTransactionStatePurchased and check that the original_transaction_id property in the returned, validated receipt matches the transaction_id.
The bad news is: In the current iOS version (4.3.x) there's no way to distinguish between a buy and a re-buy of non-consumable products.
To ease the situation I would recommend two things:
First
After a successful purchase, store the product identifier of the purchased product in the NSUserDefaults on the device. You can then hide the already purchased products from the user and thus handle a re-buy situation.
The NSUserDefaults are backed up by iTunes when the user synchronizes his device. So your stored purchase information is not lost when the user gets a new device.
Second
Store the receipt data together with the device ID on your server. Analyze the receipt's product identifier and the device ID.
If you receive another receipt with the same product identifier and device ID combination, then assume a re-buy. At least this would allow you to cover most of the re-buy cases.
Assuming that an ordinary iPhone user switches his device every 1-2 years, you will at least cover most of the re-buy cases and maybe apple will fix this in the future.
I have one solution,
Configure the product as consumable.
this will solve the problem - (They require that every time we sell a piece of this content (i.e. user pays us)).
Next you need to implement a logic in product buy option. It is in a way that once the user purchase a product the buy option need to remove otherwise the user may happendly go purchase and lost is cash once again for same product in same device.
you can use NSUserdefaults for this purpose.
thanks,