In reply to Rick F.

It is a credit transaction. The terminal will normally be injected with some sort of encryption key. The one I work with for example is a 3DES DUKPT system (an Initial Encryption Key, IPEK needs to be injected so that our Hardware Security Module can decrypt it prior to sending the data on to the card networks for authentication). This is not new though as all readers up till this point have had encryption. Maybe I am mistaking your debit pin for normal PAN (Account number) encryption. If so, very sorry. I am still a bit new to the field.

The readers will need PCI-PTS (PIN Transaction Security) for PIN based transactions, but as America is non 100% PIN based, there will be some readers that have no PIN PAD and thus will not be able to accept CHIP and PIN only cards...

1. EMV card is inserted and card is validated by the terminal
2. PAN is encrypted (in our case, using DUKPT and 3DES)
3. Encrypted data is sent up to our PCI-DSS datacenter where it is decrypted (there is still another layer of encryption in the EMV package)
4. Decrypted data is passed to bank for authorization (securely... it will depend on the acquiring bank on how it is sent along... HTTPS, VPN, etc)

5. Aquiring bank does it's thing (sending along to the cardholders bank to make sure they have an active/valid account etc) and sends a reply back through to the merchant (Yes/No basically)