I want to purchase some token from my server , for this i am implementing paypal sdk.
But i want to know that apple will allow this paypal integration for token purchase or they will force me to use inAppPurchase?
Apple's guidelines are quite clear on that. It depends on what you are selling. There are even things for which they don't want you to use In-App Purchase. IAP is strictly for content, service or funktionality of your app or consumed within your app.
IAP ist not designed for anything else.
https://developer.apple.com/appstore/resources/approval/guidelines.html
Related
I am building an IOS app with an auto-renewable subscriptions enabled. What I am attempting to do is allow a user to purchase a subscription through an in app purchase that would allow them web access as well as mobile access. However I need a way to check that a subscription in the App Store is still valid.
The Problem is that if I wait for the mobile app to initiate a purchase receipt verification then there is a chance that user with a cancelled subscription will continue to have access to the application paid features.
The solution I am looking for is to be able to check the status of a paid subscription in the Apple AppStore from a web application. However I cannot find any documentation on how to accomplish this.
Please help.
I'm developing an iOS app where users can ask for advice to influential people on their subject. In order to interact with these people you have to pay the price they set. Once you pay you are able to engage with them on a private chat.
There is an app called Healthtap which does almost the same but with doctors.
I wanted to know if we might be able to use paypal and stripe payment systems instead of apple's.
For more info, I'm building it with HTML5 and making it native with Phonegap
Thanks!
You "have" to use apple's system when paying will add more content to the app, which seems to me, is what you are trying to do.
From Apple's In-App Purchase Programs:
You should read this if you are interested in offering additional
paid functionality to users from within your application.
You can use other payment methods when you are not adding new functionality to the app but rather buy something else in the real world. This is the reason why apps such as Amazon's kindle stopped selling ebooks through their apps, since they did not want to share their profits with apple.
No, Apple does not allow any third-party payment methods to be presented in the app itself; it's IAP or nothing.
What you CAN do is have the third-party payment system as part of your web site and have your users make payments through the web site. You will then need some authentication system in the app that uses to validate the user's payment.
Please tell me How to make payment with different amount via In app purchase in iphone sdk?? as i am creating an application in which subscription charges deduced from a website and in the same way i want to make payment using my application and subscription amount change all the time.. as apple don't approve paypal for the same purpose. How to handle this problem??
can we use web services for deduction of charges and get response of success or failure from web services?
For in-app purchases of app content, you're only allowed to use Apple's In-App Purchase system. You're not allowed to use paypal or anything else from in the app.
The only way to set the price of an in-app purchase item is in iTunes Connect. StoreKit (the API you use for in-app purchases) gets product prices from iTunes Connect, and there is no API for overriding the prices from within the app.
There's no public API (as far as I know) for changing the price in iTunes Connect, either. Perhaps you can script the normal web browsing interface, or find code someone else has written that scripts it. But the only way that Apple provides for changing the price of an in-app purchase is to log in to the iTunes Connect web site in a web browser.
I have a requirement in my new iPhone application, where I have to made payment like paisapay (Ebay) does. can I open a web page where user can fill information related to payment and server will handle payment? This Transaction will be in secure manner (In standard way). is it possible? Apple will approve app?
If you are using this means to unlock functionality in the app after payment, it will be rejected else it's okay.
As per app review guidelines
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
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
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
For more reference please read the latest App store review guidelines at https://developer.apple.com/app-store/review/guidelines/
maybe this might help you
http://www.zooz.com/
FYI: In accordance with Apple’s App Store Guidelines, ZooZ can be used without limitation for purchasing physical goods or goods and services used outside of the application.
I want to implement the payment gateway like functionality in my iphone application other than In-App Purchase feature provided by Apple.
So, i have one Question regarding the application approval on Appstore that, if i will redirect user to the UIwebview for payment related functionality, then apple will reject this application for not following the human interface guideline or it will allow this.
Other way i can do it by calling web-service for the transaction of money. So, again there is any chance of app rejection on AppStore.
Please share your thought on this
Absolutely no way you'll be allowed to do this. Check the news the past couple of days. Apple is demanding even giants like Amazon and Sony to go with the In-App purchasing.
Edit Actually, Apple did come out with a softer stance, saying that you'd have to offer both payment options if you did your own transactions. So there's that..