🔷 1. Understanding ISO 8583
ISO 8583 is a standard for financial transaction message format. Each transaction (e.g., purchase, refund, balance inquiry) is encoded into a message with fields called Data Elements (DEs) (like DE2 for PAN, DE4 for amount, DE22 for POS entry mode, etc.).
🔷 2. What is Certification?
Certification ensures that your terminal, switch, or host system:
- Communicates correctly with the card scheme’s network.
- Follows functional, format, and security requirements.
- Accurately processes different types of card transactions (Online, Offline, PIN, Contactless, Fallback, Reversal, etc.)
🔶 Steps to Certify RuPay, MasterCard & Visa Cards Using ISO 8583
✅ Step 1: Understand Scheme-Specific Certification Requirements
Each card network (RuPay, Visa, MasterCard) provides:
- Certification Test Plans
- Host Interface Specifications (HIS)
- Test Cases & Expected Results
- Field mapping for ISO 8583 (for DE1 to DE128)
✅ Step 2: Prepare the System for Testing
You need a test-ready environment:
- POS terminal or acquiring system integrated with your host.
- Support for all card types: EMV, Contactless (CTLS), Magstripe, Fallback.
- ISO 8583 message parser and validator.
- Logs enabled for all DEs.
Each application transaction includes 1 Bitmap, A Bitmap consists of 64 bits from the left starting with bit ‘1’. If any ISO message doesn’t support a secondary bit map processing, then the first bit of the bit map is ‘0’
✅ Step 3: Execute Test Scenarios
Perform the required functional test cases as per scheme guidelines. Typical test cases:
| Test Case Type | Description |
|---|---|
| Purchase | Online EMV with PIN, Offline EMV, CTLS, fallback |
| Reversal | Full/partial reversals with correct DE90 |
| Refund | Correct use of DE2, DE3, DE4, DE22, DE37 |
| Balance Inquiry | Using correct processing code (DE3) |
| Declined Transactions | Handle response codes like 05 (Do not honor), 91 (Issuer unavailable) |
| PIN Bypass / Offline PIN | Must reflect in DE22 and EMV DEs |
| Fallback / Magstripe / Manual | Proper handling of DE22 and fallback rules |
| Key Exchange / MAC validation | For secure messaging |
✅ Step 4: Validate ISO 8583 Messages
Ensure:
- All required fields are present (DE2, DE3, DE4, DE11, DE22, DE35, DE37, DE39, DE41, DE42, DE52, DE55, DE90).
- DE values follow correct formats (e.g., numeric/ASCII/BCD).
- Field dependencies are respected (e.g., DE52 with DE53, DE22 with DE55).
✅ Step 5: Submit Logs to Scheme
Once tests are done:
- Share ISO 8583 request/response logs.
- Mention test cases and results.
- Scheme will verify log compliance.
- If passed, you receive a certification letter or approval for production.
💳 Examples for Each Scheme
🔷 RuPay
- Uses NPCI-provided ISO 8583 specs.
- May involve certifications like: POS Certification, Host Certification, Terminal Integration Certification.
- Done via RITS (RuPay Integration Test System).
🔷 Visa
- Uses VTS (Visa Test System).
- Test message formats follow VisaNet standards.
- Visa provides simulation tools for test card profiles.
🔷 MasterCard
- Certification through MCPS (MasterCard Certification Platform System).
- Test plans managed in MasterCard’s CollabNet portal.
- Focus on EMV contact, CTLS, Online/Offline, and Risk Management.
📌 Summary
| Step | Action |
|---|---|
| 1. | Study scheme ISO 8583 specs and certification test plans |
| 2. | Set up test environment with logging and validation |
| 3. | Execute all required test cases (EMV, CTLS, fallback, refund, etc.) |
| 4. | Verify DE fields, values, and formatting for ISO 8583 compliance |
| 5. | Submit logs for review and get certified |
✅ Sample ISO 8583 Log for EMV Chip Transaction with PIN
📌 Message Type Indicator (MTI):
javaCopyEdit0200 — Financial Transaction Request (Purchase)
📋 Sample Data Elements Breakdown:
| DE# | Field Name | Sample Value | Description |
|---|---|---|---|
| 2 | Primary Account Number | 539999XXXXXX1234 | PAN (masked) |
| 3 | Processing Code | 000000 | Purchase |
| 4 | Transaction Amount | 000000010000 | ₹100.00 |
| 7 | Transmission Date & Time | 0617171032 | MMDDhhmmss |
| 11 | STAN (System Trace Audit) | 123456 | Unique for each transaction |
| 14 | Expiry Date | 2608 | YYMM |
| 22 | POS Entry Mode | 553 | EMV chip with PIN |
| 23 | Card Sequence Number | 001 | Optional |
| 25 | POS Condition Code | 00 | Normal |
| 35 | Track 2 Data | 539999XXXXXX1234=26081234567890123456 | |
| 37 | Retrieval Ref Number | 123456789012 | RR Number |
| 38 | Authorization ID Response | 654321 | Provided by issuer |
| 39 | Response Code | 00 | Approved |
| 41 | Terminal ID | TERM1234 | 8-char |
| 42 | Merchant ID | MRC123456789012 | 15-char |
| 52 | PIN Data | FFFFFFFFFFFFFFFF | Encrypted |
| 55 | ICC Data | 9F2608AABBCCDDEEFF… | EMV tag data |
| 90 | Original Data Elements | For reversal/refund | |
| 128 | MAC (Message Auth Code) | A1B2C3D4E5F60789 | Optional in RuPay |
🧾 Sample Raw ISO 8583 Log (Hex Dump Representation)
ISO 8583 Message
MTI: 0200
Bitmap: B238000108C00000
DE 02: 5399991234 DE 03: 000000 DE 04: 000000010000 DE 07: 0617171032 DE 11: 123456 DE 14: 2608 DE 22: 553 DE 23: 001 DE 25: 00 DE 35: 5399991234=26081234567890123456
DE 37: 123456789012
DE 38: 654321
DE 39: 00
DE 41: TERM1234
DE 42: MRC123456789012
DE 52: FFFFFFFFFFFFFFFF
DE 55: 9F2608AABBCCDDEEFF1122…
DE 90:
DE 128: A1B2C3D4E5F60789
✅ Certification Focus Points
DE22 = 553→ Must match EMV with PINDE55→ Contains all required EMV tags like9F26,9F27,9F10,5F2A, etc.DE52→ Encrypted PIN block presentDE39 = 00→ Transaction approvedMTI = 0200→ RequestMTI = 0210→ (response, not shown here)
Let me know if you want:
- Sample Reversal (MTI 0400)
- Sample Fallback Transaction (DE22 = 620 or 623)
- Sample CTLS (Contactless) Transaction (DE22 = 911/913)
- Sample Declined Response (DE39 = 05/91)
✅ EMV TLV Parser – Explanation & Sample Tool Format
EMV TLV stands for Tag-Length-Value format used in EMV transactions, especially in DE55 (Data Element 55) of ISO 8583, which contains ICC (Integrated Circuit Card) data.
🔍 What is TLV?
Each EMV TLV block is structured as:
cssCopyEdit[Tag] [Length] [Value]
- Tag: 1–3 bytes (identifies the data type, e.g.,
9F26) - Length: 1 byte or more (length of value in bytes)
- Value: Actual data (hexadecimal, depends on Tag)
🔖 Example TLV String (DE55 / EMV Data)
CopyEdit9F2608AABBCCDDEEFF11229F2701809F101307010103A0A800010A010000000000BF9F3704AABBCCDD9F3602001E950500000480009A031906179C01009F02060000001000005F2A020356820239009F1A020356
🧾 Parsed Output:
| Tag | Length | Value | Description |
|---|---|---|---|
| 9F26 | 08 | AABBCCDDEEFF1122 | Application Cryptogram |
| 9F27 | 01 | 80 | Cryptogram Information Data |
| 9F10 | 13 | 07010103A0A800010A01… | Issuer Application Data |
| 9F37 | 04 | AABBCCDD | Unpredictable Number |
| 9F36 | 02 | 001E | Application Transaction Counter |
| 95 | 05 | 0000048000 | Terminal Verification Results |
| 9A | 03 | 190617 | Transaction Date |
| 9C | 01 | 00 | Transaction Type |
| 9F02 | 06 | 000000100000 | Amount Authorized |
| 5F2A | 02 | 0356 | Transaction Currency Code (INR) |
| 82 | 02 | 3900 | Application Interchange Profile |
| 9F1A | 02 | 0356 | Terminal Country Code (INR) |
✅ Tag 95 – TVR (Terminal Verification Results) Decoder in EMV
The Terminal Verification Results (TVR) is a 5-byte (40-bit) bitmap that indicates the status of various checks performed by the terminal during a chip card transaction.
📌 Structure of TVR (Tag 95)
TVR = 95 05 <value>
- Length: 5 bytes = 40 bits
- Each bit has a predefined meaning according to EMVCo specification.
📋 TVR Bit Mapping
| Byte | Bit | Meaning |
|---|---|---|
| Byte 1 | 8 | Offline data authentication was not performed |
| 7 | SDA failed | |
| 6 | ICC data missing | |
| 5 | Card appears on terminal exception file | |
| 4 | DDA failed | |
| 3 | CDA failed | |
| 2 | Reserved | |
| 1 | Reserved | |
| Byte 2 | 8 | ICC and terminal have different application versions |
| 7 | Expired application | |
| 6 | Application not yet effective | |
| 5 | Requested service not allowed for card product | |
| 4 | New card | |
| 3 | Reserved | |
| 2 | Reserved | |
| 1 | Reserved | |
| Byte 3 | 8 | Cardholder verification was not successful |
| 7 | Unrecognized CVM | |
| 6 | PIN Try Limit exceeded | |
| 5 | PIN entry required and PIN pad not present or not working | |
| 4 | PIN entry required, PIN pad present, but PIN was not entered | |
| 3 | Online PIN entered | |
| 2 | Reserved | |
| 1 | Reserved | |
| Byte 4 | 8 | Transaction exceeds floor limit |
| 7 | Lower consecutive offline limit exceeded | |
| 6 | Upper consecutive offline limit exceeded | |
| 5 | Transaction selected randomly for online processing | |
| 4 | Merchant forced transaction online | |
| 3 | Reserved | |
| 2 | Reserved | |
| 1 | Reserved | |
| Byte 5 | 8 | Default TDOL used |
| 7 | Issuer authentication failed | |
| 6 | Script processing failed before final GENERATE AC | |
| 5 | Script processing failed after final GENERATE AC | |
| 4-1 | Reserved |
🧪 Example Decode
Input:
nginxCopyEditTag 95 = 0000048000
Step-by-step:
- Convert hex
0000048000to binary: iniCopyEdit00 = 00000000 00 = 00000000 04 = 00000100 80 = 10000000 00 = 00000000 - Merge bits into bitfields: pgsqlCopyEdit
Byte 1: 00000000 → All OK Byte 2: 00000000 → All OK Byte 3: 00000100 → Bit 6 set = PIN Try Limit Exceeded ❗ Byte 4: 10000000 → Bit 8 set = Transaction exceeds floor limit ⚠️ Byte 5: 00000000 → All OK
🔍 Decoded Result:
- ✅ SDA, DDA, CDA → Passed
- ❌ PIN Try Limit Exceeded
- ⚠️ Floor Limit Exceeded (went online)
✅ ISO 8583 Bitmap – Detailed Explanation with Example
The ISO 8583 bitmap is a crucial component of the message that indicates which data elements (DEs) are present in the transaction.
🧾 What is a Bitmap in ISO 8583?
- It’s a 64-bit (or 128-bit for extended bitmap) binary map.
- Each bit position corresponds to a Data Element (DE).
- If bit n = 1, then DE n is present in the message.
📘 Types of Bitmaps
| Type | Bits | Hexadecimal Length |
|---|---|---|
| Primary Bitmap | 64 | 16 bytes (hex) |
| Secondary Bitmap | 64 | 16 bytes (hex) |
| Tertiary Bitmap | 64 | Rarely used |
- If bit 1 (MSB) is set → Secondary Bitmap is present
📌 Sample Hex Bitmap (Primary)
makefileCopyEditHex: F23C048108C00000
Step 1: Convert Hex to Binary
makefileCopyEditF2 = 11110010
3C = 00111100
04 = 00000100
81 = 10000001
08 = 00001000
C0 = 11000000
00 = 00000000
00 = 00000000
Combined (64-bit):
11110010 00111100 00000100 10000001 00001000 11000000 00000000 00000000
Step 2: Determine Active Data Elements
| Bit # | Status | Meaning |
|---|---|---|
| 1 | 1 | Secondary bitmap present (DE 65–128 may exist) |
| 2 | 1 | DE 2 → PAN |
| 3 | 1 | DE 3 → Processing Code |
| 4 | 1 | DE 4 → Amount |
| 7 | 1 | DE 7 → Transmission Date & Time |
| 11 | 1 | DE 11 → STAN |
| 14 | 1 | DE 14 → Expiry Date |
| 22 | 1 | DE 22 → POS Entry Mode |
| 25 | 1 | DE 25 → POS Condition Code |
| 35 | 1 | DE 35 → Track 2 Data |
| 37 | 1 | DE 37 → Retrieval Ref # |
| 41 | 1 | DE 41 → Terminal ID |
| 42 | 1 | DE 42 → Merchant ID |
| … | 0 | All other DEs not present |
🧪 Visual Bitmap Representation
plaintextCopyEditBit #: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ...
Value: 1 1 1 1 0 0 1 0 0 0 1 1 1 1 0 0 ...
🛠️ Bitmap Calculation Example
If your message has DEs: 2, 3, 4, 11, 41
- Set bits: 2, 3, 4, 11, 41
- Convert to binary bitmap → 64 bits
- Convert to hex → 16 characters (primary bitmap)
✅ Summary
- Each bit in bitmap tells if DE is present.
- Bitmaps help parse ISO messages dynamically.
- Common tools: Wireshark, Hex editors, or custom parsers.