Our team is developing a payment infrastructure that provides for payment via smartphone with NFC technology.
For Android no problem as we used HCE; while as far as iOS is concerned we have come to the conclusion that the best solution, given the strong limits on NFC technology imposed by Apple, is the use of NFC-enabled Passes.
We have collected several information unfortunately very fragmented as on the net and on the Apple documentation itself not there is a lot of space on the deepening of this type of Pass. I know the implementation is under NDA, but we need to understand which way follow in order to at least start the tests.
With regard to the above, I list the points that are vital for the continuation of the work:
We have already requested the NFC certificate through the
appropriate form but we have not received any response yet. There is
a way, a particular form that the request must have or a sum to be
paid so that the request for the certificate can be processed
faster?
When the certificate is obtained, how should it be used? As already
mentioned, the implementation is protected by NDA, in fact I was
interested understand who I should talk to or how to get Apple's
documentation.
I thank in advance to those who know how to answer these doubts.
You are right, the entire process is under NDA.
I applied, like yourself and also reached out to a Developer Evangilist in Apple. I was told that the process was outside of their control and that you just had to be patient.
When you get the certificate from Apple, it will include an entitlement that enables the NFC support. I believe you just use the cert as normal when creating the pkpass bundle.
As I understand it, Apple will provide all the instructions to you if they approve your NFC request.
You can embed information within the pass that is sent via the NFC tag.
I’m afraid I can’t be more helpful.
I have an app that involves messaging (and it's a big part of the app). People can text each other through the app, and every message is kept on our server, uncrypted. (We never really thought of encrypting it)
The user has to accept terms when he creates his account and it's all written there, but my question is the following :
Knowing the user supposedly read the terms, is it still legal/allowed by apple to keep all the messages on our servers? We can identify who wrote it and what is written, obviously, but the users can only read his own messaging feed. Is that ok? Or should we run a encrypt algorithm when uploading the message and decrypt it on the reciever side? Or any other relevant idea/solution?
The T&C your working with Apple are documented in iTunes Connect > Contract, Tax, Bank > iOS Paid Applications and iOS Free Applications
TINLA: They don't say anything about how to store the data of your customers (by my brief understanding)
When distributing your App thru App Store as you say have you own Privacy Policy provided. If not then the standard EULA applies. the standard also does not say anything about privacy / encryption.
I would like to capture the NFC payment details in an app and was hoping this would be available if the NFC payment was launched from my app. I just need to know the amount paid, and merchant.
Going through Apple's docs, all I can see is software implementations of the Apple Pay with Touch ID, I can't see any references to integrate the Apple Pay NFC.
This is not possible as Apple's implementation is meant to conceal this data. That's the reason you can't find anything in their docs about it. Apple Pay via NFC is initiated by the contactless payment terminal and not "launched from [your] app". The data like the tokenized Primary Account Number (PAN), Cardholder Name, Expiration date, etc is sent from the Apple device to the payment terminal and up to the cloud via the merchant's infrastructure. Check page 19 of the EMV Overview Guide to get an idea. The Apple device unlocks the data from the Secure Element (after TouchID access granted) and shuttles it over NFC and most likely won't ever expose these details to the App layer. The approach runs inline with their statement "Keep your purchases private." If the transaction is approved the payment terminal will send a Transaction Certificate (TC) over the NFC link to alert the Apple device the payment was successful. No amount paid or merchant name is sent over with the TC according to the spec. It might also be worth reading this post to better understand how the Apple devices only act as contactless cards and not readers.
The best way to get involved with the customer transaction is offering an InApp payment experience at the store. Whether it be through iBeacons or geolocation, launching the retail app in context can allow customers to purchase through Apple Pay InApp rather than NFC. This provides you more opportunity to get the merchant and transaction amount since your app is in control vs the NFC stack. It's tricky to cover the checkout workflow but doable.
I hope this info is useful and guides you to some other options to get what you need done.
I have a question about in app purchases. My company charges customers for access to our software system. They are charged to use the system (subscription fee) and then can opt to use higher quality data (satellite imagery). We have multiple imagery sources but one that provides better imagery (5 meter resolution vs 30 meter resolution) charges for it (the lesser quality imagery is government provided and free) and we pass that cost to the user in the form of credits. We require the user to per-purchase credits to "activate" a boundary (provided imagery is available at that location).
Apple allows us to "activate" and charge against a customer's credits (at least hasn't rejected the app based on this yet).
My question is if we can use our own purchasing system to add credits in the app? It does not unlock features in the app. Anything you can do with the higher quality data, you can do with the other free data.
In the App Store Review Guidelines (https://developer.apple.com/appstore/resources/approval/guidelines.html#purchasing-currencies), section 11.3 states:
Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
Does this mean we are allowed to use our own purchasing system to process payments for goods and services used outside the app? These same credits can be spent through other software we provide as well as third part software (we offer third party support through our APIs).
I need to preface this with several caveats
Carefully read all of your Apple contracts
Nothing is guaranteed - Apple's reviewers can be touchy in this area and Apple has been known to change the rules in this area
Until you build and submit it, I doubt anyone can give an authoritative answer - all of this is opinion.
I believe Apple will allow this but will not allow you to, in any way, encourage users to use (including links or text references to) the alternative method of payment from within the App. The rule is they want a 30% cut of any revenue the application generates. Only if the revenue is generated elsewhere can they be cut out. Amazon Kindle app has fought this battle. Also note that once they get the idea that this revenue is somehow "theirs" then it will be difficult to convince them otherwise. Be very careful on that first submission.
for a client, I have been developing an app which has been tailored to make their employees every day lives easier. Think of it as a calendar designed to fit the needs of their special business.
Now it turns out that other companies in the business are interested in the very same solution too. My client suggested we could sell the app on the appstore.
Since the app is equally useful for companies with hundreds of employees as it is for a team of five, I wonder what would be the best way to sell it.
It is my understanding that a company, once they purchased one copy of the app, may install it on as many devices as they want, as long as they use the devices with the same iTunes account. This is especially true if the company would equip their employees with new devices for the purpose, like my client did. Right?
This is obviously not what I want, I'd rather like to charge a small price per device. Usually, this would cry for a volume license, which is not part of the appstore concept, except for educational institutions.
Now I am looking for a convenient way to achieve something with the same effect.
I was thinking about checking the UDID of the device against a whitelist on my server to allow each purchased license to run on just one device, while allowing migration of course.
To enable a company to purchase a "volume license", I would offer packs of additional licenses via In-App-Purchases, as well as individual licenses. The app itself would be free while featuring only demo capabilities, full functionality would be available after assigning the device to one of the purchased licenses. Means to manage licenses would be included within the app.
What do you guys think? Any technical reasons why this concept could fail?
Do you know of examples that actually implement something similar?
Any other ideas how to sell apps in volume? Maybe there are even some examples on how to implement something like this?
Do you think apple would approve this kind of use of in-app-purchases? (I know this last question is not of a kind that can be answered here without uncertainty, but let me hear what your gut feeling tells you..)
This question has been flagged as being off-topic twice, so I think I should back up the fact that I am mainly interested in a technical solution (and emphasized the important sub-questions accordingly). Of course I am interested in whether apple allows the proposed use of their appstore, however before I contemplate that further I need to know if there are technical caveats to my approach. I would love to offer code snippets to support the technical nature of my inquiry, however I'm just planning things so there is no code yet...
While the core question is still business-related here, and thus off topic, I'll bite.
The standard App Store end user license agreement has this wording:
a. Scope of License: This license
granted to You for the Licensed
Application by Application Provider is
limited to a non-transferable license
to use the Licensed Application on any
iPhone or iPod touch that You own or
control and as permitted by the Usage
Rules set forth in Section 9.b. of the
App Store Terms and Conditions (the
“Usage Rules”). This license does not
allow You to use the Licensed
Application on any iPod touch or
iPhone that You do not own or control,
and You may not distribute or make the
Licensed Application available over a
network where it could be used by
multiple devices at the same time. You
may not rent, lease, lend, sell,
redistribute or sublicense the
Licensed Application.
Therefore, if you consult the "App Store Product Usage Rules" section of the iTunes Store Terms and Conditions, you see this wording:
(i) You may download and sync an App
Store Product for personal,
noncommercial use on any iOS Device
you own or control.
(ii) If you are a commercial
enterprise or educational institution,
you may download and sync an App Store
Product for use by either (a) a single
individual on one or more iOS Devices
you own or control or (b) multiple
individuals, on a single shared iOS
Device you own or control. For
example, a single employee may use the
Product on both the employee's iPhone
and iPad, or multiple students may
serially use the Product on a single
iPad located at a resource center or
library.
(iii) You shall be able to store App
Store Products from up to five
different Accounts at a time on
compatible iOS Devices.
(iv) You shall be able to manually
sync App Store Products from at least
one iTunes-authorized device to iOS
Devices that have manual sync mode,
provided that the App Store Product is
associated with an Account on the
primary iTunes-authorized device,
where the primary iTunes-authorized
device is the one that was first
synced with the iOS Device or the one
that you subsequently designate as
primary using the iTunes application.
The rules are quite explicit about commercial enterprises not being allowed to just purchase one copy and install it on all devices at that company.
It is for this reason that Apple offers volume discounts for applications purchased in bulk (where the developer has checked the box in iTunes Connect allowing for this). I can't find the business equivalent, but here's Apple's page on the educational bulk discount program.
While I could see how you could use in-app purchase to activate functionality in an application and make sure that it was properly licensed, I've heard complaints about the practical difficulties of deploying applications using this in educational and business settings. Many applications use this approach for free Lite versions that upsell into the full paid application, so Apple has no problem with this.
One thing I do recommend is that you not abuse the ad hoc distribution system to do any licensing workarounds. The last time some geniuses did this caused Apple to clamp down on everyone's ad hoc licenses and make our lives more difficult.
The correct answer here is for the companies you sell to to purchase an Enterprise program from Apple, then for you to license the application to them. You can use over-the-air distribution to get the application onto their devices, and charge them a per-user or per-device fee.
Let anyone download the app for free in the app store, but charge for licenses/subscriptions outside of the app store. You can then require them to register each device they want to use and you charge accordingly.
Can I bypass Apple's in app purchase mechanism by outside billing?
Thq question was asked long before, but still I feel that the answer might help someone having the issue. All you need is Apple's Volume Purchase Program. It provides the option for custom B2B apps developed by third-party developers, that too can be seen and downloaded only by the authorized client. Cool, isnt it? :-)
For clarifications, see the FAQ
The client can do a bulk purchase, on which they will receive a bunch of URLs. By opening the URL in iOS device is enough to install the app. Of course, you need a Apple Developer account for download and install, I think.