I am testing in app purcahsement by phonegap IAP plugin. the plugin works well and
I've done for testing free-subscribe items. However, I need to test none-free items too.
from manage in app purchases section on itunesconnect, I only can add free-subscribe items only.
there is no buttons for $0.99 or $1.99 but only a button for free-subscribe.
Is it possible to add none-free items from sandbox mode? how developers can be sure
their none-free items works in sandbox mode? is there no way to test none-free item before
submitting an app? any help will be appreciated.
You can only add free subscription items from iTunes Connect because you haven't sign the legal agreements and contracts for In-App Purchases.
From that page:
If a type is missing, make sure you have agreed to all recent contracts. The Legal user must go to the "Contracts, Tax, and Banking" module on iTunes Connect to agree to the latest Paid Applications agreement. You must agree to the Developer Program License Agreement before you can access the Paid Applications agreement.
Your account must me the Agent.
Related
I've been looking for a way to add a monthly subscription with free trial to my product. I've noticed some apps, like Life360 (screenshot 1), do this through credit card billing rather than an iTunes account. I've searched all through the developer documentation and cannot find an API to allow a user to enter a credit card outside their iTunes account.
Is there an API for this?
You have to go through Apple for all credit card transactions if you want to be accepted in the App Store.
According to the App Store Review Guidelines, 11.2:
Apps utilizing a system other than the In-App Purchase API (IAP) to
purchase content, functionality, or services in an App will be
rejected
And 11.3:
Apps using IAP to purchase physical goods or goods and services used
outside of the App will be rejected
So, yes, so-and-so does it, but you aren't so-and-so, so you probably will be rejected for doing it.
Apple frowns on this, in general, for non-physical merchandise. Chances are good your app will be rejected (and Life 360 might have just slipped through - it happens!)
There's definitely not a credit card API built into iOS. You'd need to use a third-party for your payment processing. Stripe is a popular one, and has a page on iOS integration: https://stripe.com/docs/mobile/ios
There isn't a built in API for this. You need to use a third party like Stripe. However by having a subscription system that does not go through the appstore you will likely be rejected.
Most apps that use content (news, magazines) will need to use in app purchases. Apps that provide a service such as insurance etc can usually be added by working with someone from Apple in order to get it into the app store such as Uber.
We are three guys, who have made a free game for iPhone, which has been available on the App Store for almost a year.
The app is a board game, where you create a user or login using your Facebook credentials. You are able to log out of the game and log back in with another account.
Now we have updated the app with the ability to upgrade the user to a premium user. Allowing personal and global game statistics.
But Apple is giving us a headache in the approval process, and refuses to accept our In-App Purchase. First they would not approve it, as it had no restore button. Then when we told them, a restore button was not required, as it was a consumable purchase, they now demand we change it to a non-consumable and add the restore button.
Consider this scenario if purchase was non-consumable.
User logs in.
User upgrades account to premium
User logs out.
User logs in with a different account.
User restores the previous purchase.
This would allow you to upgrade two accounts to premium, but with just one purchase.
Apple's argument is, that our users need to be able to restore purchases, if a new device is setup, or a device is restored.
But that is not the way it works. Users upgrade their accounts to premium accounts. Now when they buy a new device or restores an existing device, they just log in with their existing game account, and the upgrade will be available, because we on the server-side has marked the account as a premium account.
So my question is basically. Were we totally wrong, when we choose to use a consumable instead of a non-consumable. And if so, how should a non-consumable be implemented in order to be (potentially) purchased more than once with different game accounts on the same device?
And secondly, if we are correct about the usage of a consumable in-app purchase, what should we say to convince Apple, that we are on the right path?
If your premium account is something that your users have to buy only once then Apple is definitely right to ask you to switch to non-consumable in-app.
The scenario you described is quite possible (i had to face it too) but if you add server-side verification of in-app receipts before unlocking the premium feature (saving all transactions associated to a user) you have the chance to verify that the purchase is new or restored checking the fields original_transaction_id and original_purchase_date in the receipt data. This way you can see if the user restoring the purchase is the same that originally bought it (maybe checking its facebook user id).
Anyway, experience showed me that the chance of this happening is not really high and i wouldn't recommend implementing this check (although server side validation is almost always a must ;-) )
According to the 'Restoring Transactions' section of the In-App Purchase Programming Guide:
If your application supports product types that must be restorable, you must include an interface that allows users to restore these purchases.
If your app contains non-consumable purchase, and if you don't include a restore button apple will not approve your app.
This has been made necessary by apple after June 2012.
So to answer your question: No, it seems that you must use restoreCompletedTransactions.
Hope it helps you.
I am getting invalid product identifiers back from the store, however I believe I have set up everthing correctly.
I think this might be due to the fact that I dont have a paid contract in effect.
I was allowed to set up the app's product, in iTunes connect, without the contract completed which suggests to me completing the paid contract might not be needed (I would rather not since this is a proof of concept app).
Does anyone know for sure if you can or can not test in the sandbox before this is set up?
It turns out you only need to request the contract and enter tax information. I.e. you dont need to enter banking info for the Sandbox.
From my experience it worked as followed:
Request the paid apps contract.
You can now set up the in-app-purchase on your apps. However, you will get 'invalid product identifier' back from StoreKit if you try to use it.
Enter tax information.
It now works.
You cannot setup a PAID app without signing the contracts.
So you cannot test the In-App purchase without signing the contract.
I want to make an app that lets a vendor sell gift cards through the app to the vendor's store. Does anyone know which PayPal SDK I would use?
I'm hoping for guidance based on experience here, which is easiest to work with and simplest.
Also does anyone know if there's a paypal alternative with an SDK?
Thanks!
Following on from my comment above, the rules are not clear and are therefore open to interpretation (and Apple's interpretation always supersedes anyone else's)
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
A gift card could be interpreted as a service, PayPal interpreted as a system other than IAP
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
Therefore you can't use IAP's to purchase your gift cards
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected
Here external mechanism could easily refer to alternate payment providers, so that rules out using PayPal.
As you mention giftcards, the following clause may also be relevant as a gift card could be interpreted as a credit or even a virtual currency
11.4 Apps that use IAP to purchase credits or other currencies must consume those credits within the application
We are planning a new application development for iPhone and Android devices. The application would be published in both markets (Android Market and Apple's App Store) and its download would be free.
Nevertheless, the application would have some items that can be purchased by the user. The easiest way would be to integrate each version with its corresponding billing system: Android In-App Billing and the Apple iTunes Billing System.
Is there a way for avoiding the 30% transaction fee from the billing systems? Can a developer use a custom in-app billing system for its application? Is there a disclaimer policy for Android or iPhone when using other in-app bill systems for avoiding their transaction fees? What are the options a developer has for providing an in-app item purchase within his application?
Many thanks!
We've developed several applications that transport users to a web page payment portal contained within the application.
Apple have seemed fine with this approach, in one particular application we had implemented both In-App purchasing and a custom payment portal - they asked us to remove In-App purchasing as the app was selling deal/vouchers and they classed this as virtual product.... they didn't reject anything about our custom payment portal.
Potentially they could pull all apps that do this at any point they feel like it, although I don't see this as a likely scenario.
Since both Android Market and Apple's App Store terms of service prohibit what you're asking for, the answer is a simple: no, there is no way to avoid the transaction fees (and still remain within the terms of service).
You're also asking about a disclaimer policy -- if you mean for your product, you should disclaim to your users that your app could get removed from its respective market at any time, without any notice (if you decide to implement billing that subverts the market).