I have 2 in-app-purchase in my iOS application which is developed using phone gap.
I am using inappPurchaseManager.js for implementing in-app-purchase.
https://github.com/usmart/InAppPurchaseManager-EXAMPLE
1st in app is non-consumable and second one is non-renewing in-app.
in case of restoring the in-app purchase,I used the following code.
window.plugins.inAppPurchaseManager.restoreCompletedTransactions();
window.plugins.inAppPurchaseManager.onRestored = function(originalTransactionIdentifier, productId, originalTransactionReceipt) {
console.log("originalTransactionIdentifier: " + originalTransactionIdentifier);
console.log("productId: " + productId);
console.log("originalTransactionReceipt : " + originalTransactionReceipt)
};
but though I have bought 1st and 2nd in-app, This function will only return 1st in-app product name.I don't know that whether I am understanding this code or process wrong.Please give me proper guidelines.I am using apple test account for testing this functionality.
This is the correct behavior, quote from apple docs:
If your app uses non-renewing subscriptions, your app is responsible for the restoration process.
Related
I got rejected from Apple today,
They say
We noticed that your in-app purchase product is set to an incorrect
product type.
(Paid Plan) is set to Non-Consumable.
Next Steps
Since the service offered by your app requires the user to make an
advance payment to access the content or receive the service, please
use the non-renewable subscription in-app purchase product type.
Non-renewable subscription content must be made available to all iOS
devices owned by a single user, as indicated in guideline 3.1.2 of the
App Store Review Guidelines
But in my app, I just have a package to get full access(remove Ads, add some features)
And the user just buy it once!
So that's why I use Non-Consumable.
why apple rejected it?
Performance - 2.3.1 & Business - 3.1.1
Your app contains hidden features that enable users to purchase content by means other than in-app purchase API.
For this reason, your app will be removed from sale on the App Store at this time.
Our app has been removed from App Store.After that we submitted a new version but it has been "waiting for review" for more than a month.What should we do to update our App?
enter image description here
From the rejection line it seems like your app is wrongly using any payment options rather using inApp purchase.
As per apple rules if you know we have to use inApp purchase option for non physical existence products. Like for ex : Earn coins, points etc.
So make sure you are using the payment options as per apple guidelines. If all things are checked & as per apple rules than try to submit it again by sending appeal to the apple review team.
So by that way you can give them more information about your product & get approval.
Hope it will helps.
My issue, i really need help with, is that i can't get the logic working which renders the 'Restore Purchase' button conditionally.
I have built my IOS app with an in-app purchase button that allows the user to pay once to unlock extra features - of type "Non-Consumable Product". The purchase feature works fine in TestFlight using my regular home user Apple IDs and some other Test Apple IDs (not sandbox testers). I don't have a Mac and so can't use a Sandbox environment. When the trial period is up i display the Purchase button, this invokes the CN1 Purchase API and PurchaseCallback, and i then use Storage to store the flag that its been purchased.
purchaseApp.addActionListener(e -> {
if (Purchase.getInAppPurchase().wasPurchased("full_product")) {
ToastBar.showMessage("You have already previously purchased this product.", FontImage.MATERIAL_INFO);
...
} else {
Purchase p = Purchase.getInAppPurchase();
p.purchase("full_product");
}
});
(I am not doing anything with receipts or receipt_stores.)
But to comply with Apple i need a 'Restore Purchase' button, so users don't pay again on new devices. The difficulty is getting the logic right, as i only want the Restore button to display IF they have paid for it before, else i just want the Purchase button displayed.
So i created the userHasPreviousPurchased() method below to test for the button to show, and added RestoreCallback interface to my main class as per CN1 documentation. But the method below never returns true on my IPhone using a TestFlight build, so my Restore button never shows. It is that p.getReceipts() always returns an empty List, when i expect 1 row with my SKU in it.
private boolean userHasPreviousPurchased() {
Purchase p = Purchase.getInAppPurchase();
if (p.isRestoreSupported()) {
p.synchronizeReceipts();
List<Receipt> receipts = p.getReceipts();
for (Receipt receipt : receipts) {
if (receipt.getSku().equalsIgnoreCase("full_product")) {
return true;
}
}
}
return false;
}
Please can you point me in the right direction. Using CN1 API's how do you test for a previous purchase using this type of IAP?
I tried creating a sandbox test user and, after signing out on my device, purchasing the IAP using the user (which was accepted). I have debug code in my app with tests the above method and that still didn't return a receipt (i fail to see how it could have as i wasn't signed in as the sandbox user).
Many thanks in advance
If you want to keep track of who has purchased your products already, you need to have a server-side component to store this. The Receipts API depends on this, and requires you to implement a ReceiptStore. Check out these blog posts that cover this in detail.
Introduction to In-App Purchase
Non-renewable Subscriptions - This introduces you to ReceiptStores and how they work.
Auto-renewing Subscriptions in iOS and Android - This includes full sample code for client and server for Android and iOS.
I am implementing In-App Purchase in my app and test around the existing apps to get some ideas. But I found a scenario which I am quite confused on it.
I have installed an iOS app and purchased the particular levels. Later I uninstall this app, sign out from existing iTunes store account and sign in again with another apple id, then reinstall that app again (same app). Here i can again i need to purchase the particular levels.But my doubt is In-App purchase method we can use based on the purchase Apple ID or Device token ?
If the user can purchased with Apple ID ,then the user can login with another device they no need to purchased again but one user can purchase app and user can login to another users Devices is the one problem..!why because another users no need to purchase.
And if we set the Device token, based on the in-app purchase user can only login that device only ,they can't login another devices with same Apple ID,here it is a problem.
I am quite confused on it... so is the purchased items tied on device if we use multiple apple ids on same device?
I understand that I can restore my purchased items on different devices using same apple id. But how about multiple apple id on multiple devices? If I have 2 apple id associated on an device, I use one of them purchased item, but later I use these 2 apple id login to another device, am I still need to pay again to download items I have purchased on previous device?
Please let me know if my questions are not clear... I hope someone can give some idea on sharing purchased items against different devices and apple ids.And which one use the in-app purchase.
Any suggestions and comments are welcome. Thanks a lot.
IAPs fall into two categories - consumable, and non-consumable.
Non-consumable purchases (purchase level 10-15 of a game, upgrade to pro, etc) are synced across devices by the system, and are restored by the system. They are tied to the Apple ID.
Consumable purchases (purchase 5 gold coins) are NOT synced or restored. Your application needs to remember that the purchase has been made, and store information about that so that a backup and restore correctly restores the user's state. If the user uninstalls and then reinstalls, they have lost any previous consumable purchases (but they will retain all non-consumable purchases, and your application can query for these). You can, of course, sync all information about consumable purchases to your own server, but you would then need to have the user create an account with you. This would allow you to sync consumables between devices.
The Device ID (which you can't get, anyway) has no relevance.
See https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html for more discussion.
If the IAPs are non-consumables (or autorenewables) they can be 'restored' by the user (i.e. the app would execute a restoreCompletedTransactions or refreshReceipt). I believe that the username/password log-in required to restoreCompletedTransactions (or refreshReceipt) must be the same username/password as the person who downloaded the app onto the device. Given that requirement, I still believe that a single 'purchaser' can share their single purchase of a non-consumable IAP on many devices.
I'm making an iPhone app that completes a PC application.
I sync my iphone application with webservice to the PC application, making it thus an extension.
I wanted to sell it for periods of time. (Example 1 month, 6 months, 1 year).
For such applications the Apple allows use in-app purshase auto-renewable?
If yes, can someone indicate me a good tuturial of how to implement this in-app?
I already implemented consomable and non-consumable in-app previously.
I've read this tutorial among others:
http://www.raywenderlich.com/21081/introduction-to-in-app-purchases-in-ios-6-tutorial
http://www.raywenderlich.com/23266/in-app-purchases-in-ios-6-tutorial-consumables-and-receipt-validation
But still could not find any on in-app auto-renewable.
A code example also serves
if this type of in-app which does not serve advise?
I'm not sure if it will answer, but auto-renewable in-app purchase are allowed only if your app provide new content each time (or often) the user pays. (like provide new magazine, video...)
If your purpose is to do a premium subscription which give access to so premium functions (so no logic of periodical new content), Apple will reject your app.
You will find much more explanations on the subject here: The limited world of auto-renewable subscriptions