Payment card system authorization and settlement explanation including need-to-know information.

1. |
Card Payment System Overview
Narudom Roongsiriwong CISSP
24 June 2016

2. |
About Me
Head of IT Security, Kiatnakin Bank PLC (KKP)
Committee Member – Cloud Security Alliance (CSA)
Consultant – OWASP Thailand Chapter
Working Team for Adviser to the Finance Ministry's National
e-Payment project
E-mail: narudom.roongsiriwong@owasp.org
24 June 20162

3. |
When the customer want to make a payment by
credit/debit card, authorization flow starts.
24 June 20163

4. |
Simplified Authorization Flow
1. The customer make a payment. Enter cardholder data into the
merchant’s payment system (POS, e-commerce website).
2. The Merchant sends card data to an acquirer/payment
processor who will route data to through the payments system
for processing. For e-commerce, a payment gateway may
redirect website to the acquirer.
3. The acquirer/processor sends the data to Payment brand
4. Payment brand forwards the data to the issuer. The issuer
verifies and make approval. . For e-commerce, a payment
gateway may redirect website to the issuer (ex. Verified by
VISA).
24 June 20164

5. |
Simplified Authorization Flow for Card Payment
5. If the issuer agrees to fund the purchase, it will generate
an authorization number and routes back to the card
brand.
6. Payment brand forwards the authorization code back to
the acquirer/processor.
7. The acquirer/processor sends the authorization code back
to the merchant.
8. The merchant concludes the sale with the customer.
24 June 20165

6. |
Electronics Data Capture (EDC)
24 June 20166
A Point-of-sale terminal for submitting and validating card
transactions to a merchant account provider, or some other
card transaction processor.

7. |
EDC Use Case
24 June 20167

8. |
ISO 8583 Financial Transaction Message Format
24 June 20168
One of the most widely used format
Card originated transactions
purchase, withdrawal, deposit, refund, reversal, balance
inquiry, payments and inter-account transfers
System-to-system messages
secure key exchanges, reconciliation of totals, network
sign-on/sign-off and other administrative messages
Structured as follows
Header
Message
type identifier
Primary
bitmap
Secondary
bitmap
Data elements

9. |
ISO 8583 Message Structure
24 June 20169
Header
Network specific thus Visa and MasterCard use a different
message header structure
Message Type Identifier (MTI)
Classifies the high level function of the message
One or more bitmaps indicating which data elements are
present in the message
Data elements or fields
Bitmap Binary value Defines presence of fields
42100011
02C04804
0100001000010000000000000001000
1000000101100000001001000000001
00
2, 7, 12, 28, 32, 39, 41, 42, 50,
53, 62

10. |
Magnetic Card vs EMV
24 June 201610
Magnetic Stripe Card Chip Card
Initial
terminal-
card
interaction
Terminal gets static data
from card
• Terminal identifies card type (chip, non-
chip)
• Terminal and card agree on Application ID
• Card generates request cryptogram
Request
includes
Data from magnetic
stripe
Authorization processing must include EMV
• Validate request cryptogram
• Optionally generate response cryptogram
• Optionally generate a command for the
card
Response may include new EMV data
elements
Final
terminal-
card
interaction
• Card validates response cryptogram if
sent by issuer
• Card executes command if sent by issuer

11. |
Verification Options
Cardholder Verification
24 June 201611
No CVM
Signature
On-line PIN at ATM
On-line PIN at POS
Off-line PIN plain texted
Off-line PIN enciphered
Verification Fallback

12. |
Card not Present
24 June 201612
A remote purchase where the cardholder and the card are
not present at the point-of-sale
A remote purchase CNP transaction can be for:
Mail order
Telephone order
A sale made over the internet
Recurring
Verification
CVV2 Verification by requesting the three-digit code
AVS verify the cardholder’s billing address by the issuer
Verified by VISA®

13. |
Card Management System
24 June 201613
 Register – adding a smart card to the smart card management system
 Issue – issuing or personalizing the smart card for a smart card holder
 Initiate – activating the smart card for first use by the smart card holder
 Deactivate – putting the smart card on hold in the backend system
 Activate – reactivating the smart card from a deactivated state
 Lock – also called block; smart card holder access to the smart card is
not possible
 Unlock – also called unblock; smart card holder access to the smart
card is re-enabled
 Revoke – credentials on the smart card are made invalid
 Retire – the smart card is disconnected from the smart card holder
 Delete – the smart card is permanently removed from the system
 Unregister – the smart card is removed from the system (but could
potentially be reused)
 Backup - Backup smart card certificates and selected keys
 Restore - Restore smart card certificates and selected keys

14. |
Simplified Settlement Flow
24 June 201614
1. The merchant submits settlement message from EDC. For e-
commerce, it would be done automatically.
2. Merchant’s bank sends clearing data to payment brand
3. Payment brand calculates net settlement position and sends
advisement to merchant’s bank and cardholder’s bank and
Transfer Fund Order to settlement banks

15. |
Simplified Settlement Flow
24 June 201615
4. Settlement bank facilitates exchange of funds to
guarantee payment to merchant’s bank
5. Cardholder’s bank sends payment to settlement bank
6. Merchant’s bank pay merchant for card purchases.
7. Cardholder’s bank bills cardholder for purchases

16. |
Thank You
24 June 201616