I'm building a small app where users can browse cheap accessories like lipstick, nail polish, etc. I have Login With Amazon (http://login.amazon.com/) implemented because I originally thought that I could allow users to buy the accessories directly from my app.
But I soon realized that Apple has actually restricted that functionality. The purchase ability is available on Android and for web developers, but unfortunately not yet for iOS.
Is there some hacky way that I can allow users to make a purchase from my app (or from a web view in my app)? I have a little bit of experience with Python so I'm guessing there might be a way to write a script that presses different buttons on the Amazon web page in a web view in my app. The user is already logged in with Amazon.
You can use Shopelia SDK which enables in-app purchase of physical goods using one click payment. It is available for Amazon but also for any kind of retailers.
It works using a combinaison of automation and monetics to inject the order and process the payment.
Right now (October 2013), the product is in beta stage and can be demonstrated on Shopelia website http://www.shopelia.com
Integration is available through SDK for Android and iOS.
Disclaimer : I'm co-founder of Shopelia. Please contact me if you are interested to integrate the technology in your app.
Related
I'm finding it difficult to get a concrete answer on this, either I'm finding the wrong info or not comprehending what I am finding.
Our app will be available on the Play Store and App Store, as well as being accessible via Web App. We planned on using our website for customers to sign up, subscribe, pay, etc. The app will be a free download on the mobile app stores, with the free features active, only requiring a subscription for the advanced features.
Would this scenario (using Stripe for subscriptions, without any use of Google IAB or Apple IAP) break any developer agreements as they stand?
You will be rejected from the app store if you do this. Guidelines:
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game
currencies, game levels, access to premium content, or unlocking a
full version), you must use in-app purchase. Apps may not include
buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP.
If you don't want to bother integrating IAP, you can just exclude the payment stuff on the mobile client and let people do it on the web. Then, you can use your own verification mechanism to give people that have subscribed the correct content once they log into your app.
Spotify does something similar as described on their website. As far as how much of that they reveal in the app itself, you'd have to download it and see as I am not sure offhand. Your app may be rejected if it directly instructs users to go subscribe on your site.
The relevant info for the Play store is here.
Developers offering products within another category of app downloaded
on Google Play must use Google Play In-app Billing as the method of
payment, except for the following cases: Payment is solely for
physical products.
Payment is for digital content that may be consumed
outside of the app itself (e.g. songs that can be played on other
music players).
According to this, you are not required to use In-app Billing on Android since your content will technically be available on iOS and web as well.
I'm developping a mobile app that is simply a presentation of a product (what it is for? how to use it? and other details). It's meant for the commercials to present the product in a more comfortable way than a simple pdf to a client.
I've read recently that the apple team doesn't allow to publish on the app store apps with only marketing content.
Do you think I would have problems when publishing the app? Do you have a clue how I can solve the problem ?
(1) Sure, it would probably be rejected
(2) Depending on your needs -- the solution is simple, make an "enterprise app" which is sort of a private app for your company.
You can find 1000s of QA on here about enterprise apps.
TyrAds is a mobile app marketing agency focused on delivering new, global users for our clients. Specializing in user acquisition and monetization, They provide a holistic approach to promoting your app through premium ad placements within alternative app stores. Furthermore, They are able to promote your apps on major advertising networks. TyrAds is here to help you reach the app users you need to grow your business to the next level.
I am developing an iOS App. In that I want to sell books to the User. In simple words, I want Payment Gateway Integration in my iOS App. My Research shows that we have option to use Apple Payment Gateway API but for every transaction they will charge 30% for them.
Is there any other way to implement this and Apple will approve ?
The Apple payment gateway/API is for in-app purchases (of virtual goods, apps, etc). For physical items/items which have value outside the app, you're free to use whatever payment gateway/API you wish, such as PayPal (cool new SDK for US-based payers), Square (not available in Asia), or any local online payment gateway that you have available depending on your region.
You can provide a web interface where you can implement payment gateway. and generate a token which user can use for purchase the book.
But still you need to provide In-App purchase (Apple provided) in case of e-book and in case of physical book i don't think you need in-App purchase you can use above way or any other way which you think better.
If you're looking for an SDK to accept physical payments within your app, then check out CardFlight (https://getcardflight.com). They provide the hardware and SDK so that you can accept a physical card swipe and handle the payment processing, all within your own app.
Full disclosure: I am currently working on this. We realized the opportunity for an open payment platform that processes credit card swipes within your own app when we realized there wasn't anything like this on the market.
In terms of payment/charging Apple payment gateway/API is for in-app purchases (of virtual goods etc.). For physical items which have value outside the app, I guess you're free to use whatever payment gateway/API you wish, such as PayPal (new SDK for US-based payers) who introduced a new mobile SDK that allows iOS app developers to integrate PayPal checkout and mobile credit card payment mechanisms directly into their apps.
This means that you are not looking at just having a PayPal button inside the app, where users are redirected to Safari on iPhone to complete their transactions, but with this new SDK users can pay without ever leaving the app or any local online payment gateway that you have available depending on respective region.
Apple says,
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.
For example my IOS app will be used to make consultations with a web service and will be given free to users by my customer, since the web service is ours and flexible, it can offer different and hunderds of types of consultations (e.g first-aid guide, TV troubleshooting, Internet Connection trouble shooting..etc) and this can all be updated in web service by user. But this does not mean that users can use the app to buy some new guides. It will be offered to the users for free with a specific description of "This app includes this 10 guides" but we are charging the customer for license of using out web service and iPhone is one of the many ways we are offering client to access the web service and get that knowledge.
Is this possible? and what are the Apple restrictions?
Can I sell this app to CompanyX which offers 10 different troubleshooting guides?
Then sell CompnayQ another build with supports 50 different guides?
Apple have made it clear in their terms for the App Store that you must not offer anything for sale - neither products nor services - from inside an app unless it uses their purchasing APIs. This is why e. g. Amazon had to remove the buy-a-book feature from their Kindle app for iOS. You must not even have a link to a website in your app that would take the user to your website for purchase in Safari. AFAIK even a text hint on some screen inside your app telling people to go to your website for purchase of further services might be problematic in the review process.
In my opinion (which is just that, an opinion) you will probably be good with different apps for CustomerX and CustomerY, each offering free access to a specific subset of your web services. You will even be good if existing users of any of the apps can buy access to additional services on your website and then use them in their respective apps, as long as you do not link to that page from your app. You will, of course, still have to implement some kind of user-id system to recognize which users have access to the additional services, and which don't.
I suggest you take a look at how Amazon does it, because their Kindle app has certainly had a lot of scrutiny from the reviewers. Follow their lead and you should be good.
If you sell guides in the app you probably have to use in app purchases, where apple will remain 30% of the money. otherwise your app will probably get rejected.
if you have an developer account you can check the app store review guidelines.. point 11.2:
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
I've heard there are some precautions to take to develop a market in an application.
I'm developing an application for a football club. I would like to integrate a kind of market to sell stadium seats.
Someone told me Apple will refuse the application if I integrate it directly inside the app (using Obj-C, communicating with PHP pages).
According to him, I should redirect the user to an external web page (using Safari app for example) to realize the transaction.
Apple does not really communicate about that kind of information.
Do you know anything about it?
You can't use In App Purchase to buy "real life things" such as stadium seats : http://developer.apple.com/news/ios/pdf/in_app_purchase.pdf
The only solution is to use an external payment solution.
The Movies Now app implements such a thing : http://moviesnowapp.com/
Yes, you can use only in-app purchases to sell anything in your app, otherwise Apple will reject your app.
I'm not so sure if Apple will reject your app on these grounds. How can they know what your php pages are doing if you put them in a WebView? Also, think about services like Sky or Spotify that require a subscription. Apple do not take a cut on this, so you could set up a similar thing whereby your users have an account online that they can purchase tickets from and the iPhone is simply a thin client for your online services...
Yes you have to use InApp purchase only to apply unlock functionality,and to use In App purchase there are certain scenarios which can be implemented.
You can find in detail about In App functionality on
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/AddingaStoretoYourApplication/AddingaStoretoYourApplication.html
Secondly if you want to implement In App purchase,there is a very good tutorial which i found very helpful and was easily able to integrate inApp in my application and it was also later on approved by apple.
http://troybrant.net/blog/2010/01/in-app-purchases-a-full-walkthrough/
Cheers
You cannot use Apple in app purchase to purchase non digital goods, if you have an existing payment provider or user account you could use that, take a look at the eBay app which has Paypal integration