From My Previous question
sending request to apple - from iphone custom application
Here, I have added more specified my question.
Suppose my application has implemented followings.
Lets take an simple example
I have developed an application, for mobile dealer.
User can see ten mobile items on screen.
Now, user selects two items.(mobiles)
Now, User chooses check out option.
in check out option, he will provide his apple account - id & password.
Above I have explained the process that should be implemented in my application.
Up to 4 stpes I can do programming.
But I have no idea about the last step.
Can user make payment through apple
id - from iPhone?
What kind of steps do I/programmer
have to follow?
What kind of accounts do
I/programmer are required? (If
any..)
What kind of certificates do
I/programmer are required? (If
any..)
Let's take an another example.
Suppose, Application if something like this,
User can pay for bike (new order) through iPhone - apple id - password ?
Edit :
After a round - round question ...
Let's understand it in single line
Does apple allow to use apple-ID for payment of items other than apple-store? Why ?
You cannot sell your products through the Apple Store. If you want to have an iPhone app that interfaces with your store you can do that, but you will have to provide your own store service.
To answer the edit to your question, Apple does not allow using an Apple ID to purchase products from other stores. Instead you should use something like Paypal or Google Checkout.
StoreKit allows you to sell digital content, such as books, music, ect. and get it delivered right into the application. Payment happens via the iTunes account.
However, you cannot sell physical goods with this mechanism. You may want to consider other payment methods as mentioned by Amuck.
Answering the edited short-question:
Does apple allow to use apple-ID for
payment of items other than
apple-store? Why ?
No, because they do not pose as a payment provider to third parties and I am pretty sure they never will.
Related
I have been stuck in a strange situation, according to my requirement, I need to track the resellers of my app, i.e. I will be publishing link of my app in the iTunes-Store on 3 or more different sites(The re seller's sites).
According to my promise which I made to these resellers, I will provide a share of my profit.
So here I have to track from which link did the user came to the APP-Store.
Any suggestions or solutions will be Thankful.
I think the only way to do it will be server-side. Links at your resellers should point to your server, where you log the source of link (resellers web page) and redirect request to AppStore. But you'll have no way of knowing, which of this requests ended up with a purchase.
The only way to do this for real is to get them to become iTunes affiliates and provide reports back to you. They should use the iTunes referral to make the sale (they will get a small cut from Apple) -- Apple will report that back to them, and then they can prove to you that they made a sale, and then you pay based on that.
Reserve the right to audit them -- meaning that they will have to show you the report directly from the iTunes affiliate site.
I assume that iTunes actually tells them what they sold, but you would need to check that.
Another idea (which may or may not make sense based on what your app does) is to make personalized versions of your app for each reseller. If there's some way to incorporate a very simple feature that is personalized (and makes sense), then you can upload the same app multiple times and assume all sales are coming from that reseller.
So, for example, if the app were an exercise tracker, and the resellers were gyms -- you could customize the app for each gym and add their schedule and contact info to it. Then, sell the app as an Excerise Tracker for XYZ Gym and let them promote it and get a cut of sales.
I am working on a application which has a more peculiar requirement. Basically it is something which is not targeted at end users but at a system integrator who will embed an iPad into a larger system and sell it to an end user as a whole.
However, the problem I'm facing is that the system integrators could simply purchase the app once and then keep cloning thousands of iPads from a single iTunes account, my company would not get any revenue from this.
Is there any way around this. I've looked at in app purchases but according to the guidelines I'm supposed to give in app purchase restore functionality so I guess if I don't the app won't get approved.
I could use external authentication servers I guess, but that may be viewed as circumventing the app store.
I've loked at the volume B2B stuff but I'm not quite clear on how that works or if it would help me in this case.
Any ideas?
Thanks
Last time I checked an application can only be installed on five devices, and then the other ones simply refuse to install the application.
If this system integrator managed to circumvent this, it's he who is breaking the App Store rules.
You can't use the App Store mechanisms as you described (you can't change iTunes). In-App purchases of non-consumable items must include a restore option so the user can restore it on all his devices even if it's thousands (this also for subscriptions etc). If you won't enable that you would be rejected.
You can think you can send the Device-ID for each device that purchase the item and have control over that(or any information) but apple would simply reject your app because it's forbidden to send device-ID.
If your service is online you can simply use some kind of tokens created on your servers which would be given to each client (from some kind of private key), This way you must be connected to each purchased item (only those would contact your servers and you would grant access).
Security wise you must consider leaving some of the functionality on your server side. This is not illegal same as you can't access Facebook without username& password.
And now for the easy way, Define your service as consumable item for in-App purchase(if you can). What does it mean? Lets say you are selling a special feature like "Ad-Free" you can sell credits that would be consumed with each app open or any other process you have in mind, You can even set this credit to 1 million for 0.99$ (so the user never gets to that) but still the consumer would have to buy it again and again for each device and it would be absolutely legal by Apple. Pay attention that the problem would be on the consumer side such as that if user have deleted his app you should find a way to help him or refund him on next buy. Also, If you can and would use this method pay attention to save those credits on the restored folder on the device, so if the user would upgrade or restore the device he would still have the credits he bought.
Pay attention that if you are going to use in-App there are lots of methods to steal this content on jailbroken devices and you must use your own server to check the buying process (according to Apple).
Another important thing is that the app without the in-App purchase must have some value to the user.
From this page (http://developer.apple.com/programs/ios/distribute.html) I've read this
Custom B2B Apps
You can also offer custom B2B apps directly to your business customers
who have a Volume Purchase Program account. A custom B2B app provides
a unique, tailored solution to address a specific business need or
requirement.
Does anyone have any more details about this? i have an app idea that is specific for a individual company, say I am building an app for Company ABC, this app is solely for company ABC & no one else, how do I distribute such an an app (to Company ABC) & can I charge a monthly subscription for this app?
Thanks
kb
B2B Apps need to go through Apples review just like normal apps do, but they will appear in some sort of a private store to which you may grant your client access. It is my understanding that, aside from that, normal rules apply.
That means you might be able to offer In App Purchases and lock most of the app down, unless the user purchases a subscription.
I do not know however if subscriptions can be purchased via the Volume Purchase Program.
As a rule of thumb, before entering "uncharted waters" by just developing your idea, you should just contact Apple about what you like to do. Ultimately it is their decision what they will approve, so I wouldn't rely on the opinion of someone on the internet before putting too much effort into it.
You should also be aware that the Volume Purchase Program is available in the United States only.
Have you seen this:
http://www.apple.com/business/vpp/
"Custom B2B Apps for Business
In addition to offering volume purchasing of apps in the App Store, the Volume Purchase Program provides your business with an easy way to procure custom B2B apps built by third-party developers. Custom B2B apps are built to address a unique business need, and therefore are not available to the general public for purchase. "
Yes you can create an app for Company ABC only, and restrict only them as purchasers. I don't think you can make it a subscription though. Oh, and it's US businesses only.
https://developer.apple.com/programs/volume/b2b/
Look at bottom of page for other countries you can distribute to.
I have an app which costs $5. I'd like to change this so that the app is free and that users must purchase an auto-renewing subscription to use it. I know how to implement the auto-renewing subscription, but the problem is dealing with users who have already bought the app for $5; I'd like to continue letting these users use my app without a subscription.
The rub is that for privacy reasons I can't store any identifying information on my server which link an account for my app to a specific person (not even UIDID). What I can do is maintain a separate database table which links UIDIDs to subscription purchase receipts which will allow me to know if a user has a subscription.
So my question is, how can I identify users who got my app when it cost $5? I know there's a way to restore in-app purchase receipts, but is there a way to to retrieve a receipt for the initial purchase of the $5 app which I could store on my server?
The poor man's solution is just to mark all current UIDIDs (i.e. the UIDIDs of people who have paid $5) in my server as paid, but then they would have to buy a subscription if they ever wanted to use my app from a different device.
The previously selected answer is outdated. The new answer is that it is possible today with the new receipts that were standardized this year (2013).
The receipt now has two additional fields: original_application_version and original_purchase_date which can be used to detect when a user purchased and therefore be used to guide logic around what users should get what features.
You can see more about 10 minutes in here: http://devstreaming.apple.com/videos/wwdc/2013/308xex4x6ybggtlw4ztv0sg5btp/308/308-SD.mov?dl=1
or if that link dies here: https://developer.apple.com/wwdc/videos/ and search for Using Receipts to Protect Your Digital Sales.
Chaning your business model like this is not very well supported by the App Store.
Your "poor mans" solution is probably one of the best of a poor set of options.
Another one would be to switch to a new app entirely (just a different bundle ID in practice). Anyone using your old app would have paid, regardless of which device they use. Anyone using the "new" app would need a subscription. Obviously you'd lose any reviews and possibly external links that you currently have.
i'm working on an magazine app for iPad and i've been asked to build a system to allow users to subscribe for, say, a year. I have to say... I didn't quite get the concept of Subscription... Anyway, there's my point: should I implement a real Subscrition model of payment or can I go with a standard consumable one? I mean, if for 20euros I allow the app to download a secret code, say a boolean, which enable the download of all future issues of the year, why should I prefer the subscription model?
thanks to all,
Marcello
There's no need to "build a system to allow users to subscribe" since there is already a subscription billing service offered by Apple:
Apple Launches Subscriptions on the App Store
CUPERTINO, California—February 15, 2011—Apple® today announced a new subscription service available to all publishers of content-based apps on the App Store℠, including magazines, newspapers, video, music, etc. This is the same innovative digital subscription billing service that Apple recently launched with News Corp.’s “The Daily” app.
Security is the main reason you want to use the Subscription service. There are places out there where poorly made apps which have 'secret code' which just needs to be enabled have been pre-packaged which allows people to bypass buying.
Not doing things the right way and coming up with a half-arsed workaround because "you don't quite get it" is hardly a good attitude.
Doing things the right way means that the customer gets billed until they take action to cancel their subscription. It should be obvious why that is preferable to a one-time fee that expires.
Also, Apple may have a problem with you bypassing the method they've provided. There's an entire section on in-app purchases/subscriptions in the review guidelines that you are coming dangerously close to breaking.
The MAIN difference is Apple is responsible to auto-renew subscription every time it expired. So you should go for In-app purchase subscription type.