| 1. |
Power up the chip and negotiate the communications protocol |
| |
|
| 2. |
Process the list of EMV payment applications supported by the chip,
e.g. credit, debit or purse and giving a choice to the cardholder
or asking for their confirmation if appropriate. |
| |
|
| 3. |
Select the chosen application and read all the relevant data from
the chip. |
| |
|
| 4. |
Perform cryptography to validate the chip data. |
| |
|
| 5. |
Check the PIN. If not PIN, signature is checked after the EMV element
of the transaction is complete. |
| |
|
| 6. |
On the basis of floor limits, type of transaction, success of PIN
verification, expiry dates, etc. decide whether to approve off-line,
go on-line or decline. |
| |
|
| 7. |
The chip is then asked whether it would like to override the decision
to approve off-line, go on-line or decline. |
| |
|
| 8. |
If transaction goes on line, additional EMV chip data is sent to
the bank. Part of this is a cryptographic packet which is validated
by the issuer. The response from the issuer may also contain a cryptographic
packet for validation by the chip. Thus a secure link can be made
directly between chip and issuer despite insecure data transmission
in between. |
| |
|
| 9. |
Part of the response from the bank may contain a script which is
processed by the chip, e.g. to disable the chip if it is stolen, unblock
the PIN, etc. |
| |
|
| 10. |
The chip is asked whether it would like to override the decision
to approve or decline the transaction. |
| |
|
| 11. |
The EMV element of the transaction is now complete, the chip is
powered down and may be removed. |
| |
|
| 12. |
If signature verification was required, or if, in the UK, a referral
response came back from the bank, these are now processed. |
| |
|
| 13. |
At this stage and at the retailer's own risk, they may still approve
a transaction which has been declined. There will not be the necessary
transaction certificate to put in the settlement file so payment is
not secured. |
