Sorry I have some sort of question about iphone apps, this is my first time developing with IOS devices that's why I need some suggestions.
Is it allowed to create an apps for IOS devices that contains a transaction with credit card, such as booking reservation or on-line payment/banking?
Lets say that user should log-in first before doing any transaction, for Authentication between the device and web server, any secure way to do this? I mean when logging-in from the device, something like authentication for 1 time login. Any tips or best practice/approach to achieve this?
Well, there is that Square app where they give away the reader which plugs into the audio jack, so others have
2) SSL for encrypted xfer?
Related
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.
Is it somehow possible to use phone number of receiver to send app messages?
The idea is the user don't have to know anything about ips, etc. just a phone number. Then the app can find this user and send messages (app protocol).
Sorry complete newbie question, but was just wondering if there's a connection… I didn't find any information with search engine…
Yes, you could do this, but it would require both parties to have your app installed and you would likely need to create some sort of intermediate web-based service to store their account information (username, password, phone number, UDID, etc) then use that service to send the app messages from the sender to the receiver.
Assuming both of these users would be using an iPhone it will probably just be easier to wait until iMessage is released with iOS 5 in a month or two since it will work similar to FaceTime in that you can use phone numbers, emails, etc and works between all iOS devices running iOS 5.
I am developing a game application with majority of web content,but also have to provide support for iPhone. Here users have to first register on the server from the website,and based on their payment they are given membership type (gold,silver,etc) for the game. They can play the game on iPhone also,using registration ids to indicate user type.Each time on gameplay certain amount is deducted from their account. The iPhone version of game also keeps tab on amount remaining and prompts user to replenish on server.
Payment is entirely on server side and only data is passed through iphone application.
Does this in anyways violates Apples rules?? Can it cause App rejection??
I don't know 100% but it sounds like it might if not invalidate sail pretty close to what Apple sees as acceptable. Why don't you deal with all payments through a web-based site and simply allow registered users to access the game via iPhone. When a user runs out of time you could simply suspend the app and start up a web browser to access your site / renew game time.
Also (and I am not familiar with this) but in app purchases might be a good way to go?
all the best
Gary
I'm working on an app that will provide data from a web server to users but only if they've bought an in app purchase subscription. I understand the basics of IAPs but how do I securely make sure the data from the server is only accessible to the app, and only if the subscription has been purchased? I don't want to make the user set up an account, I just want to auth the app/purchase securely.
Thanks in advance :)
I'm going to use subscription model too with IAP.
AFAIK, you SHOULD NOT use a unique phone identifier like the IMEI of the phone to identify the user on your server. According to the Apple documentation, you MUST provide a way so that an user can restore his subscriptions on several devices!
Besides, a call to restoreCompletedTransactions of the SKPaymentQueue will restore ONLY nonconsumable products! Subscriptions are not supported by this method.
See these links :
http://developer.apple.com/library/ios/#technotes/tn2009/tn2259.html (section « Frequently Asked Questions », point 10)
iPhone - How to recognize the iTunes user of my app
The only way I know is to use a login/password to identify the user on the web server but this could be quite ugly...
However, if someone know another way, could he describe his solution ?
You should upload store receipts to your server, to be able to check them on Apple's site. And, with request you should upload phone identifier. And, of course, store somewhere in the database. After all, you will have information about which phone id has access to subscription.
And, when you will request subscription-related info from your server, you'll be able to check who has acces (via phone id) and who hasn't.
I am considering using In App Purchase for our iPhone app. But since we will offer a larger quantity of content items (>10 video items each day added), I would like to automate the new product registration in iTunes Connect.
Is this possible ?
If not: how long does it typically take before Apple approves a new registred product in iTunes Connect ? Since the content looses quickly it's 'freshness' (news broadcasts...), it is crucial to be able to have new content available ASAP.
Would you recommend using In App Purchase for this scenario or would you recommend developing our own payment & account system ?
As far as I know, it is not possible to automate it, unless you develop your own script (in AppleScript, for example, to operate safari and I am not sure if it will work as expected.
A new app will be reviewed and approved typically in 7 days. In-app purchases will go live when the app is approved.
In-app purchases can operate in two ways:
you include the content inside the app
you put the content on your severs and include the mechanisms to make the magic work. When the user buy the app, Apple server will communicate with yours and vice-versa, and a signal must be sent to Apple servers, during the process, so they will know the content was delivered. You will have to read the docs, as this is too complex to explain here.
I automated the input of a large number of in-app purchases using the Firefox extension iMacros. The free version is absolutely sufficient for this.
You have to create a CSV file containing all the data, then record the workflow in iTunes Connect and press start!