I would like to know if there is a possibility of changing the PIN of an EMV card using POS devices equipped with an IC Reader. Or if that functionality is reserved for ATMs only.
If its possible through POS Devices, what series of commands does one need to issue to make the PIN change.
EMV Offline PIN change is performed by issuer script that is sent together with response to authorization request. It does not matter if device is POS or ATM. It technically works the same and issuer scripts are guaranteed (up to 127 bytes) to be transferred through any authorization protocol.
ATMs have additional requirements from payment schemes, so PIN Change and PIN unblock transaction support are obligatory. With POS, there is no direct requirement to be able to initiate such transactions, but if it is performed over some other channel (IVR, online, etc), issuer scripts can transfer the PIN to the card on the next online transaction regardless if card is used on ATM or POS.
No special commands are there for PIN change, the transaction will require entering both old and new PIN, send them in encrypted PIN Blocks and the response shall contain issuer script that will be sent by EMV kernel to the card (without modification or interpretation by the device) as any other issuer script.
Side note - bigger issuer scripts are not common and handled in devices that are connected through On-us interfaces with issuer banks. For large issuer scripts, devices that can avoid card removal during the process are preferred (mostly bank owned ATMs with motorized readers).
EMV cards supported two types of pin concept -
1) Offline pin
2) Online pin.
If card supported offline pin i.e. pin is stored in the card itself and if it need to change then issuer script will be executed.
Issuer script is a set of commands that runs between POS and EMV card and change the offline pin.
If card supported online pin i.e. pin is not inside the card, saved at somewhere. For changing this pin, no need to present card at POS, can change by any mode ATM, Internet Banking etc.
Sorry my response might be late but i hope it helps. This entirely depends on the functions supported by your terminal acquire.
For offline pin change for instance;
If the function is supported by your aquirer/issuer, the user can initiate a pin change on the terminal itself.
After that, the very first transaction on the card will return an issuer script data in the tag "72" to communicate with the pin change function on the card run before the second generate Account Cryptogram. If the response to the issuer script command returns 9000, the proccess completes to second generate AC command, ortherwise the Terminal runs a trasuction reversal process hence the pin reset failed.
It is a long broad respose but i hope it covers the idea.
As long as the POS has IC reader, you can read IC card based getProcessing options and static data for authentication, the answer is YES.
Whether the PIN is stored on the card in OWNERPIN variable or at the Bank(the issuer) is a function of the card usage profile defined by the issuer. Your terminal application can communicate the PIN to the card through various processing steps.
Related
We created a wallet pass and sent the wallet pass invitation email to end-users. However, there was an issue with the back-end APIs which prevented the Apple pass from automatically calling the device registration API.
The question I have is, do we need to re-inform all user to reinstall the Pass, or will the Pass automatically try re-registering by calling the device API.
Thank you.
The way you have worded your question possibly describes an impossible situation. A valid pass will always attempt to register. You state that your API was the issue, but an issue with a web service implementation would not prevent devices attempting to call it.
If the pass.json contains a valid https webServiceURL an authenticationToken, it will call the device registration endpoint after it has been added to the user's wallet. If the device does not get a 201 or 200 response, it will continue to retry, progressively backing off from every few seconds, to every few days for a period of around 2 weeks.
Therefore, if your pass.json contained the correct information; assuming that the issue was with your device registration endpoint and assuming that you picked up and addressed the issue quickly, then you should see device registrations coming in without having to do anything.
If it took longer than a couple of weeks or if you want to accelerate the process, you could ask your users to toggle the Automatic Notifications setting on the back of the pass. This will force the device to attempt a re-registration.
If however, the pass does not contain a webServiceURL, or if the webServiceURL was incorrect, then the device will not call back, or will call the incorrect endpoint. In this case, the only option is to have your users reinstall the pass. In this case, it is not your API that is causing the problem, but your passes.
I have a terminal that behaves this way, when offline PIN is requested and the user presses enter without typing the PIN it goes on to request online PIN instead.
I want to know if this is the recommended behaviour. My team argues that it should fail if the offline PIN is not entered instead of requesting online PIN.
This a feature called PIN bypass.
What is an additional option is subsequent PIN bypass (which means bypassing all PIN methods if bypass is requested on one of them). If you have bypass enabled but not subsequent and the next applicable method will be online PIN, it will be requested.
In either case, offline PIN is just one of the cardholder verification methods. Failing in such situation without processing the rest of the CVM List when method has 'Apply succeeding rule when this one fails' bit set would be against EMVCo specs.
The new platform API at Clickatell seems to not allow you to add "from" to the JSON payload, complaining that it not a 2 way integration, but the is no possibility to add a text moniker to the short codes so that instead of the number "COMPANY" would appear
This is possible with the older api. Clickatell endpoints, and wondering if anyone can confirm that this functionality is actually removed, but better still suggest a workaround if it is
They used to allow this a long time ago (TPOA - transmission path originating address)... looks like the API's haven't been updated to reflect that now it's not a free-for-all, but restricted to short or long codes you have purchased via them.
The Platform account doesn't have the sender ID feature - however, the FROM parameter is still available for any two-way integration with an active two-way subscription. The subscription can either be for a short code or a long number, if specified in the message submission. If the feature is supported by suppliers and network operators, these messages will deliver with the short code or long number specified.
I'm trying to completely unregister a device token using the Urban Airship API (http://docs.urbanairship.com/api/), previously registered via an iOS device. I am doing this because I would like to verify the complete remote notification registration process.
There is a GET device_id endpoint:
GET /api/device_tokens/<device_token>
I was hoping there would be an endpoint like:
DELETE /api/device_token/<device_token>
DELETE /api/device_tokens (+send json data)
Maybe what I'm looking for can be achieved some other way? Or maybe this is an incorrect flow? I believe the old interface/API had this capability which is why I assumed it still existed.
Right now I'm relying on the "last_registration" value (from the GET endpoint) to inform me that the device has been registered, but I would like some way to completely remove the registered device/token via the API.
Doesn't work that way. Apple is the one the assigns and manages the lifecycle of device tokens. Urban Airship is a provider that handles the management/storage/utilization of said device tokens. Apple, however, is the one that manages the lifecycle of the device token based on the device and its actions. The best thing is to simply listen to the feedback to determine if that device token is still active or not. Apple's documentation on the matter is available here.
In regards to the old API; there was indeed a way to mark the device as inactive. However, as stated above, Apple manages the device tokens status. So, if the DT was indeed 'active' despite a delete/inactivate call was made on that DT, Apple would simply re-activate that DT, rendering that endpoint pointless.
I have developed a desktop application using HTML 5 and node web-kit .
I would like to track parts of the app , such as how long its used , clicks ect.
I would like the analytics system to work both on and offline (storing data until its on-line).
Is there anything that I could use to do this?
The Google measurement protocol allows you to track everything that can send an http request. You need to generate a unqiue client id to group pageviews into session (the part is usually done by the Javascript tracker which does not help you) and can then choose between various interaction types and their related data to be added as parameters in a request to the Google Analytics server.
As far as offline capabilites, there is a "queue time" parameter that allows you to send delayed calls to GA. However as per documentation that delay is 4 hours at most (intended for Smartphones and Tablets that temporarily lose connection rather than to work permanently offline).
In the end it depends what data you need - you might just as well send calls to your own server and log them in a csv file and feed that to Klipfolio or some other dashboard solution (or even use Excel if you expect a low data volume).