I successfully created a pass with PassKit. But I want to add NFC capability to this pass to, when other smartphone (NFC reader) read the card, an URL will be opened to this smartphone.
I don't know if I need to do an NFC Certificate request for Apple Pay, because I don't want to use NFC for Apple Pay (https://developer.apple.com/contact/passkit/) ?
Can I achieve this without a certificate ?
No, you absolutely must have a certificate authorizing the use of NFC even if it is not a payment.
To obtain a certificate, contact Apple: http://developer.apple.com/contact/passkit.
But they rarely answer
Related
First, forgive my complete ignorance. I've tried to research this, but I clearly don't know the correct terminology for what I'm trying to accomplish.
I'm trying to set up NFC chips that link to separate, unique profiles. The profiles will be to a web app, but I want to hide the hyperlink to prevent someone from being able to copy the direct link to the profile and put it into another NFC Chip.
Example: A Plastic Business Card with an NFC chip that takes someone to a unique web app profile on their phone. I want to make sure someone can't create a new card and copy/paste the profile link into the new card on their own.
Note: The NFC Chip at this current moment will NOT be used for contactless payments.
Thanks.
So first point, security on NFC is hard, you can make it more difficult but not impossible to get the data from the card depending on how tightly you can control access to readers etc.
But from the sounds of it you are looking just to prevent casual copying.
It also sounds that you want the reading device to be a reading device.
So there are various techniques you can use to prevent casual copying, below I'll list a few in some order of complication (some can be used in combination with others):-
There is a common theme and drawbacks to some of these techniques.
You have to write your own phone App and get it to display the web App in it's own webview as you do not want the URL shown in a standard web browsers address bar.
Any protections you put in the phone App can be extracted from it by reverse engineering the phone App.
Use a NFC Tag like the Ntag21x range that has read password protection. You would write a phone App that knows the password to read the URL and then the App displays it
Encrypt the data on the card using standard encryption method and write an phone App that knows how to decrypt it and has the encryption keys to read the URL
Don't use a standard data format like Ndef but use your own data format again you phone app needs to know how you formatted the data to display
You can make reverse engineering of item 1 and 2 harder by not storing the "secrets" in the App itself but have it get it across the network at run time, but getting the secret can be reverse engineered or sniffed from the network.
We are developing mobile app in which customers can access multiple loyalty programs. The most convenient way for customers is to use nfc loyalty card and we are in search of ways to implement it via google pay passes and apple wallet passes
However, we are quite not familiar with the pipeline and user—>PoS—>etc interactions.
Could someone explain, please:
What process is happening after card is submitted to PoS terminal? (Interactions with GPay/Wallet and our backend).
Any information is appreciated!
For the Google Pay Passes side the protocol to transmit loyalty card payload through NFC is called Smart Tap. The design is as follows:
The phone with Google Pay and loyalty passes (enabled with Smart tap) loaded into the wallet is tapped on the terminal.
The terminal through Smart Tap Protocol presents a unique collector ID and signed information to the Google Pay app.
The Google Pay app uses this signed information to verify the identity of the terminal and that collector id is used to determine which passes it transmits.
Google Pay transmits the pass payload through Smart Tap from the wallet.
The terminal then decrypts the payload and passes upstream, to the POS.
The best way to think about NFC transmission is as an encrypted alternative to transmitting a value using barcode.
I want to build a payment app by NFC and iOS13 to send/receive data from contactless payment machine for a country not support apple pay, is it possible?
The only way to work with NFC at iOS is Core NFC.
https://developer.apple.com/documentation/corenfc
You can read tags and get some special Informations. For example to get information about a product.
In my opinion Apple blocks the data evaluation of payments. So you can only use the Core NFC.
When you enable the nfc dictionary in the pass what does that pass do? It emulates an MIFARE card or simply extends Apple Pay with some extra data?
Yes, it certainly is possible to get an NFC certificate. However, the details of the implementation are protected by an NDA. There is a link where you can apply for a certificate here
For in-app purchases for iOS we can use an online API for validation, meaning that we can validate the purchase on our own server.
Is there any way (API) for such validation of in app purchases for OS X?
I've found only this snippet about in-app validation for Mac and it seems that Apple doesn't provide any API for online validation.
Or maybe there is some plan from Apple to support online validation for OS X?
My app EasyBooks provides an online component that users pay yearly for. It wouldn't make sense to provide this as a non-consumable type as it only really works as a consumable (however it's really a non-repeating subscription in iOS). I would like to offer this in-app and I think I have a solution finally...
I used one of my Apple DTS tickets to query a statement made in the StoreKitGuide document. It says ...
"OS X supports both the server validation method described in this
chapter and the local validation method..."
I got a reply from Apple saying ...
"The steps for verifying your In-App Purchase products for Mac
applications are the same used for iOS applications. The difference is that you will be assigning your base 64 encoded app receipt (rather than the content of the transactionReceipt property) to the receipt-data field. Retrieve the full Mac App Store receipt for your application, then encode it using base64 encoding. Create a JSON object with a single key named receipt-data and assign your encoded receipt to it. Proceed as outlined in the Verifying a Receipt with the App Store section of the In-App Purchase Programming Guide.
Note: In App Purchases receipt are included in the associated Mac app's receipt. You must check the receipt associated with your app to verify the validity of the In-App Purchase receipts that it contains. Doing so also allows you to enable the appropriate functionality in your app."
So after some failed attempts, I did manage to get this working with the caveat that the receipt data returned by Apple's servers does not contain the 'hash of the GUID' and therefore does not tie the receipt data to any particular hardware.
This can be tested on your Mac quite easily using these steps:
Find the Mac app receipt file (it's in your app's bundle once you've run the app and entered your (test) Apple ID and password.
At the command line, base64 -i receipt will base64 encode the receipt with no line breaks (that's important)
Again at the command line, curl -d '{ "receipt-data": "<your b64 string here>" }' https://sandbox.itunes.apple.com/verifyReceipt
This returns JSON data in the format
{"status":0,
"environment":"Sandbox",
"receipt":{"adam_id":"0",
"bundle_id":"uk.co.geode.easybooks",
"application_version":"2.2.7",
"download_id":"0",
"in_app":[ {"quantity":"1",
"product_id":"uk.co.geode.easybooks.syncing",
"transaction_id":"1000000034508678",
"purchase_date":"2012-09-05 12:00:17 Etc/GMT",
"original_transaction_id":"1000000034508678",
"original_purchase_date":"2012-01-24 10:16:17 Etc/GMT"} ]}}
I have not confirmed it yet, but apparently (according to the Apple engineer) any consumable types of in-app purchase will be added to the receipt when first purchased, but removed after any further purchases or restore operations. I wonder whether it might be a good idea to make the code running in the app make a copy of the receipt file after each purchase just in case our own servers are down at the time the app tries to validate the receipt. Users may otherwise try to restore purchases, not realising this will remove any consumable product receipts.
I hope that helps.
(ORIGINAL COMMENTS FOLLOW)
I have the same issue. I have an iOS app in the store that has a mix of consumable and non-consumable products that can be purchased in-app. The consumable product is a service, which is fulfilled by my webserver. In the StoreKit delegate method paymentQueue:updatedTransactions:, I use the transactionReceipt property, which is an NSData object. I encode this to base64 and send it to the server. Out on the server I pass the receipt to Apple's servers for validation.
But for Mac OS, there is no transactionReceipt property on the SKPaymentTransaction, so we cannot validate receipts in the same way.
We can do the non-consumable products, which may help you. When an in-app purchase is made on Mac OS, the receipt is updated in the app bundle. It is then possible to parse the receipt file looking for each in-app receipt, which are all stored in the receipt file in the main bundle. For more about that see http://developer.apple.com/library/mac/#releasenotes/General/ValidateAppStoreReceipt/_index.html
This works fine for me when I use the non-consumable product, but I have one consumable and this is not updated into the app's receipt file. Without the transactionReceipt property, I don't see any way for my server to validate that the receipt is genuine. If anyone else has any other experience please let us know!
Anyone with an Apple developer account can also read about this on the Apple developer forum:
https://devforums.apple.com/message/548411#548411
SwiftyStoreKit is popular:
https://github.com/bizz84/SwiftyStoreKit
InAppReceipt for local receipt validation:
https://github.com/tikhop/TPInAppReceipt