02 v.I.P. System Services Volume 1 0853A

V.I.P.
System Services, Volume 1
V.I.P. SYSTEM
Effective: 1 June 2013
© 1999 - 2013 Visa. All Rights Reserved. 0853A–22
Visa Confidential
Important Note on Confidentiality and Copyright
The Visa Confidential label signifies that the information in this document is confidential and
proprietary to Visa and is intended for use only by Visa Clients subject to the confidentiality
restrictions in Visa's Operating Regulations, non-Client Third Party Processors that have
an executed and valid Exhibit K on file with Visa, and other third parties that have a
current nondisclosure agreement (NDA) with Visa that covers disclosure of the information
contained herein.
This document is protected by copyright restricting its use, copying, distribution, and
decompilation. No part of this document may be reproduced in any form by any means
without prior written authorization of Visa.
Visa and other trademarks are trademarks or registered trademarks of Visa.
All other product names mentioned herein are the trademarks of their respective owners.
THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR

TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE
INFORMATION HEREIN: THESE CHANGES WILL BE INCORPORATED IN NEW
EDITIONS OF THE PUBLICATION. VISA MAY MAKE IMPROVEMENTS AND/OR
CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS
PUBLICATION AT ANY TIME.
If you have technical questions or questions regarding a Visa service or capability, contact
your Visa representative. If you have comments or questions about this document, send
them to TCS@visa.com.
Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X Contents
Manual.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
About This Manual
Audience.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Audience
Structure of This Manual
Manual.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Conventions.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Document Conventions
Descriptions.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
System Documentation Descriptions
Contents
Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Sources of System Information
Book.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
How To Use This Book
Samples.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Obtaining Report Samples
Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
For More Information
PART 1 V.I.P. BASICS
CHAPTER 1 INTRODUCTION TO SYSTEM SERVICES

1.1 Manual.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-
Services Not Described in This Manual 1-33
1.2 Services.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-
How the System Performs Services 1-33
1.3 Service.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-
How To Sign Up for a Service 1-55
1.3.1 Enrollment Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
1.4 Implementation.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-
How To Prepare for Service Implementation 1-5
5
1.4.1 Testing With Visa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
1.4.1.1 For More Information About the
VisaNet Certification Management
Service (VCMS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
1.4.2 Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
CHAPTER 2 SYSTEM FUNDAMENTALS

2.1 Overview.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
VisaNet Overview 2-33
2.2 Flow.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
VisaNet Process Flow 2-55
2.3 Systems.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
VisaNet Systems 2-55
2.3.1 VisaNet Integrated Payment (V.I.P.) System. . . . . . . . . . . . . . . . . . . . . . .2-5
2.3.2 BASE I System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6
2.3.3 Single Message System (SMS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6
2.3.4 BASE II System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
2.3.5 VisaNet Settlement Service (VSS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
2.4 2-10
The Common Member Interface (CMI) and Other Interface Methods . . . . . . . . . .2- 10
2.5 Parameters.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
Processing Parameters 2-11
11
2.6 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
System Messages 2-12
12
2.6.1 Message Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13
2.6.2 Message Flow Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18
2.7 Editing.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
Message Editing 2-19
19
1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 i

X Contents
2.8 Basics.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-

Message Routing Basics 2-19
19
2.8.1 Routing Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19
2.8.1.1 Routing Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-20
2.8.1.2 Internal Routing Services. . . . . . . . . . . . . . . . . . . . . . . . .2-21
2.8.1.3 Gateways to Non-VisaNet Destinations. . . . . . . . .2-21
2.9 (STIP).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
Stand-In Processing (STIP) 2-22
22
2.9.1 BASE I STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22
2.9.2 SMS STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-23
2.10 Transactions.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
Auto-Substantiation Transactions 2-24
24
Rewards.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
2-25
25
Contents
2.11 Account-Level Programs and Cardholder Rewards

2.12 Inquiries.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
Healthcare Eligibility Inquiries 2-25
25
2.13 Processing.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
MasterCard Processing 2-26
26
2.13.1 Routing Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-26
2.13.2 Visa Services and Functions Available for MasterCard. . . . . . . . . . .2-27
2.14 Service.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
U.S. Account Updater Verification (VAU) Service 2-28
28
2.15 (TAP).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
Trusted Agent Program (TAP) 2-29
29
2.16 Inquiries.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
Visa Product Eligibility Inquiries 2-29
29
2.17 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
For More Information 2-30
30
PART 2 ROUTING SERVICES
CHAPTER 3 INTRODUCTION TO ROUTING SERVICES

3.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
In Brief 3-33
3.2 Capabilities.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
Enhanced Routing Capabilities 3-33
3.3 Routing Services Available
Available.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
3-33
3.4 Tables.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
Routing Tables 3-66
3.5 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
CHAPTER 4 ATM/POS SPLIT ROUTING SERVICE

4.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
In Brief 4-33
4.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
Eligible Participants 4-33
4.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
Service Summary 4-44
4.3.1 ATM/POS Split Routing Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
4.3.2 ATM/POS Account-Type Split Routing Option. . . . . . . . . . . . . . . . . . . . . .4-4
4.3.3 Alternate Routing Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
4.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
Participation Requirements 4-5
5
4.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
4.4.3 Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
4.5 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
How ATM/POS Split Routing Service Works 4-55
4.6 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
Process Flows 4-55
4.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
Message Flows 4-99
ii Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X Contents
4.8 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-

Key Fields Glossary 4-11
11
4.9 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
12
CHAPTER 5 CHECK ACCEPTANCE SERVICE

5.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
In Brief 5-33
5.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
5.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
5.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
4
5.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4
Contents
5.4.2.1 Contracts With Check Acceptance Vendors. . . . . .5-4
5.4.2.2 Processing Considerations. . . . . . . . . . . . . . . . . . . . . . . .5-4
5.4.2.3 Delivery Method for Check Approval Requests. .5-4
5.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
Related Messages 5-44
5.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
How Check Acceptance Service Works 5-55
5.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
Process Flows 5-55
5.7.1 Processing Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
5.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
Message Flows 5-66
5.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
5.10 For More Information
Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
5-99
CHAPTER 6 GATEWAY SERVICES

6.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
In Brief 6-33
6.2 Eligible Participants
Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
6-33
6.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
6.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
5
6.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5
6.5 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
How Gateway Services Works 6-55
6.5.1 Field 62.17—Gateway Transaction Identifier. . . . . . . . . . . . . . . . . . . . . . .6-6
6.5.2 Gateway Governing Contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
6.5.3 Available Gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
6.6 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
Process Flows 6-77
6.7 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
CHAPTER 7 PIN DEBIT GATEWAY SERVICE (PDGS)

7.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
In Brief 7-33
7.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
7.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
7.3.1 PIN Debit Gateway Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
7.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 iii

X Contents
7.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4

7.5 Related Messages
Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
7-44
7.6 How PIN Debit Gateway Service (PDGS) Works Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7- 7-5
5
7.6.1 Report and File Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
7.6.2 Settlement of PDGS Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
7.6.3 Reconciliation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
7.6.4 Billing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
7-77
Contents
7.7 Process Flows

7.7.1 PIN Debit Gateway Processing Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
7.7.1.1 Assessing Surcharges. . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12
7.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
Message Flows 7-13
13
7.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
18
7.10 (EBT).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
Electronic Benefits Transfer (EBT) 7-19
19
7.10.1 Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19
7.10.2 Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19
7.10.3 EBT Processing Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20
7.11 EBT.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
Key Fields Glossary for EBT 7-20
20
7.12 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
21
CHAPTER 8 PIN/NO-PIN SPLIT ROUTING SERVICE

8.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
In Brief 8-33
8.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
8.3 Service Summary
Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
8-33
8.3.1 PIN/No-PIN Split Routing Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3
8.3.2 POS PIN Routing Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
8.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
4
8.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
8.5 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
How PIN/No-PIN Split Routing Service Works 8-44
8.5.1 How the POS PIN Routing Option Works. . . . . . . . . . . . . . . . . . . . . . . . . . .8-5
8.6 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
8.7 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
CHAPTER 9 PRIORITY ROUTING SERVICE

9.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
In Brief 9-33
9.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
9.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
9.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
4
9.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
iv Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X Contents

9.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
9.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
How Priority Routing Service Works 9-55
9.7 Process Flows
Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
9-55
9.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
Message Flows 9-88
9.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
9.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
Contents
CHAPTER 10 VISA SHORTEST ONLINE PATH (VSOP) SERVICE
10.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
In Brief 10-33
10.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
10.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
10.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
4
10.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
10.4.2 Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
10.4.3 Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5
10.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
10.6 Works.. . . . . . . . . . . . . . . . . . . . . . . . .10-
How Visa Shortest Online Path (VSOP) Service Works 10-55
10.7 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
PART 3 RISK MANAGEMENT SERVICES
CHAPTER 11 CARD RECOVERY BULLETIN (CRB) SERVICE

11.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
In Brief 11-33
11.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
11.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
11.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
4
11.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4
11.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
11.6 How Card Recovery Bulletin (CRB) Service Works Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11- 11-5
5
11.6.1 CRB Service Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
11.6.2 File Update Deadlines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
11.6.2.1 Exception File Update Deadline. . . . . . . . . . . . . . . . .11-6
11.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
Process Flows 11-66
11.7.1 CRB Process Flow (Acquirer). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
11.7.2 CRB Process Flow (Issuer). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7
11.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
Message Flows 11-88
11.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
11.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
11
1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 v

X Contents
CHAPTER 12 FRAUD REPORTING SYSTEM (FRS)

12.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
In Brief 12-33
12.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
12.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
12.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
4
12.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4
12.4.3 Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5
12.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
Contents
12.6 How Fraud Reporting System (FRS) Works

Works.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12- 12-5
5
12.6.1 Fraud Reporting Timeframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
12.6.2 Unique New Transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
12.6.3 Correct Notification Code for Identical Transaction. . . . . . . . . . . . . . .12-6
12.6.4 Rejected Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
12.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
Process Flows 12-77
12.7.1 The Fraud Reporting Decision Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-9
12.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
Message Flows 12-11
11
12.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
11
12.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
15
PART 4 VISA SECURE ELECTRONIC COMMERCE (VSEC) SERVICES
CHAPTER 13 VISA SECURE ELECTRONIC COMMERCE (VSEC) WITH VERIFIED BY VISA

(3-D SECURE)
13.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-
In Brief 13-33
13.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-
13.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-
13.4 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-
PART 5 CHIP CARD SERVICES
CHAPTER 14 VISA CONTACTLESS PAYMENT SERVICE
CHAPTER 15 VISA SMART DEBIT/SMART CREDIT (VSDC) SERVICE

15.1 Brief.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
In Brief 15-33
15.2 Participants.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
15.3 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
15.4 Requirements.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
5
15.4.1 Authorization Feature Participation Requirements. . . . . . . . . . . . . . . .15-6
15.4.2 Participation Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-6
15.4.2.1 Issuer Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-6
15.4.2.2 Acquirer Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-6
15.4.3 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-7
vi Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X Contents
15.4.3.1 Visa Test System (VTS /3). . . . . . . . . . . . . . . . . . . . . . .15-7

15.4.3.2 VisaNet Certification Management
Service (VCMS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-8
15.4.3.3 Card Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-8
15.4.3.4 Preparation Activities to Avoid
Erroneous Declines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-8
15.4.4 Card Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-8
15.4.5 Cryptogram Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-10
15.4.6 Format Options for Chip Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-11
15.4.6.1 Third Bitmap Formats. . . . . . . . . . . . . . . . . . . . . . . . . . .15-11
Contents
15.4.6.2 Field 55 Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-11
15.4.6.3 Field 55 Supplemental Data. . . . . . . . . . . . . . . . . . . .15-12
15.4.7 Field 55 vs. Third Bitmap Fields 130–149. . . . . . . . . . . . . . . . . . . . . . . .15-12
15.4.8 Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12
15.4.9 Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12
15.4.9.1 Offline Authorization Controls. . . . . . . . . . . . . . . . . . .15-12
15.4.9.2 Enhanced Cardholder Verification. . . . . . . . . . . . . .15-13
15.4.9.3 Offline Data Authentication. . . . . . . . . . . . . . . . . . . . .15-14
15.4.9.4 Online Card and Issuer Authentication. . . . . . . . .15-14
15.4.9.5 Post-Issuance Updates. . . . . . . . . . . . . . . . . . . . . . . . .15-15
15.4.9.6 Visa iCVV Convert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-16
15.4.9.7 VSDC PIN Management Service. . . . . . . . . . . . . . .15-17
15.4.9.8 Integrated Circuit Card CVV (iCVV). . . . . . . . . . . .15-17
15.4.9.9 Dynamic Card Verification Value (dCVV). . . . . .15-18
15.4.9.10 Alternative Primary Account Numbers. . . . . . . . .15-19
15.5 Messages.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
20
15.6 How Visa Smart Debit/Smart Credit (VSDC) Service Works Works.. . . . . . . . . . . . . . . . . . .15- 15-20
20
15.6.1 V.I.P. Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22
15.6.2 SMS Routing and STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22
15.6.3 BASE I Routing and STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22
15.6.4 Online Card and Issuer Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . .15-26
15.6.4.1 Offline PIN Entry Attempt Limit Exceeded. . . . .15-27
15.6.5 dCVV Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28
15.6.6 “Fallback” Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28
15.7 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
Process Flows 15-28
28
15.8 Flows.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
Message Flows 15-29
29
15.9 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
29
15.9.1 0100 Authorization and 0200 Financial Requests. . . . . . . . . . . . . . .15-29
15.9.2 Third Bitmap Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-34
15.10 Information.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
37
Index
1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 vii

THIS PAGE INTENTIONALLY LEFT BLANK.
Contents
viii Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X Figures
1 Sample Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

2-1 The VisaNet Communications Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4
2-2 VisaNet Basic Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5
2-3 The VisaNet Software System Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
2-4 VisaNet Settlement Service (VSS) Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9
2-5 V.I.P. System Software at the VIC and at the Processing Center. . . . . . . . . . . . . . .2-11
Figures
2-6 Typical Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19
4-1 ATM/POS Split Routing Option Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
4-2 ATM/POS Account-Type Split Routing Option Process Flow. . . . . . . . . . . . . . . . . . . . .4-7
4-3 Alternate Routing Option Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
4-4 Alternate Routing Option Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
5-1 Check Acceptance Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
5-2 Check Acceptance Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7
6-1 Gateway Services Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9
7-1 PIN Debit Gateway Service (PDGS) Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
7-2 PDGS Preauthorization Request Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13
7-3 PDGS Preauthorization Completion Request Message Flow. . . . . . . . . . . . . . . . . . .7-14
7-4 PDGS Financial Request Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-15
7-5 PDGS Merchandise Return or Credit Request Message Flow. . . . . . . . . . . . . . . . . .7-16
7-6 PDGS Reversal Request Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-17
8-1 PIN/No-PIN Split Routing Option Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5
8-2 POS PIN Routing Option Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6
9-1 Priority Routing Service Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9-2 Priority Routing Service Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
11-1 CRB Process Flow (Acquirer). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7
11-2 CRB Process Flow (Issuer). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8
11-3 CRB Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9
12-1 Fraud Transaction Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-9
12-2 Fraud Reporting Decision Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10
12-3 Fraud Reporting System Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-11
1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 ix

Figures
x Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X Tables
1 Document Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
2 Descriptions of V.I.P. System Manuals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2-1 Message Types Supported by V.I.P.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13
3-1 Routing Service Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5
3-2 BASE I and SMS Routing Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7
4-1 ATM/POS Split Routing Service Key Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11
Tables
5-1 Check Acceptance Vendors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
6-1 BASE I and SMS Gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
7-1 Fee Collection and Funds Disbursement Reason Codes. . . . . . . . . . . . . . . . . . . . . . . . .7-6
7-2 Field Values for PDGS by Transaction Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10
7-3 Field Values for EBT by Transaction Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20
9-1 Field 63.12—Sharing Group Code Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
11-1 Exception File Update Deadline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
11-2 Field 91 File Update Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10
11-3 Field 101 File Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10
12-1 Fraud Reporting Timeframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
12-2 Field 63.9, Position 2, Notification Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13
15-1 PIN Management-Specific Response Code Definitions. . . . . . . . . . . . . . . . . . . . . . . .15-17
15-2 Valid BASE I and SMS Message Types for VSDC Processing . . . . . . . . . . . . . . .15-20
15-3 Card Authentication in STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23
15-4 VSDC Routing and STIP Default Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23
15-5 Third Bitmap Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-34
1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 xi

Tables
xii Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X About This Manual
V.I.P. System Services, Volume 1 and Volume 2, provides updated, comprehensive

information about the various services available from the VisaNet Integrated Payment
(V.I.P.) System, including processing specification details. Message and process flow
diagrams help illustrate the ways the services work. Specific examples, where appropriate,
address actual situations, questions, and problems.
Each service chapter also lists available documents that contain additional information,
technical specifications, service implementation specifics, and service activation
information.
AUDIENCE
This manual is intended for Visa members' technical and non-technical staff and managers,
as well as for Visa Member Services and customer support personnel who answer
members' system and production questions. Non-technical staff will find this information
useful in making decisions about subscribing to services and selecting service options.
About This Manual

Readers who do not have a working knowledge of VisaNet and of the V.I.P. System
should refer to Chapter 1, Introduction to System Services, and to Chapter 2, System
Fundamentals, before reading the service descriptions.
STRUCTURE OF THIS MANUAL
The two-volume V.I.P. System Services manual has seven parts, based on service
functions.
Volume 1
2)—Part 1 provides an overview of V.I.P. services

Part 1: System Basics (Chapters 1 and 2)—
and defines the scope of the manual. It also contains a basic overview of the V.I.P. System,
including a description of VisaNet components, and V.I.P. transaction processing.
10)—Part 2 describes routing messages

Part 2: Routing Services (Chapters 3 through 10)—
to networks and to systems outside of VisaNet and additional, optional services for routing
messages within VisaNet.
12)—Part 3 contains descriptions

Part 3: Risk Management Services (Chapters 11 and 12)—
of risk management services available through the V.I.P. System.
Part 4: Visa Secure Electronic Commerce (VSEC) Services (Chapter 13)— 13)—Part 4 contains
a description of the VSEC service available through the V.I.P. System that provides security
for electronic payment transactions sent over the Internet.
15)—Part 5 contains descriptions of the

Part 5: Chip Card Services (Chapters 14 and 15)—
services available through the V.I.P. System that use chip cards and terminals capable
of reading chip cards in addition to magnetic stripe cards.
1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 1

X Document Conventions
Volume 2
Part 6: Authorization Database Files and Services (Chapters 16 through 18)—

18)—Part 6
contains an overview of the Cardholder Database and a detailed service description of the
Automatic Cardholder Database Update (Auto-CDB) Service, which members can use to
update the Cardholder Database. Part 6 also describes the Merchant Central File and the
Merchant Central File Service (MCFS) in detail.
39)—Part 7 contains descriptions

Part 7: Authorization Services (Chapters 19 through 39)—
of services that perform functions related to message authorization.
DOCUMENT CONVENTIONS
Table 1 identifies the document conventions used in this manual.
Table 1 Document Conventions
Document Convention Purpose in This Manual

boldface Extra emphasis (stronger than italics); field values and codes.
Identifies an example of what the accompanying text describes or
EXAMPLE
explains.
About This Manual
IMPORTANT Highlights important information in the text.

italics Document titles; emphasis; variables; terms or acronyms being defined.
Section names referenced in a chapter; first instance of a word used in
“text in quote marks”
an unconventional or technical context.
text in Courier New
URLs and email addresses.
font
NOTE Provides more information about the preceding topic.

n/a Not applicable.
Systems or procedures that are not directly involved in the process
shaded illustrations
being illustrated in the graphic.
white boxes in flow
White boxes represent request messages.
diagrams
shaded boxes in flow
Shaded boxes represent response messages.
diagrams
dotted line boxes in flow
Boxes with dotted lines illustrate advice messages.
diagrams
2 Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X System Documentation Descriptions
SYSTEM DOCUMENTATION DESCRIPTIONS
This two-volume book is part of the set of V.I.P. System documents. V.I.P. System Services,
Volume 1 and Volume 2, is designed to be a companion to the V.I.P. System Overview,
which has also been updated. The V.I.P. System Overview and V.I.P. System Services,
Volume 1 and Volume 2, contain new and updated information, and incorporate all system
changes and revisions described in the April 2013 VisaNet Business Enhancements Global
Technical Letters and Implementation Guides published after October 2012 through
April 2013. (See “Sources of System Information” in this chapter for a complete list of
sources used to prepare this V.I.P. System Services manual.)
The first three manuals in this series: V.I.P. System Overview, V.I.P. System Services,
Volume 1 and Volume 2, and V.I.P. System Reports, apply both to BASE I System
processing and to Single Message System (SMS) processing.
The next two manuals are specific to the BASE I System: V.I.P. System BASE I Processing
Specifications and V.I.P. System BASE I Technical Specifications, Volume 1 and Volume 2.
For the Single Message System (SMS), the Visa U.S.A. (U.S.) region processing
specifications for ATM, for Interlink, and for POS are consolidated in one manual,
V.I.P. System SMS Processing Specifications (U.S.). For the international audience,
About This Manual

there are separate processing specifications manuals for ATM and for POS.
Table 2 provides brief descriptions of the V.I.P. System manuals.
Table 2 Descriptions of V.I.P. System Manuals
General Information
V.I.P. System Overview
Provides basic descriptions of the VisaNet network and its components, access points, processing
concepts, requirements, and options. Contains descriptions of the V.I.P. System, the BASE I
System, and the Single Message System (SMS), VisaNet Access Points (VAPs), issuer and
acquirer responsibilities, and Visa Interchange Center (VIC) operations. Also provides a brief
introduction to V.I.P. services.
Doc ID 0851-22
V.I.P. System Reports
Provides sample reports for BASE I and SMS processing and for V.I.P. System services.
Doc ID 0852-22

Table 2 Descriptions of V.I.P. System Manuals (continued)

V.I.P. System Services, Volume 1
Provides complete information about V.I.P. System services available to BASE I users and to SMS
users. Service descriptions include basic information, processing requirements, options, features,
key message fields, and message flows.
Volume 1 contains the following parts:
Part 1: V.I.P. Basics

Part 2: Routing Services
Part 3: Risk Management Services
Part 4: Visa Secure Electronic Commerce (VSEC) Services
Part 5: Chip Card Services
Doc ID 0853A-22
Provides complete information about V.I.P. System services available to BASE I users and to SMS
users. Service descriptions include basic information, processing requirements, options, features,
key message fields, and message flows.
Volume 2 contains the following parts:

About This Manual
Part 6: Authorization Database Files and Services

Part 7: Authorization Services
Doc ID 0853B-22


BASE I
V.I.P. System BASE I Processing Specifications
Describes V.I.P. transaction processing in the BASE I System environment, including message
types, processing considerations, related services, and VisaNet Access Points (VAPs).
Doc ID 0847-22
V.I.P. System BASE I Technical Specifications, Volume 1
Documents technical specifications of V.I.P. transaction processing in the BASE I System

environment. This companion volume to V.I.P. System BASE I Processing Specifications describes
the fields for BASE I.
Doc ID 0844A-23
V.I.P. System BASE I Technical Specifications, Volume 2
Documents technical specifications of V.I.P. transaction processing in the BASE I System

environment. This companion volume to V.I.P. System BASE I Processing Specifications describes
the message formats and the file specifications for BASE I.
Doc ID 0844B-23
About This Manual

Interlink
V.I.P. System SMS Processing Specifications (U.S.)
Contains information about the Single Message System, including message types, processing
considerations, VisaNet Access Points (VAPs), and related services for Interlink, Visa and Plus
ATM, Visa POS, and Visa Electron.
Doc ID 0857-22
V.I.P. System SMS Interlink Technical Specifications
Companion volume to V.I.P. System SMS Processing Specifications (U.S.). Describes message
formats, field descriptions, and file specifications for Interlink.
Doc ID 0866-21
SMS ATM
considerations, VisaNet Access Points (VAPs), and related services for Visa and Plus ATM,
Interlink, Visa POS, and Visa Electron for members in the Visa U.S.A. (U.S.) region.
Doc ID 0857-22
V.I.P. System International SMS ATM Processing Specifications
Contains information about Single Message System ATM processing, including message types,
processing considerations, VisaNet Access Points (VAPs), and related services for members
outside of the U.S. region.
Doc ID 0839-22

X Sources of System Information

V.I.P. System SMS ATM Technical Specifications, Volume 1
Companion volume to V.I.P. System SMS Processing Specifications (U.S.) and to V.I.P. System
International SMS ATM Processing Specifications. Contains information about field descriptions
for ATM.
Doc ID 0868A-21
V.I.P. System SMS ATM Technical Specifications, Volume 2
International SMS ATM Processing Specifications. Contains information about message formats
and file specifications for ATM.
Doc ID 0868B-21
SMS POS
considerations, VisaNet Access Points (VAPs) and related services for Visa POS, Visa Electron,
Visa and Plus ATM, and Interlink for members in the U.S. region.
About This Manual
Doc ID 0857-22
V.I.P. System International SMS POS (Visa & Visa Electron) Processing Specifications
Contains information about Single Message System POS processing, including message
types, processing considerations, VisaNet Access Points (VAPs), related services, and reports
for members outside of the U.S. region.
Doc ID 0835-22
V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 1
International SMS POS (Visa & Visa Electron) Processing Specifications. Describes the fields
for Visa POS and for Visa Electron.
Doc ID 0869A-21
V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 2
International SMS POS (Visa & Visa Electron) Processing Specifications. Describes message
formats and file specifications for Visa POS and for Visa Electron.
Doc ID 0869B-21
SOURCES OF SYSTEM INFORMATION
This section lists the primary sources for the information contained in V.I.P. System
Services. The information from these sources has been analyzed, rewritten,
and reorganized, when necessary. Technical staff and subject matter experts reviewed and
verified these updates. In addition, this revised manual incorporates, where appropriate,
all of the comments and change requests received from members and from Visa staff.

X How To Use This Book
Existing V.I.P. System Manuals
For a list of the existing V.I.P. manuals, refer to Table 2.
VisaNet Business Enhancements Global Technical Letters and Implementation Guides
The V.I.P. System Services, Volume 1 and Volume 2, includes information from the
following technical letter and implementation guide: the April 2013 VisaNet Business
Enhancements Global Technical Letter and Implementation Guide, Version 3.0, effective
14 March 2013.
Other Documents
Other documents used as sources for V.I.P. System Services include the Visa International
Operating Regulations (and all revisions), RTN publications, general design documents,
detailed design documents, service advisories, and project presentations.
HOW TO USE THIS BOOK

This manual has seven parts, based on service functions, to help readers quickly find
information about available services that address specific needs.
About This Manual

Chapter Structure
Service description chapters appear in the part (V.I.P. Basics or Routing Services,
for instance) appropriate to their functions, as described in “Structure of This Manual” in this
chapter. With the exception of introduction and overview chapters, which appear first,
service chapters within each part are listed alphabetically.
Each service description chapter follows a standard structure, using the same section
headings to make finding information as easy as possible. A service description chapter
begins with a brief explanation of the service and then presents the following sections
of information.
Eligible Participants
This section contains text and icons (simple graphics) that identify which entities can use
the service. Icons indicate the following:
—The regions in which the service is available

There are icons for each of the five Visa regions and for Visa Europe. Each icon indicates
that the service is available to members in that region or in Visa Europe. The “ALL” icon
indicates that the service is available to members in all Visa regions and in Visa Europe.
Represents all Visa regions and Visa Europe

Represents the Asia-Pacific (AP) region
Represents the Visa Canada (CAN) region

NOTE
CA, but V.I.P. documentation refers to the
The V.I.P. System internally refers to the Visa Canada region as CA
CAN.
Visa Canada region as CAN
About This Manual
Represents the Central and Eastern Europe, Middle East, and Africa (CEMEA) region
Represents Visa Europe (VE)
Represents the Latin America and Caribbean (LAC) region

Represents the Visa U.S.A. (U.S.) region
—The system on which the service is available (BASE I, SMS, or both)
BASE I
SMS
BASE I only
BASE I
SMS
About This Manual

SMS only
BASE I
SMS
BASE I and SMS

—The type of member for which the service is available (issuer or acquirer)
Issuer
Acquirer
Service Summary
This section contains a complete description of the service and available options.
Participation Requirements
This section describes all prerequisites and requirements for participating in the service.
About This Manual
It provides specific information about:

• Testing.
• Service monitoring.
• Planning and implementation.
Related Messages
This section lists the message types that the service directly uses or that contain key
service fields.
How the [Service Name] Works
This section provides processing details specific to each service, including:

• Process flows, which provide a visual representation of the processing.
• Message flows, which illustrate the flows of messages and significant field information
from the message initiator through VisaNet to the message recipient.
In some cases, the process flow and the message flow are combined.
Key Fields Glossary
This section lists the fields that directly influence the processing of the service and gives a
short description of the fields and of their contents.
For More Information
This section lists other publications that provide additional information about the service.

Interpreting Flow Diagrams
The process and message flow diagrams in each service chapter illustrate the path that
messages take from the originator of the message to the message recipient. Figure 1
shows a sample flow.
• Icons at the top of the illustration show the destinations of the message (acquirer, V.I.P.,
issuer, merchant, network, vendor).
• Arrows indicate the entity that creates the message and the entity that receives it
(acquirer, V.I.P., issuer, merchant, network, vendor).
Boxes list key message fields and specific field values contained in the messages,
as appropriate.
• White boxes represent request messages. Shaded boxes represent response messages.
• Boxes with dotted lines illustrate advice messages. The arrows between the boxes
indicate the creator and the path of the advice messages.
NOTE
V.I.P. typically creates advice messages for issuers to let them know that it performed processing on
their behalf.
About This Manual

In Figure 1, the acquirer creates the request message and sends it to the V.I.P. System
within VisaNet. V.I.P. processes the message and, as indicated by the next arrow,
sends the message to the issuer for processing.
The issuer creates a response message and sends it to V.I.P. for processing. V.I.P.
performs its functions on the response message and sends it to the acquirer.
For the purposes of illustrating an advice flow, Figure 1 shows that V.I.P. creates an
advice message for the issuer to recover. When the issuer receives the advice, the issuer
responds with an advice response message.

X Obtaining Report Samples
NOTE
Responding to some advices is optional. For other advices, a response is mandatory.
Figure 1 Sample Message Flow
Acquirer V.I.P. Issuer
0100 Request 0100 Request 0100 Request
0110 Response 0110 Response 0110 Response

About This Manual
0x2x Advice 0x2x Advice
0x3x Advice Response 0x3x Advice Response
NOTE
In actual service chapters, each message flow indicates key fields, as appropriate.
OBTAINING REPORT SAMPLES
Visa offers several reports to members. Many of these reports clarify and track service
processing. The following manuals provide report samples:
• V.I.P. System Reports
• VisaNet Settlement Service (VSS) User's Guide, Volume 2, Reports
Members can contact their Visa representatives to discuss reporting options or to obtain
additional report samples.

X For More Information
FOR MORE INFORMATION
Visa provides documentation to support Visa products and services. For many of the
services described in this manual, Visa has developed implementation guides that contain
region-specific details about signing up for a service, selecting options, and installing,
testing, and operating the service. Members can ask their Visa representatives for regional
guides.
The V.I.P. documentation suite does not contain details about the BASE II System.
For information about this system, members can contact their Visa representatives.
Related Publications
The publications listed in this section provide information about Visa systems, regulations,
and additional services not covered in this manual. If you have technical questions or
questions regarding a Visa service or capability, contact your Visa representative.
Use the following information to obtain any of the listed publications, to be added to or
removed from distribution lists, or to inquire about other publications.
• U.S. members and third-party processors can contact Publication Orders by sending
an email to publicationorders@visa.com.
About This Manual

• Members and third-party processors in all other Visa regions or in Miami can contact
their Visa representatives.
If you have comments or questions about this document, send them to TCS@visa.com.
Operating Regulations
The operating regulations are contained in the Visa International Operating Regulations
(VIOR).
Qualifying merchants and third-party agents can also request a copy of the Interchange
Qualification Guide.
PIN Management Requirements
For complete, current information about PIN management requirements, refer to:
Payment Card Industry PIN Security Requirements Manual—This manual contains

requirements for the secure management, processing, and transmission of personal
identification number (PIN) data during online and offline payment card transaction
processing at ATMs and at attended and unattended terminals.
PIN-Entry Device Security Requirements—The following manuals contain physical and

logical security device requirements and management procedures for online and offline
PIN-entry devices and the procedures and forms that entities use to measure compliance:
• Payment Card Industry Encrypting PIN PAD (EPP) Security Requirements Manual
• Payment Card Industry POS PIN-Entry Device Security Requirements Manual
POS Check Service
For information about the POS Check Service, refer to:

Visa U.S.A. POS Check Service Operating Regulations
V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 1 and
Volume 2
VisaNet Settlement Service (VSS) User's Guide, Volume 2, Reports
Risk Management Services
For information about risk management services, refer to:
Card Recovery Bulletin Service User's Guide
Fraud Reporting System (FRS) User's Guide
Issuer's Clearinghouse Service User's Guide
Merchant Fraud Performance Program Guide
Risk Management Process Guide

About This Manual
Visa Risk Manager
Security
For complete, current information about data and system security, refer to:
Payment Technology Standards Manual—This manual contains standards for PINs

and for encoding account and cardholder data on Visa payment form factors.
Visa Extended Access Servers (EA Servers)
For information about Visa Extended Access Servers (EA Servers), refer to:
Extended Access Administration and Installation Guide
Visa Extended Access Server Endpoint Guide
Extended Access Management Installation Guide
Extended Access Management Operators Guide
Extended Access Security Administration Guide
Extended Access Server Endpoint Guide
Visa Incentive Network (VIN)
For information about the Visa Incentive Network (VIN), refer to:
Visa Incentive Network Service Description—(This is a high-level overview and is not the
same as the V.I.P. System Services descriptions.)
Visa Incentive Network Member Implementation Guide

Credit Rewards Key Implementation Tasks and Best Practices
Credit Rewards: Visa Incentive Network and Credit Interchange Frequently Asked
Questions
October 2005 VisaNet Business Enhancements Technical Letter, updated version 3.0,
dated September 15, 2005
Visa Traditional Rewards Registration Toolkit
Visa Signature Registration Toolkit
Visa Resolve Online (VROL)
For information about Visa Resolve Online (VROL), refer to:
Visa Resolve Online Administrator's Guide
Visa Resolve Online Bulk Systems Interface Development Guide
Visa Resolve Online Member Implementation Guide
Visa Resolve Online Real-Time Systems Interface Development Guide
About This Manual

Visa Resolve Online Reference Manual
Visa Resolve Online User's Guide
Visa Smart Debit/Smart Credit (VSDC) Service
For information about the VSDC Service, refer to:
JCB, MasterCard, Visa (EMV) Specifications, EMV '96 Version 3.1.1 and EMV 2000
Version 4.0—These documents contain industry standards for chip card and terminal
interaction. They are available at www.emvco.com.
Visa Smart Debit and Visa Smart Credit Service Description—This manual provides a
high-level description of the features and the benefits of a VSDC program.
Visa Smart Debit and Credit Planning Guide—This manual helps members plan their VSDC
program and migration strategy to position themselves competitively for the future.
Visa Smart Debit and Credit Member Implementation Guide for Acquirers—This manual
provides guidelines for acquirers involved in the implementation of new VSDC programs.
Visa Smart Debit and Credit Member Implementation Guide for Issuers—This manual
provides guidelines for issuers involved in the implementation of new VSDC programs.
Visa Smart Debit/Visa Smart Credit System Technical Manual—This manual provides
information for members and for Visa staff responsible for the implementation and the
operation of a VSDC program.
Visa Integrated Circuit Card Specifications (VIS)—This 3-volume manual contains the
technical specifications for the VSDC card application, describing both the functionality and
the flow of a VSDC transaction.

Miscellaneous Systems and Services
For more information about miscellaneous systems and services relevant to V.I.P., refer to:
Credit Gateway Service Cross-Reference Guide—This document includes field-by-field

data transfer descriptions between V.I.P.-format dual-message transactions, and American
Express- and MasterCard-format transactions.
Visa Global ATM Planning Guide—This manual contains information about the Visa and
Plus International ATM Program. It includes an overview of the program, its business
requirements, optional services, risk management, processing options, testing procedures,
and back-office management.
Visa Information System User's Guide
Visa Test System—V.I.P. User's Guide
VisaNet Settlement Service (VSS) User's Guide, Volume 1, Specifications
VisaNet Settlement Service (VSS) User's Guide, Volume 2, Reports

About This Manual

Part 1 V.I.P. Basics
Part 1, V.I.P. Basics, provides background information about the services available through
the V.I.P. System. Readers unfamiliar with V.I.P. services and VisaNet processing should
review the chapters in this part before reading the service description chapters.
Part 1 contains the following chapters:
Services—This chapter describes the scope of this manual

Chapter 1, Introduction to V.I.P. Services—
and the criteria used to determine which services it documents. It includes general
information about signing up for a service and testing for service participation.
Fundamentals—This chapter contains an overview of VisaNet

Chapter 2, V.I.P. System Fundamentals—
(the Visa transaction processing network), the V.I.P. System, and transaction processing.


Chapter 1 Introduction to System Services
MANUAL.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-
SERVICES NOT DESCRIBED IN THIS MANUAL 1-33
SERVICES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-
HOW THE SYSTEM PERFORMS SERVICES 1-33
SERVICE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-
HOW TO SIGN UP FOR A SERVICE 1-55
Introduction to System Services

Enrollment Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
IMPLEMENTATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-
HOW TO PREPARE FOR SERVICE IMPLEMENTATION 1-55
Testing With Visa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5
For More Information About the VisaNet Certification Management
Service (VCMS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 1-1

1-2 Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

Chapter 1 Introduction to System Services
The V.I.P. System provides many services for members. For the purposes of this
manual, a service is defined as software or as options that add to the basic V.I.P. System
functionality.
This 1 June 2013 edition of V.I.P. System Services includes service descriptions for the
majority of services available to BASE I System users and to Single Message System

(SMS) users.
1.1 SERVICES NOT DESCRIBED IN THIS MANUAL

This manual does not include information about the following types of services:
• Basic V.I.P. System services

These services are those that are integral to V.I.P. processing and are available upon
access to VisaNet. For instance, this manual does not discuss reversal processing
because this service is fundamental to V.I.P. processing. Refer to Chapter 2, System
Fundamentals, for information about basic V.I.P. processing.
• VisaNet Access Points (VAPs)

VAPs are described in detail in the VisaNet Access Point (VAP) documentation suite and
in the Visa Extended Access Server documentation suite. Refer to “For More Information”
in About This Manual for a partial list of available documents.
• Stand-In Processing (STIP)

Chapter 2, System Fundamentals, briefly describes STIP services. The Positive
Authorization Capacity Management (PACM) Service chapter and the Positive
Cardholder Authorization Service (PCAS) chapter, both in Volume 2 of this manual,
describe STIP processing in more detail. The V.I.P. processing specifications and
technical specifications manuals contain full details of STIP processing. Refer to
“For More Information” in About This Manual for a list of processing specifications
manuals and technical specifications manuals.
• Settlement and Reporting

This manual does not describe settlement and reporting services, including BASE II
System clearing and VisaNet Settlement Service (VSS) settlement processing. Refer to
“For More Information” in About This Manual for a list of available documents describing
these services.
1.2 HOW THE SYSTEM PERFORMS SERVICES

Members control much of V.I.P. service processing by providing information and processing
parameters to the V.I.P. System. Members provide information to V.I.P. in two ways:
Selections—Members provide data, optional selections,

Member Processing Selections—
and processing limits to the V.I.P. System to enable V.I.P. to provide the services selected
by the members. V.I.P. stores the parameters submitted by each member in databases

Chapter 1 How the System Performs Services
called system tables. V.I.P. checks the data in these tables to determine the type of
processing the member requests and the parameters and limits to use for processing.
Refer to “Processing Parameters” in Chapter 2, System Fundamentals, for an overview of
system tables.
Content—Additionally, V.I.P. compares message content to member processing

Message Content—
selections in the system tables and processes messages according to available information
and to established priorities. For instance, V.I.P. checks the message type and the network
code when determining the processing requested by the member.
Typically, certain standard message types apply to particular services. Where possible,
each chapter lists the messages related to a specific service. For instance, the following
messages pertain to the Address Verification Service (AVS):
Request—An 0100 authorization request message can include the

0100: Authorization Request—
address verification request information. Acquirers can also use 0100 messages for
address verification-only requests. V.I.P. and issuers respond to acquirers' request
messages with 0110 authorization response messages.
NOTE
When V.I.P. receives an AVS-only account verification request destined for a U.K. issuer that is directly
connected to Visa Europe Authorisation Services, V.I.P. forwards the request to Visa Europe Authorisation
Services, which determines whether the request is to be processed by its stand-in processing system or
forwarded to the issuer.
Response—V.I.P. and issuers send 0110 authorization response

0110: Authorization Response—
messages in response to acquirers' 0100 request messages. The 0110 responses contain
the code indicating the result of the address verification in Field 44.2—Address Verification
Result Code and the authorization response code in Field 39—Response Code.
Advice—An 0120 advice notifies issuers when V.I.P. stand-in processing (STIP)
0120: Advice—
processes an address verification request on their behalf. If the address verification request
includes an authorization, field 39 contains the authorization response. Field 44.2 contains
the address verification results. If the request does not include authorization, only the
address verification result code appears.
Request—An 0200 financial request can include the address verification

0200: Financial Request—
request information. Acquirers can also use 0200 messages for address-verification-only
requests. V.I.P. and issuers send 0210 response messages to acquirers.
Response—V.I.P. and issuers send 0210 financial response

0210: Financial Transaction Response—
messages in response to 0200 financial request messages. An 0210 response message
contains the verification result code in field 44.2 and the authorization response code in
Field 38—Authorization Identification Response or in field 39.
Advice—An 0220 advice notifies issuers when STIP processes address verification
0220: Advice—
requests on their behalf. V.I.P. sends 0220 advices to issuers and to acquirers when
V.I.P. performs address verification for 0200 request messages. If the address verification
request includes authorization, field 39 contains the authorization response. Field 44.2
contains the address verification results. If the request does not include authorization,
only the address verification result code appears.

Chapter 1 How To Sign Up for a Service
Advice—An 0420 advice notifies acquirers when V.I.P. sends an 0400 reversal to
0420: Advice—
the issuer because the acquirer is unavailable to receive an 0210 response. If the 0210
response includes authorization, field 39 contains the authorization response. Field 44.2
contains the address verification results. If the request does not include authorization,
only the address verification result code appears.
Some services do not have specific, related messages. A “Key Fields Glossary” appears at
the end of each service chapter and contains detailed information about the key message
fields and about their contents.
1.3 HOW TO SIGN UP FOR A SERVICE

Most of the services described in this manual are optional. Members can subscribe to
optional V.I.P. services:
• During the member's initial installation of VisaNet access.
• Anytime after the member's initial implementation.
Some services are mandatory for all members or for members in specific Visa regions.
The Eligible Participants section in each service chapter contains this information.
To participate in services described in this manual, members can contact their Visa
representatives, who coordinate service participation.
1.3.1 Enrollment Process

Enrollment processes differ for each region. Visa representatives can explain the
requirements and enrollment specifics.
1.4 HOW TO PREPARE FOR SERVICE IMPLEMENTATION

Before any service implementation, each member must test its systems and, in many
cases, test with Visa to implement the service.
1.4.1 Testing With Visa

The VisaNet Certification Management Service (VCMS) provides test systems that enable
members to test for most V.I.P. service requirements and to test with Visa to process
transactions through VisaNet.
VCMS:
• Improves member readiness for transaction processing.
• Facilitates implementation of new services for members.
• Provides end-to-end and transaction life-cycle testing for Custom Payment Service
(CPS)/ATM and Custom Payment Service (CPS)/POS.
• Reduces the risk of incorrect processing in authorization and clearing production systems
both for Visa and for the membership.
Testing is a process in which members use specially designed test cases to verify the
integrity of their systems connected to VisaNet. The test cases are specific for each Visa
service. Members perform testing using the Member Testing System test environment that
simulates (as closely as possible) the production environment.
Testing is a process in which Visa monitors tests to verify that members can successfully
perform specific transaction processing requirements. The Visa International Operating
Regulations list these requirements. Once successfully tested, members are ready for
service activation.

Chapter 1 How To Prepare for Service Implementation
IMPORTANT
Successful testing by Visa does not imply that Visa has tested a member's overall system or processes.
Visa recommends that the following members test before service activation:
• All new members
• Members participating in new services
• Members activating enhancements of existing services
• Members that have made any type of change to their systems
Members that want to participate in testing by VCMS for specific services can contact
their Visa representatives; they make the necessary arrangements for testing, monitoring,
and implementation.
1.4.1.1 For More Information About the VisaNet Certification Management Service (VCMS)
For further information about VCMS, refer to the following documents:
• VisaNet Certification Management Service Testing and Certification Guide—V.I.P.
System, Member Version
• VisaNet Certification Management Service User's Manual—BASE II System
1.4.2 Service Monitoring

Visa may monitor transactions for a specified period when members access VisaNet for
the first time and when they select certain new services. This monitoring ensures that the
member is connected properly and is processing all messages correctly.
Each service description specifies monitoring requirements, if applicable. Members can

contact their Visa representatives if they have questions about monitoring.

Chapter 2 System Fundamentals
OVERVIEW.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
VISANET OVERVIEW 2-33
FLOW.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
VISANET PROCESS FLOW 2-55
SYSTEMS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
VISANET SYSTEMS 2-55
VisaNet Integrated Payment (V.I.P.) System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5
BASE I System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6
Single Message System (SMS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-6
BASE II System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
VisaNet Settlement Service (VSS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
THE COMMON MEMBER INTERFACE (CMI) AND OTHER INTERFACE

2-10
METHODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2- 10
System Fundamentals
PARAMETERS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
PROCESSING PARAMETERS 2-11
11
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
SYSTEM MESSAGES 2-12
12
Message Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13
Message Flow Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18
EDITING.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
MESSAGE EDITING 2-19
19
BASICS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
MESSAGE ROUTING BASICS 2-19
19
Routing Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19
Routing Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-20
Internal Routing Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21
Gateways to Non-VisaNet Destinations. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .2-21
(STIP).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
STAND-IN PROCESSING (STIP) 2-22
22
BASE I STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22
SMS STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-23
TRANSACTIONS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
AUTO-SUBSTANTIATION TRANSACTIONS 2-24
24
REWARDS.. . . . . . . . . . . . . . . . . . . . .2-
ACCOUNT-LEVEL PROGRAMS AND CARDHOLDER REWARDS 2-25
25
INQUIRIES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
HEALTHCARE ELIGIBILITY INQUIRIES 2-25
25
PROCESSING.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
MASTERCARD PROCESSING 2-26
26
Routing Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-26
Visa Services and Functions Available for MasterCard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-27
SERVICE.. . . . . . . . . . . . . . . . . . . . . . . . . . .2-
U.S. ACCOUNT UPDATER VERIFICATION (VAU) SERVICE 2-28
28

Chapter 2
(TAP).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
TRUSTED AGENT PROGRAM (TAP) 2-29
29
INQUIRIES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
VISA PRODUCT ELIGIBILITY INQUIRIES 2-29
29
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-
FOR MORE INFORMATION 2-30
30
System Fundamentals

Chapter 2 System Fundamentals
Understanding the interaction between the V.I.P. System and the various services that the
system provides requires a basic understanding of VisaNet and of its components. VisaNet
components include the V.I.P. System, user processing options, transaction processing,
messages, and routing principles.
This chapter contains a brief description of the Visa processing network and its major
systems, along with an overview of system messages and transaction processing.
This information provides a groundwork for understanding the service descriptions in this
manual.
For a complete overview of VisaNet and of the V.I.P. System and its components, see the
V.I.P. System Overview.
2.1 VISANET OVERVIEW

VisaNet is the Visa financial transaction processing network, the structure that supports
transactions routed among acquirers and issuers in all Visa regions. The term VisaNet
System Fundamentals
applies to the network’s hardware, software, and communications components and
facilities, as well as to member regional systems and networks.
The main components of VisaNet are:

• VisaNet Interchange Centers (VICs).
• VisaNet communications network.
• VisaNet Access Points (VAPs), such as Direct Exchange (DEX) and Visa Extended
Access Servers (EA Servers).
NOTE
Members in the Visa U.S.A. (U.S.) region connect to VisaNet through Direct Exchange (DEX). Members in
all other Visa regions connect to VisaNet through DEX or EA Servers.
• Processing centers.
(VICs)—A VIC is a Visa data processing center. Each VIC
VisaNet Interchange Centers (VICs)—
houses the computer systems that perform all VisaNet transaction processing and serves
as the control point for the telecommunications facilities of the VisaNet communications
network. Members access VisaNet from the closest VIC. If one VIC experiences system
disturbances that interrupt system processing, VisaNet automatically routes members'
transactions to another VIC, ensuring continuity of service.
Network—Visa operates telecommunications lines and facilities

VisaNet Communications Network—
worldwide to link all system users to the VICs and thus to each other. Most links in the
VisaNet communications network are high-speed leased lines; other links use satellite
connections.
Almost all communication is based on IBM SNA and TCP/IP conventions and protocols.
(VAPs)—Visa provides access devices for connecting to VisaNet.

VisaNet Access Points (VAPs)—
These VisaNet Access Points (VAPs) enable members to connect to VisaNet for

Chapter 2 VisaNet Overview
transaction processing. A VAP provides the interface between the systems at the VIC and
the processing center's host computer. A VAP can connect the member to the BASE I and
BASE II dual-message systems, to SMS, or to all three systems. VAP types include:
• Visa Extended Access Servers (EA Servers)
EA Servers use open systems technology and a Linux or hardened Solaris operating
system. EA Servers sit at participating endpoint sites. The servers perform authorization
routing, file staging, and delivery services, and provide secure connectivity to VisaNet.
• Direct Exchange (DEX)®

The Visa Direct Exchange (DEX) network provides members a single network connection
for all message processing and �le delivery services.
The network has two major components:
- The Visa Message Gateway, which handles online transaction processing, resides at
the VIC, and supports all V.I.P. messages. The Visa Message Gateway operates as
a routing “switch” for all V.I.P. transactions processed through it, controls the �ow of
traffic between endpoints and the VIC, and provides end-to-end BASE I and SMS
online processing.
- The Open File Delivery (OFD) Service, which handles report and �le delivery, including
System Fundamentals
the delivery of Automated Clearing House (ACH) data, BASE II data, and various
SMS reports and raw data.
Members can choose additional options for receiving reports and raw data, and for routing
files.
Options vary by region. Members can contact their Visa representatives for information
about available VAP options.
Refer to “For More Information” in About This Manual for documentation about VAPs.
Centers—A processing center, often called a processor, is a data processing

Processing Centers—
facility operated by or designated by an issuer or an acquirer. The processing center
houses card processing systems that support merchant and business locations, maintain
cardholder data and billing systems, or both. Each processing center host computer that
communicates with a VAP must run a computer interface to the VAP. Visa must test this
interface before the member or the processor can connect the VAP to VisaNet.
Figure 2-1 illustrates the VisaNet network.
Figure 2-1 The VisaNet Communications Network
VisaNet
Acquirer VisaNet Access Point (VAP) VisaNet Access Point (VAP) Issuer

Chapter 2 VisaNet Process Flow
2.2 VISANET PROCESS FLOW

The basic communications flow in the VisaNet network begins from the originating
processing center to the VIC and then proceeds to the destination processing center. This
transaction path provides optimum message control and enables VisaNet systems to
perform stand-in processing (STIP) services on behalf of system users.
Each message sent from one processing center to another is transmitted as follows:
1. The processing center originating the message sends it to the VIC.
2. VisaNet systems at the VIC process the transaction according to the transaction type
and to member specifications.
3. VisaNet systems at the VIC transmit the message to the destination processing center.
Figure 2-2 illustrates the basic process flow of the request and response messages used to
process cardholder transactions.
Figure 2-2 VisaNet Basic Process Flow
System Fundamentals
Merchant VisaNet
or
ATM
Acquirer Issuer
Request
Response
2.3 VISANET SYSTEMS

There are three main transaction processing systems within VisaNet that provide online
and offline transaction processing:
• The VisaNet Integrated Payment (V.I.P.) System, which includes:
- The BASE I System
- The Single Message System (SMS)
• The BASE II System
• The VisaNet Settlement Service (VSS)
The following subsections describe each of these VisaNet systems.
2.3.1 VisaNet Integrated Payment (V.I.P.) System

The V.I.P. System is the primary online transaction routing (switching) and processing
system for all online authorization and financial request transactions that enter VisaNet.

Chapter 2 VisaNet Systems
The system provides the V.I.P. services described in this manual to members and to other
users worldwide.
V.I.P. has one system that supports dual-message processing (members request
authorization of transactions in a first message, then send financial clearing information
in a second message), and another system that supports single-message processing
(the processing of interchange card transactions that contain both authorization and
clearing information in a single message). In both cases, settlement occurs separately.
2.3.2 BASE I System

BASE I is the component of the V.I.P. System that processes authorization-only request
messages online. Authorization request messages are the first messages sent in
dual-message processing. (BASE II clearing messages are the second messages sent in
dual-message processing.)
The BASE I component of the V.I.P. System supports online functions, offline functions,
and the BASE I files. BASE I files include the internal system tables and the Merchant
Central File (MCF).
Refer to “V.I.P. Processing Parameters” in this chapter for an overview of system tables.
Refer to Part 6, Authorization Database Files and Services, in Volume 2 of this manual for
System Fundamentals
information about the Merchant Central File.
Functions—The BASE I online functions support dual-message authorization

BASE I Online Functions—
processing. BASE I online processing involves routing, cardholder and card verification,
and stand-in processing (STIP), plus related functions, such as Card Verification Value
(CVV) validation, PIN verification, and file maintenance.
NOTE
BASE I processes U.S. domestic Interlink-acquired transactions if the account range is set up to accept
PIN-authenticated POS transactions.
A bridge from BASE I to SMS makes it possible for BASE I members to communicate with
SMS members and to access the SMS gateways to outside networks.
Refer to Chapter 6, Gateway Services, for information about networks supported by

Gateway Services.
Functions—The BASE I offline functions include BASE I reporting and

BASE I Offline Functions—
the generation of Visa Card Recovery Bulletins. BASE I reporting includes authorization
reports, Exception File and Advice File reports, and POS reports. For information about
BASE I offline functions, refer to V.I.P. System BASE I Processing Specifications and to
V.I.P. System BASE I Technical Specifications, Volume 1 and Volume 2.
2.3.3 Single Message System (SMS)

The Single Message System (SMS) component of the V.I.P. System processes full financial
transactions. Full financial transactions contain both authorization and clearing information.
Because one message contains both the authorization and clearing information, this form of
processing is referred to as single-message processing. SMS also supports dual-message
processing (participants submit an authorization request as a first message, then send
clearing and settlement in a second financial request message), communicating with

BASE I, and accessing outside networks, as required, to complete transaction processing.

Only the SMS component performs single-message processing.
A bridge from SMS to BASE I makes it possible for SMS users to communicate with BASE I
users and to access the BASE I gateways to outside networks.
Refer to Chapter 6, Gateway Services, for information about networks supported by

Gateway Services.
SMS supports online functions, offline functions, and SMS files. SMS files consist of
internal system tables that control system access and processing. SMS also supports the
Merchant Central File for SMS members in the U.S. region.
Functions—The SMS online functions perform real-time cardholder transaction

SMS Online Functions—
processing and exception processing. This processing supports authorization and full
financial transactions. In addition, SMS supports the delivery of transactions to the BASE II
System for members that use dual-message processing.
SMS also accumulates reconciliation totals, performs activity reporting, and passes activity
data to VisaNet, which supports settlement and funds transfer processing for SMS. VisaNet
handles settlement and funds transfer as an automatic follow-up to SMS transaction
System Fundamentals
processing. The VisaNet Settlement Service (VSS) performs settlement as a separate
process and delivers its results through advices and reports. For an illustration of the
relationship of VSS to SMS and to BASE II, see “VisaNet Settlement Service (VSS)”
in this chapter.
Both the BASE I component and the SMS component use files of member-supplied
cardholder data and processing parameters to perform online processing. Both systems
interact with several offline systems, including BASE II and exception processing systems.
SMS processes Visa, Plus, Interlink, and other card transactions.
Issuers can choose to have all of their transactions processed by SMS or can use BASE I
and BASE II, as well as SMS, to process their transactions. Issuers can also choose to use
different processing methods for different Visa products.
Functions—The SMS offline systems process settlement and funds transfer

SMS Offline Functions—
requests and provide settlement and activity reporting. (SMS members may also receive
the BASE I reports mentioned in “BASE I Offline functions” in this chapter.) The offline
systems also support an offline bridge to and from BASE II for those Visa and Plus clearing
transactions that VisaNet sends between an SMS member and a BASE II member.
NOTE
SMS access points must use the V.I.P. International Organization for Standardization (ISO) message format
and must observe all rules for its use.
2.3.4 BASE II System

The BASE II System is an international electronic batch transaction clearing system that
facilitates the exchange of interchange data between acquirers and issuers. The system
calculates interchange fees between members.

BASE II performs the second part of dual-message processing. Through a BASE I or SMS
connection, members submit authorization messages, which V.I.P. clears through a
VisaNet connection to BASE II. A bridge to the V.I.P. System permits interchange between
BASE II processing centers and SMS processing centers.
NOTE
This manual does not provide details about BASE II. For information about this system, members can contact
Settlement occurs through VSS. BASE II passes message data to VSS, which settles with
the issuer and with the acquirer. For information about VSS, see “VisaNet Settlement
Service (VSS)” in this chapter.
The following figure illustrates where V.I.P. and its software system components, along with
BASE II, reside in the VisaNet network.
Figure 2-3 The VisaNet Software System Components

System Fundamentals
VisaNet
V.I.P. System BASE II System
BASE I
SMS
Visa members and processors that use BASE I and BASE II may choose to use SMS to
process some of their transactions, or may choose to use different processing methods for
different transaction types.
EXAMPLE
An issuer can use BASE I and BASE II processing for POS transactions and use SMS processing for ATM
transactions.
2.3.5 VisaNet Settlement Service (VSS)

VisaNet processes interchange transactions for SMS and for BASE II through separate
systems. Both SMS and BASE II perform their own clearing functions. Clearing is the

process of collecting an individual transaction from one member or processor and delivering
it to another. Clearing also includes valuation, the calculation of many types of fees and
charges. Once the systems clear transactions, they are ready for settlement. Settlement
has two components: The first component is the process of calculating and determining
the net financial position of each member for all the transactions cleared by VisaNet. The
second component is the process during which actual exchange of funds takes place.
The VisaNet Settlement Service (VSS) consolidates the settlement functions of SMS and
BASE II, including Interlink and Plus, into a single service for all products and services.
VisaNet sends the settlement information to members and processors from SMS and
from BASE II in a standardized set of reports. VSS provides flexibility in defining financial
relationships, in selecting reports and report destinations, and in establishing funds transfer
points.
Figure 2-4 illustrates the VSS clearing and settlement process.
Figure 2-4 VisaNet Settlement Service (VSS) Process
System Fundamentals
BASE II Clearing SMS Clearing
SMS Reports
VisaNet Settlement Service
Funds Transfer
Settlement Reports

Chapter 2 The Common Member Interface (CMI) and Other
Interface Methods
2.4 THE COMMON MEMBER INTERFACE (CMI) AND OTHER INTERFACE

METHODS
The Common Member Interface (CMI) is an interface method that allows members and
processing centers to use the same communications line to send and to receive BASE I
and SMS messages. The communications line from a VisaNet access point, or station,
to V.I.P. connects at the CMI at the VIC.
NOTE
Members establish processing and routing parameters for their stations in the system tables through the
Customer Online Repository (CORE). Members can contact their Visa representatives to establish or to
change their CORE settings.
The CMI accepts messages in all valid message formats. Functions of the CMI include
basic editing as well as routing.
With the CMI, any BASE I processing center, including those that use both BASE I and
SMS, can send BASE I messages. Any SMS processing center, including those that
use both SMS and BASE I, can send SMS messages. The CMI chooses the appropriate
system based on the source of the request, on the type of processing requested, and on
System Fundamentals
the processing network in cases when the message specifies a network.
Besides the CMI, other interface methods are available to members and to processing
centers. These methods allow members and processing centers to communicate with only
one component of V.I.P.—with BASE I or with SMS but not with both.

Chapter 2 Processing Parameters
The following figure illustrates the V.I.P. system software components. In the example,
the processing center uses a single system for both BASE I processing and SMS
processing.
Figure 2-5 V.I.P. System Software at the VIC and at the Processing Center
VIC
BASE I
V.I.P. System SMS
Offline Offline
Systems BASE I SMS Systems
Online Online
Component Component
BASE I Files SMS Files

Common Member Interface (CMI)
System Fundamentals
Processing Center
VisaNet Access Point V.I.P. Subsystem

(VAP)
Processing Center Host
2.5 PROCESSING PARAMETERS

Members and system users control both BASE I and SMS processing primarily by selecting
options and by establishing limits and parameters. V.I.P. executes the majority of system
functions according to parameters that users select. Most V.I.P. services offer users many
options for implementing and for operating the service.
Some services allow users to choose different options by BIN (that is, by a specific range of
card numbers for a specific card program). Other options apply to all messages processed
by a given processing center. Additional options enable individual stations at processing
centers to handle specific types of transactions. V.I.P. also has the ability for issuers in

Chapter 2 System Messages
Visa Canada and in the U.S. region to link incentive and rewards programs with consumer
card products at the card account level.
V.I.P. maintains records of routing and processing rules that apply to BINs, to processing
centers, and to stations. V.I.P. stores these parameters in the system tables (also called
the system globals or system files). Typically, multiple BINs point to a single processing
center. Users change their parameters as needed to reflect business changes.
V.I.P. also keeps records of the following relationships:

• Issuers to account numbers
• Issuers and acquirers to processing centers
• Processing centers to VICs
• Processing centers to network stations
Users report any changes in account number ranges or in processing center designations
to Visa. This information is vital to the correct routing of messages.
2.6 SYSTEM MESSAGES

Information passes between members and V.I.P. in the form of BASE I and SMS messages.
Both BASE I and SMS messages are Visa variations of the International Organization for
Standardization (ISO) 8583 message, the international standard for the format of financial
System Fundamentals
messages. Each message includes:

• Bitmaps that specify the data fields that appear in the message.
• A message type identifier.
• Only those fields that VisaNet needs for the specific function intended.
NOTE
V.I.P. assigns a transaction identifier (TID) to all POS and ATM dual- and single- message transactions,
including preauthorization messages, Plus transactions, and fee collection and funds disbursement messages.
V.I.P. checks each message for validity and edits messages as required. The CMI performs
message format conversion, if necessary.
Maintaining message integrity—correctness and completeness—is critical to V.I.P.

processing. Message integrity assures participants that all other participants have followed
Visa processing rules and that a participant has acted on a message or on a transaction as
defined in the V.I.P. documentation suite and in Visa International Operating Regulations
(VIOR). For instance, V.I.P. preserves message integrity by evaluating:
• Duplicate messages
• Message sequence
• Message consistency
V.I.P. identifies key data elements used to maintain and preserve message integrity.
These key tracing elements include:
• Acquiring institution ID
• Card acceptor identification code
• Card acceptor terminal identification
• Network identification code
• Original data elements (including the original message type identifier)
• Retrieval reference number

• System audit trace number

• Transaction identifier (TID)
IMPORTANT
Throughout the V.I.P. documentation suite, the term mandatory refers to a member requirement and means
that a field must be present in a message and must contain certain values. Conditional refers to a member
requirement that applies under specified conditions. While the V.I.P. System enforces edits and rejects
transactions for some violations of mandatory requirements, V.I.P. does not enforce edits for all mandatory or
conditional fields and values.
Visa strongly urges members and their processors to comply with mandatory field requirements. Failure to
do so can result in greater risk to the member or in increased processing cost, and can result in exposure
to chargebacks and compliance claims, elevated decline rates, and disqualification for preferential interchange
rates. Visa also advises members not to rely on the V.I.P. System to reject all transactions that do not
comply with mandatory or conditional requirements.
All participants keep track of incoming and outgoing messages.
2.6.1 Message Types

Table lists the message types V.I.P. supports.
NOTE
Message support varies by region. Not all listed messages are available in all regions.
System Fundamentals
Table 2-1 Message Types Supported by V.I.P.
BASE I Messages SMS Messages

0100 Authorization or Verification Request 0100 Authorization Request
0100 Preauthorization Request 0100 Preauthorization Request
0100 Credit Voucher and Merchandise 0100 Credit Voucher and Merchandise Return
Return Authorization Request Authorization Request
0100 Healthcare Auto-Substantiation 0100 Healthcare Auto-Substantiation Request
Request
0100 Incremental Authorization Request 0100 Incremental Authorization Request
0100 Money Transfer Original Credit
Authorization Request
0100 Prepaid Activation Request 0100 Prepaid Activation Request
0100 Prepaid Load Request 0100 Prepaid Load Request
0100 Prepaid Activation and Load Request 0100 Prepaid Activation and Load Request
0100 Prepaid Partial Activation and Load 0100 Preauthorization Request
Request
0100 Balance Inquiry Request
01011 Repeat 01012 Repeat
0110 Authorization or Verification 0110 Authorization Response
Response
0110 Preauthorization Response 0110 Preauthorization Response
Return Authorization Response Authorization Response

Table 2-1 Message Types Supported by V.I.P. (continued)

0110 Healthcare Auto-Substantiation 0110 Healthcare Auto-Substantiation Response
Response
0110 Incremental Authorization Response 0110 Incremental Authorization Response
0110 Authorization Response with File
Update
0110 Prepaid Activation Response 0110 Prepaid Activation Response
0110 Prepaid Load Response 0110 Prepaid Load Response
0110 Prepaid Activation and Load 0110 Prepaid Activation and Load Response
Response
0110 Prepaid Partial Authorization 0110 Prepaid Partial Authorization Response
Response
0120 Acquirer Authorization Advice 0120 Acquirer Authorization Advice
0120 Acquirer Authorization STIP Advice 0120 Acquirer Authorization STIP Advice
0120 Preauthorization Completion Advice
0120 Balance Inquiry Advice 0120 Preauthorization Advice
System Fundamentals
Return STIP Authorization Advice STIP Authorization Advice
0120 File Maintenance Advice 0120 File Maintenance Advice
0120 Money Transfer Original Credit
Authorization STIP Advice
0120 Offline Decline 0120 Offline Decline
0130 Acquirer Authorization Advice 0130 Acquirer Authorization Advice Response
Response
0130 Issuer Preauthorization Completion 0130 Acquirer Authorization STIP Advice
Advice Response
0130 Authorization Advice Response
0130 Credit Voucher and Merchandise Return
STIP Authorization Advice Response
0130 File Maintenance Advice Response 0130 File Maintenance Advice Response
0130 Offline Decline Response 0130 Offline Decline Response
0200 Financial Transaction Request
0200 Balance Inquiry Request
0200 Healthcare Auto-Substantiation Request
0200 Money Transfer Original Credit Request
0200 Prepaid Activation Request
0200 Prepaid Load Request
0200 Prepaid Activation and Load Request
0200 Prepaid Partial Activation and Load
Request


0210 Financial Transaction Response
0210 Healthcare Auto-Substantiation Response
0210 Prepaid Activation Response
0210 Prepaid Load Response
0210 Prepaid Activation and Load Response
0210 Prepaid Partial Authorization Response
0210 Balance Inquiry Response
0220 Preauthorization Completion
0220 Interlink Preauthorization Completion
0220 Financial Transaction Advice
0220 Balance Inquiry Advice
0220 Money Transfer Original Credit STIP
Advice
0220 Representment
System Fundamentals
0220 Representment Validation Request
0220 Fee Collection or Funds Disbursement
Advice
0230 Financial Transaction Advice Response
0230 Preauthorization Completion Advice
Response
0230 Representment Advice Response
0230 Representment Validation Response
Advice Response
0282 Representment Status Advice
0292 Representment Status Advice Response
0300 Acquirer File Update or Inquiry 0300 Acquirer File Update or Inquiry Request
Request
0302 Issuer File Update or Inquiry Request 0302 Issuer File Maintenance Request (Update
or Inquiry)
0310 File Update or Inquiry Response to 0310 File Update or Inquiry Response to 0300
0300
0312 File Update or Inquiry Response to 0312 File Maintenance Response
0302
0322 Exception File Update Advice 0322 File Update Advice
0332 File Update Advice Response 0332 File Update Advice Response
0400 Reversal Request 0400 Reversal Request
0400 Preauthorization Reversal Request 0400 Preauthorization Reversal Request


0400 Credit Voucher and Merchandise
Return Authorization Reversal
0400 Prepaid Activation Void/Reversal 0400 Prepaid Activation Void/Reversal
0400 Prepaid Load Void/Reversal 0400 Prepaid Load Void/Reversal
0400 Prepaid Activation and Load 0400 Prepaid Activation and Load Void/Reversal
Void/Reversal
0400 Prepaid Partial Authorization 0400 Prepaid Partial Authorization Void/Reversal
Void/Reversal
04011 Repeat
0410 Reversal Response 0410 Reversal Response
0410 Preauthorization Reversal Response 0410 Preauthorization Reversal Response
Return Authorization Reversal
Response
0410 Prepaid Activation Void/Reversal 0410 Prepaid Activation Void/Reversal
System Fundamentals
Response Response
0410 Prepaid Load Void/Reversal 0410 Prepaid Load Void/Reversal Response
Response
0410 Prepaid Activation and Load 0410 Prepaid Activation and Load Void/Reversal
Void/Reversal Response Response
0410 Prepaid Partial Authorization 0410 Prepaid Partial Authorization Void/Reversal
Void/Reversal Response Response
0420 Reversal Advice 0420 Reversal Advice
0420 Acquirer Authorization Advice
Reversal
0420 Acquirer Authorization STIP Advice
Reversal
Return STIP Authorization Reversal
Advice
0422 Chargeback Advice
0422 Chargeback Validation Request
0422 Chargeback Reversal Advice
0422 Chargeback Reversal Validation Request
Advice
0430 Acquirer Authorization Advice
Reversal Response
0430 Reversal Advice Response
0432 Chargeback Advice Response
0432 Chargeback Validation Request Response


0432 Chargeback Reversal Advice Response
0432 Chargeback Reversal Validation Request
Response
Advice Response
0480 Chargeback Status Advice
0480 Chargeback Reversal Status Advice
0490 Chargeback Status Advice Response
0490 Chargeback Reversal Status Advice
Response
0520 Reconciliation Advice
0530 Reconciliation Advice Response
0600 Text Request
0600 Request for Copy or Original
System Fundamentals
0600 Advanced Authorization Scoring Request
0610 Advanced Authorization Scoring Response
0610 Text Response
0610 Copy or Original Response
0620 Copy or Original Advice
0620 Copy or Original Validation Request
0620 Funds Transfer Totals Advice
0620 Informational Message
0620 Mobile IP Gateway Notification Advice
0620 Text Advice
0630 Text Advice Response
0630 Copy or Original Advice Response
0630 Copy or Original Validation Request
Response
0630 Funds Transfer Totals Advice Response
0630 Informational Message Response
0800 Network Management Request 0800 Network Management Request
0810 Network Management Response 0810 Network Management Response
9240 Collection Only Request
9242 Collection Only Response
9620 Fraud Notification


9630 Fraud Notification Response
1. With the exception of their message designator, BASE I repeat requests (for instance, 0101 or 0401 messages) or
advices are exact replicas of their originals and therefore behave the same and contain the same values. The V.I.P.
System considers an 0x01 repeat message to be a copy of an 0x00 message if the values in Field 11—System Trace
Audit Number and Field 37—Retrieval Reference Number are the same in both.
2. SMS issuers can receive 0101 messages sent by BASE I acquirers.
2.6.2 Message Flow Example

Figure 2-6 illustrates a message flow (from the merchant to the issuer and back),
which includes the following steps:
1. The transaction begins when:
- A cardholder, merchant, or clerk swipes a card through a magnetic stripe reader.
- A terminal reads a chip on a card.
- A cardholder inserts a card into an ATM.
- An acquirer submits an electronic commerce request.
- A merchant or clerk manually enters the card number into a terminal.
- A merchant or clerk submits a recurring payment request.
- A merchant or an issuer submits an prepaid activation, prepaid load, or prepaid
System Fundamentals
activation and load request.

- A cardholder submits a contactless transaction. Contactless transactions are
card-present transactions that use wireless technologies such as radio frequency (RF)
and infrared to securely transmit the account number and other card-based information
without the need of a physical POS device such as a card reader or chip reader.
2. The merchant creates the financial request message and forwards it to the acquirer.
3. The merchant's acquirer takes the information and creates an 0100 authorization or
0200 financial request message, logs the event, and forwards the message to VisaNet.
4. V.I.P. logs and tracks the message, assigns a transaction identifier (TID), performs
any applicable message content editing, initiates service functions such as currency
conversion or PIN, Card Verification Value (CVV), Integrated Chip Card card verification
value (iCVV), or Dynamic Card Verification Value (dCVV) verification, and routes
the message to the issuer or processes the message in stand-in according to issuer
availability and predetermined routing and STIP parameters.
NOTE
V.I.P. assigns a transaction identifier (TID) to all Visa transactions.
5. The issuer checks the transaction amount against the account's available balance and
then checks daily activity limits and other controls, if any. The issuer logs the message
and, for approved messages, reduces the cardholder's available balance by the amount
of the transaction. The issuer creates an 0110 authorization or 0210 financial response
message based on the processing results and sends it to VisaNet.
6. V.I.P. logs the response and forwards it to the acquirer.
7. The acquirer logs the financial response and forwards it to the point of sale or point of
service (POS) to complete the transaction. The acquirer ensures that it successfully
delivers the response. If approved, V.I.P. settles the transaction after the next settlement
cutoff time.

Chapter 2 Message Editing
Figure 2-6 illustrates a message flow (from the merchant to the issuer and back).
Figure 2-6 Typical Message Flow
Request Request
(0100 or 0200) (0100 or 0200)
Merchant
or
ATM Response Response
(0110 or 0210) (0110 or 0210)
Acquirer V.I.P. System Issuer
System Fundamentals
2.7 MESSAGE EDITING
Both BASE I and SMS check the format and the content of each message they receive.
Every message must comply with the V.I.P. System message requirements. All stations
must use the V.I.P. message format.
If the message format is correct, V.I.P. performs additional edits.

EXAMPLE
For SMS financial messages, V.I.P. inserts a settlement date that indicates when the message becomes part
of a transaction's SMS settlement between the acquirer and the issuer.
2.8 MESSAGE ROUTING BASICS

Message routing is an important function of the V.I.P. System. Routing refers to sending
messages between VisaNet and acquirer and issuer processing centers. Routing also
refers to switching a message to V.I.P. stand-in processing (STIP) for authorizing a
transaction on an issuer's behalf.
2.8.1 Routing Messages

To route messages, V.I.P. uses member-supplied information stored in the BASE I and
SMS system tables along with information in the message header, the message type
identifier, and data fields. V.I.P. compares the message information to the applicable
BIN (a range of card numbers for a specific card product, such as Visa Classic) and to
processing center information stored in the system tables. This information includes:
• Account number.
• Card type.
• Source address.
• Destination address.

Chapter 2 Message Routing Basics
Visa assumes responsibility for routing a request to its proper destination. Acquirers do not
have to determine the destination of their authorization or financial requests because V.I.P.
routes requests based on the account number in the message.
In some cases, V.I.P. uses data other than the account number to determine message
routing. For SMS transactions, V.I.P. also uses the value in the network ID field to route
messages.
The Inter-Task Table (ITT) retains a transaction’s key field information until the issuer or
STIP sends a response to that transaction. The table matches requests and responses and
identifies repeat or duplicate requests by using these fields:
Field 32—Acquiring Institution Identification Code
Field 37—Retrieval Reference Number
Field 41—Card Acceptor Terminal Identification
Field 42—Card Acceptor Identification Code
Field 63.1—Network Identification Code

System Fundamentals
Issuers designate which of their issuer processing centers should receive the requests
through either one of the following ways:
• Associating each issuer BIN with a specific issuer processing center.
• Designating multiple processing centers and specifying the types of transactions that
VisaNet should route to each processing center.
2.8.1.1 Routing Tables

V.I.P. provides routing table services for both BASE I and SMS acquirers. The routing
tables, also referred to as BIN tables or as account range tables, are batch data files that
list all card prefixes, prefix lengths, and account number lengths. These tables contain
records of the relationships of issuers to account numbers, of issuers and acquirers
to processing centers, of processing centers to the VICs, and of processing centers
to stations. The tables help V.I.P. and acquirers make authorization routing decisions.
The current routing tables are:

• ATM Routing File
• Consolidated Routing File
• Interlink and Visa
• Visa
• Visa Electron
• Visa POS Debit Device
Entries in the Visa BIN routing tables contain whatever number of digits are necessary
to identify a card range or a card portfolio. A routing table entry may be simply a BIN
412345), or may be a longer number for a Plus proprietary card program
(for instance, 412345
504667214). Entries can be up to 12 digits.
(for instance, 504667214
Members control routing by establishing appropriate relationships among card account

number ranges, types of transactions, and processing center stations. BASE I and SMS

Chapter 2 Message Routing Basics
route Visa, Visa Electron, Plus, and Interlink transactions, and non-Visa card products,
based on the following parameters:
• Routing and transit numbers.
• Network IDs.
• Card types.
• Account numbers.
• Account ranges.
• Acquirer and issuer stations.
• User preferences for priority routing and for PIN processing.
NOTE
The Visa BIN routing tables include the issuer institution country code.
Visa requires all Visa and Plus acquirers to use the Visa routing tables. Visa requires
all Visa POS acquirers in the U.S. region to use the Visa POS Debit Device routing
table. For more information about routing tables, refer to the Visa International Operating
Regulations (VIOR). Members can contact their Visa representatives to obtain the tables.
2.8.1.2 Internal Routing Services
System Fundamentals
In addition to basic routing functionality, Visa provides routing services that enable issuers
and acquirers to specify alternate routing for transactions with specified characteristics.
Most of the routing services V.I.P. provides are optional.
EXAMPLE
Issuers can designate an alternate path for routing particular transaction types. For instance, issuers can
route ATM transactions differently from POS transactions; they can route transactions containing PINs
differently from non-PIN transactions; they can route exception transactions differently from authorization and
financial transactions.
Additionally, V.I.P. can route transactions according to member specifications using the
services listed below. These services route low-risk transactions to the V.I.P. stand-in
processor (STIP).
• The Positive Cardholder Authorization Service (PCAS) uses PCAS-established limits
such as issuer, advice, and activity limits to determine whether to route transactions
to the issuer or to STIP.
• The Positive Authorization Capacity Management (PACM) Service routes transactions to
the issuer or to STIP primarily by using an issuer limit as well as a dynamic limit called
the diversion threshold. STIP determines this limit by comparing transaction volume
to issuer capacity.
See Part 2 of this manual for an overview of routing services. Refer also to V.I.P. System
BASE I Processing Specifications and to the V.I.P. System SMS processing specifications
manuals for additional information about V.I.P. routing.
2.8.1.3 Gateways to Non-VisaNet Destinations

If the destination is a system or a network outside of VisaNet, V.I.P. uses Gateway Services
to reformat the message, if necessary, and to deliver it to the other system or network.
Both BASE I and SMS have connections, or gateways, to outside systems and networks.

Chapter 2 Stand-In Processing (STIP)
Gateway Services route transactions through these gateways and return messages
to members using the same VisaNet Access Points.
Refer to Chapter 6, Gateway Services, for detailed information about available gateways
and Gateway Services.
2.9 STAND-IN PROCESSING (STIP)

V.I.P. acts as a back-up processor when issuers request it or when issuers are unavailable.
During this back-up processing, V.I.P. authorizes, declines, or refers transactions on the
issuer's behalf. This function is referred to as stand-in processing, or STIP.
Issuers specify the stand-in processing parameters that V.I.P. is to use. Visa card issuers
can maintain files of cardholder data at the VisaNet Interchange Center (VIC) and can
select the limits that control which transactions STIP can approve. Other card programs
processed according to Visa rules are also eligible for STIP at the issuer's discretion.
Whether VisaNet routes a transaction to the issuer or to STIP for an approval or decline
decision depends on the:
• Availability of the issuer at the time the transaction is being processed.
• Issuer-specified transaction processing parameters that reside in the system tables.
• Visa-mandated conditions for certain transaction types.
System Fundamentals
If the conditions of the cardholder account and the transaction require that the issuer,
rather than STIP, should make the final authorization decision, STIP forwards the request
message to the issuer if the center is available. If the issuer is unavailable, STIP then
processes the transaction according to issuer-unavailable parameters.
V.I.P. usually creates advices for issuers to inform them of actions taken by STIP on their
behalf. Issuers have several options for recovering their advice data from V.I.P.
NOTE
V.I.P. stores SMS advices online for 30 days. SMS issuers that want to retrieve their advices need to retrieve
them within this 30-day period.
Refer to V.I.P. System Services, Volume 2, for information about both BASE I and SMS
advice retrieval services.
Visa provides issuers with two optional, issuer-or-STIP routing services that can help
in the routing decision process:
• Positive Authorization Capacity Management (PACM) Service—This BASE I and SMS
service routes authorization and financial requests to the issuer or to STIP based on
dollar amount thresholds and on message traffic volumes.
• Positive Cardholder Authorization Service (PCAS)—This BASE I and SMS service routes
authorization requests to the issuer or to STIP according to a comprehensive set of risk
control parameters that includes dollar amount thresholds.
Refer to the Positive Authorization Capacity Management (PACM) Service chapter and to
the Positive Cardholder Authorization Service (PCAS) chapter in Volume 2 for information
about these services.
2.9.1 BASE I STIP

BASE I stand-in processing (STIP) provides issuers with business functions that:

Chapter 2 Stand-In Processing (STIP)
• Protect issuers from transaction volumes in excess of their processing capacity.

• Allow issuers to control authorization processing expenses by having STIP approve
low-risk, small-ticket transactions.
• Allow issuers to provide a high level of cardholder service during issuer-unavailable
conditions while still controlling risk.
The first two functions pertain largely to issuer-available STIP. The third function applies
largely to issuer-unavailable STIP. The different circumstances and implications between
issuer-available and issuer-unavailable processing drive the rules for how V.I.P. processes
transactions.
When transactions fail issuer-available STIP processing, V.I.P. typically (at the issuers'
option) “forward-refers” them to issuers for authorization decisions. In these cases, STIP
forward-refers transactions identified as having elevated risk to the issuer and approves
transactions within issuer-unavailable risk parameters. This approach minimizes negative
cardholder experiences resulting from false declines, that is, declining a “good” cardholder
because of transaction characteristics or because of cardholder spending that indicates
heightened risk.
When the issuer is unavailable, STIP cannot forward-refer transactions to the issuer.
Instead, it must generate a response for the acquirer. This circumstance creates an
System Fundamentals
elevated customer service risk. Thus, for issuer-unavailable processing, issuers can
choose to relax cardholder spending-related risk controls for the sake of increasing
customer service levels.
BASE I STIP performs a number of functional services to identify elevated risk. These
services include:
• Checking the CVV or the iCVV, CAVV, dCVV, PIN, expiration date, and the Exception
File.
• Validating the account number with the Luhn modulus-10 algorithm.
• Checking cardholder spending and activity and the transaction amount.
BASE I STIP provides a wide variety of issuer options for determining which of these
functions V.I.P. is to perform and how V.I.P. is to use them.
Refer to V.I.P. System BASE I Processing Specifications for more information about
BASE I STIP functions.
2.9.2 SMS STIP

SMS STIP protects issuer processing capacities and allows issuers to maintain high levels
of cardholder service during issuer-unavailable conditions. Risk control options that issuers
can specify for STIP include:
• Establishing transaction activity limits for card ranges and for individual cardholders.
• Checking the Exception File for positive account limits (for instance, generous limits for
VIP [Very Important Person] accounts) or negative account controls (for instance, card
pick-up).
• Checking the CVV on the card's magnetic stripe, the CVV or the iCVV on the card's chip
image, the CAVV, or the dCVV.
• Checking PINs and monitoring the number of PIN-entry attempts.
• Validating the account number with the Luhn modulus-10 algorithm.
• Ensuring a valid card expiration date.

Chapter 2 Auto-Substantiation Transactions
SMS STIP also handles issuer-generated messages including chargebacks, fee collections
and funds disbursements, and text messages for unavailable acquirers.
Refer to the V.I.P. System SMS processing specifications manuals for more information
about SMS STIP functions.
2.10 AUTO-SUBSTANTIATION TRANSACTIONS

Available in the U.S. region only, cardholders make auto-substantiation transactions for
purchases eligible for Flexible Spending Accounts (FSAs) or Healthcare Reimbursement
Arrangements (HRAs) as defined by Internal Revenue Service (IRS) regulations.
These transactions allow employers and their third-party service providers to approve
over-the-counter (OTC) qualified medical expenses from participating retailers at the time
of purchase. This capability reduces the need for consumers to make a purchase and later
have to submit sales receipts for employer reimbursement. In addition to supporting partial
authorizations, auto-substantiation transactions are valid for FSA card-based transportation
purchases such as commuter tickets, parking passes, and mass transit vouchers and
tickets.
V.I.P. force-routes auto-substantiation transactions to issuers for approval or decline

decisions. The issuer forwards the request to the cardholder’s health insurer; the insurer
System Fundamentals
returns the result—approval for the full or partial amount, or a decline decision.
The IRS requires merchants to support an Inventory Information Approval System (IIAS)
if they want FSA and HRA cardholders to use the cards at their locations. For merchants
5122, if 90% of their total sales come
with merchant category codes (MCCs) of 5912 and 5122
from healthcare products, the issuer can approve FSA or HRA card transactions at these
locations even if the merchant does not support an IIAS.
NOTE
Positive Authorization Capacity Management (PACM) Service processing does not apply to auto-substantiation
transactions. V.I.P. passes the message to available issuers without performing any service-specific editing;
STIP declines unavailable-issuer requests with response code 91 (issuer unavailable) in Field 39—Response
Code. If the issuer is unavailable for reversals, STIP responds with response code 21 (no action taken
in field 39).
The key fields in 0100 and 0200 auto-substantiation requests are:

• Field 54—Additional Amounts: Positions 3–4 contain the amount type. Valid values are:
- Code 4S4S—Total Amount Healthcare
- Code 4T4T—Amount Transit (not applicable to healthcare auto-substantiation
transactions)
- Code 4U4U—Amount Prescription/Rx
- Code 4V4V—Amount Vision/Optical
- Code 4W4W—Amount Clinic/Other Qualified Medical
- Code 4X4X—Amount Dental
• Field 60.10—Partial Authorization Indicator: This field must contain 1 (acquirer supports
partial authorizations).
• Field 62.4—Market-Specific Data Identifier: This field must contain M (medical;
healthcare) or T (transportation, in healthcare transactions only).

Chapter 2 Account-Level Programs and Cardholder Rewards
IMPORTANT
Issuers must include field 62.4 in 0110 auto-substantiation responses for both Visa and MasterCard
transactions.
V.I.P. and issuer processing depends on whether the amount in field 4 equals the amount
in field 54, positions 9–20, which means the transaction is considered a full authorization; or
the amount in field 4 is greater than the amount in field 54, which means the transaction
is a partial authorization.
In the event of an IRS audit, the issuer requests the merchant for details of healthcare
product line items on specific transactions. The request contains the issuer’s fax number to
which merchants must send the healthcare receipt data.
2.11 ACCOUNT-LEVEL PROGRAMS AND CARDHOLDER REWARDS

The Visa Incentive Network (VIN) allows members and merchants in participating regions
to design and implement unique products and services for individual cardholders or for
highly specific groups of cardholders. Visa unlinked the services and benefits that were
associated with the Visa Classic, Visa Gold, and Visa Platinum programs and combined
the three cards as the revised Visa Consumer Credit Platform. Issuers are free to define
the benefits that distinguish their Classic, Gold, and Platinum consumer credit products as
System Fundamentals
they see fit. By establishing standards for a Visa Consumer Credit Platform rather than
defining distinctions among Classic, Gold, and Platinum, issuers can define the benefits
that distinguish the cards. Additionally, issuer-defined products (for instance, Classic, Gold,
Platinum) may reside in the same BIN. Also, all Visa Consumer Credit Platform cards now
carry auto rental insurance as a basic feature paid entirely by Visa.
In support of the Consumer Credit Platform, issuers can track consumer card-level activity
by individual account number. This ability enables participating issuers to assign multiple
features and modify products, services, and enhancements without changing the account
number or reissuing the card. The card-level capability applies to Visa traditional products
(consumer credit card types without reward programs) and Visa traditional rewards
products (consumer credit programs with reward programs) processed as BASE I 01xx
dual-message or SMS 02xx full financial consumer card-based transactions, including
their reversals.
Account-level processing is available also for certain commercial and prepaid products.
For account-level processing, in addition to the account number, a key field in a card-level
program is Field 62.23—Card-Level Results. V.I.P. adds this field to authorization or
financial requests to identify the specific card project for the issuer. V.I.P. retrieves the
values from the Cardholder Database (CDB) according to the specific cardholder. Issuers
update the CDB with the Cardholder Maintenance File. Refer to the pertinent V.I.P.
technical specifications manuals for more information.
2.12 HEALTHCARE ELIGIBILITY INQUIRIES

Visa healthcare eligibility inquiries allow healthcare providers to determine whether
a cardholder’s health insurance coverage is current. These U.S. region-only 0100
authorization requests and 0110 responses are non-financial, information-only transactions.
Eligibility inquiries are valid for BASE I, SMS POS, and Interlink.

Chapter 2 MasterCard Processing
The key eligibility inquiry fields in 0100 authorization request are:

• Field 3—Processing Code: Positions 1–2 must contain 39 to indicate an eligibility inquiry.
• Field 4—Amount, Transaction: The field must contain zero. If the acquirer sends a
different amount, V.I.P. changes it to zero.
• Field 104—Transaction-Specific Data: This field contains one or more specific
tag-length-value (TLV)-formatted datasets that include the healthcare provider’s ID and
the HIPAA healthcare treatment code if applicable. V.I.P. forwards the field to issuers
that have successfully completed testing for this processing; otherwise it drops it. Refer
to “Field 104—Transaction-Specific Data” in the BASE I or SMS technical specifications
manuals for further information.
0110 responses include the following key fields:
• Field 54—Additional Amounts: This field contains the co-payment amount in the following
format:
- Positions 1–2, Account Type contains 00
- Positions 3–4, Amount Type contains 3S
- Positions 5–7, Currency Code contains 840 for U.S.
- Position 8, Amount, Sign contains C for positive balance
- Positions 9–20, Amount contains the cardholder’s co-payment amount.
System Fundamentals
NOTE
For healthcare auto substantiation requests (field 62.4 contains M), if field 54, positions 1 and 2, and field 3.2
40, V.I.P. changes the value in field 54, positions 1 and 2, to match the value in field 3.2.
contain 00 or 40
• Field 4—Amount, Transaction: The field must contain zero

zero. If the acquirer sends a
zero.
different amount, V.I.P. changes it to zero
• Field 104—Transaction-Specific Data: In responses, in addition to the field 104 data
from the request, the field includes data that applies to the approval or decline decision,
such as health insurance carrier, payer ID, or approval or reject reason codes. Refer to
“Field 104—Transaction-Specific Data” in the BASE I or SMS technical specifications
manuals for further information.
U.S. region members must successfully complete testing to show that they can support
39)
field 3 processing code (39 3S).
39 and field 54 amount type (3S
3S Participation is limited.
Interested members can contact their Visa representatives for further details.
2.13 MASTERCARD PROCESSING

As with Visa and American Express, Visa and MasterCard have a reciprocal transaction
processing agreement. Under the agreement between Visa and MasterCard, VisaNet
forwards dual-message PIN and non-PIN-based MasterCard transactions acquired by Visa
acquirers within VisaNet to Banknet (MasterCard's processing network) for delivery to their
MasterCard issuers, and MasterCard forwards Visa transactions acquired by MasterCard
acquirers within Banknet to VisaNet for delivery to their Visa issuers. Supported
transactions include authorizations, including those for automated fuel dispenser (AFD)
transactions, e-commerce, contactless, telephone order, and chip-based transactions,
as well as partial approvals, partial approval reversals, and recurring payment cancellations.
“Routing Options” that follows summarizes the processing of PIN-based transactions.
2.13.1 Routing Options

There are three ways to route VisaNet-acquired MasterCard transactions to their issuers:

Chapter 2 MasterCard Processing
• POS transactions through the Visa Gateway to Banknet.

• PIN and non-PIN transactions directly to a MasterCard issuer using the Visa Shortest
Online Path (VSOP) Service.
• PIN and non-PIN POS transactions directly to a VisaNet-attached MasterCard issuer
using the PIN/No-PIN Split Routing Service.
NOTE
VisaNet supports chip-based and contactless MasterCard POS transactions.
The Visa Message Gateway connects VisaNet and Banknet and automatically converts
messages as they pass between the networks. VisaNet automatically converts MasterCard
transactions routed to Banknet to the Banknet message format. (VisaNet-acquired
MasterCard transactions sent to VisaNet-attached endpoints remain in V.I.P. message
format.) For information about converting messages between networks including field
transfer details, refer to Credit Gateway Service Cross-Reference Guide.
VisaNet sends MasterCard POS transactions to Banknet. VisaNet can send them to
MasterCard issuers that are attached to VisaNet using the VSOP Service or the PIN/No-PIN
Split Routing Service, both of which are summarized below. These transactions include
POS balance inquiries, authorizations, purchase transactions, including manual cash and
System Fundamentals
quasi-cash, as well as card-not-present mail order, telephone order, and e-commerce
(MOTO/EC) transactions, and reversals. VisaNet also processes partial approvals, partial
reversals, and recurring payment cancellations. Refer to Chapter 6, Gateway Services,
for further information and processing requirements.
By participating in the VSOP Service, MasterCard issuers can bypass Banknet and receive
PIN-based POS and ATM cash disbursement transactions, and non-PIN POS MasterCard
transactions directly from VisaNet (in V.I.P. message format). Requirements include a direct
VisaNet access device in addition to any Banknet connection. Refer to Chapter 10, Visa
Shortest Online Path (VSOP) Service, for further information and processing requirements.
As an alternate routing method, Visa issuers can route PIN and non-PIN MasterCard
transactions to VisaNet-attached MasterCard issuers using the PIN/No-PIN Split Routing
Service. PIN-based transactions can include cash disbursement transactions if they are
acquired as SMS full financial transactions destined for Plus or CIRRUS SMS issuer
BINs. VisaNet clears and settles these transactions in the same manner as Visa SMS
full-financial ATM transactions. Refer to Chapter 8, PIN/No-PIN Split Routing Service,
for further information and processing requirements.
NOTE
MasterCard can bypass VisaNet and send Visa transactions (except Custom Payment Service [CPS]
transactions) directly to Visa issuers connected to Banknet. Banknet always forwards MasterCard-acquired
Visa CPS transactions to VisaNet.
2.13.2 Visa Services and Functions Available for MasterCard

VisaNet provides several Visa services and capabilities to facilitate the processing
of MasterCard transactions by Visa members. The availability of these services and
capabilities depends on the region.

Chapter 2 U.S. Account Updater Verification (VAU) Service
IMPORTANT
V.I.P. stand-in processing (STIP) is no longer available for MasterCard transactions.
For instance, MasterCard acquirers attached to VisaNet in the U.S. region can participate
in the Merchant Central File Service (MCFS), which augments 0100 authorization requests
and 0400 authorization reversals with merchant or terminal identifiers that acquirers
cannot otherwise provide. Acquirers maintain MCFS records, which typically include the
merchant name, location, country, and ZIP or postal code, and the applicable merchant
category code (MCC).
In Malaysia, Visa members can use certain V.I.P. System services to process domestic
PIN- and non-PIN-based POS MasterCard transactions without having to send those
transactions to Banknet. Visa issuers that issue MasterCard cards must be directly
connected to VisaNet so they can receive their MasterCard transactions through VisaNet.
Allowable domestic transactions (the merchant, the acquirer, and the issuer are all in
the same country) include manual cash. The service excludes ATM cash disbursement
and MasterCard chip transactions. Visa requires successful completion of testing before
participation.
System Fundamentals
If Visa acquirers of MasterCard transactions participate in the Multicurrency Service,

the request and response messages remain by default in the acquirer’s local currency—
V.I.P. does not necessarily convert the amounts to U.S. dollars and does not automatically
840. This optional service is not available to acquirers that
change the currency code to 840
are not Multicurrency Service participants; V.I.P. continues to convert their MasterCard
transactions with non-U.S. currencies to U.S. dollars with the 840 currency code.
2.14 U.S. ACCOUNT UPDATER VERIFICATION (VAU) SERVICE

The Account Updater Verification (VAU) Service enables both BASE I and SMS acquirers
and VisaNet to query cardholders' accounts in the Global Customer Assistance Service
(GCAS) databases. VAU is an optional service that enables the secure electronic
transmission of updated account information among participating issuers, acquirers,
and merchants that process Visa transactions using account information they keep on file.
The service also enables acquirers to update the databases with current information.
Participating acquirers use 0100 authorization messages that include:
• Replacement account number
• Replacement expiration date
• Account status codes
• Credit limit information
• Card product type code
• Type of card
Participation in the service requires successful completion of testing. Acquirers, issuers,
and merchants that choose to participate in the Account Updater Verification Service can
contact their Visa representatives.
Also available are the Visa services:

• Card Verification Value (CVV) Service
• Card Verification Value 2 (CVV2) Service

Chapter 2 Trusted Agent Program (TAP)
• Positive Cardholder Authorization Service (PCAS)

• PIN Verification Service (PVS)
Members must supply Visa with necessary encryption keys as well as issuer limits and
other risk control information. For further information, members can contact their Visa
representatives.
2.15 TRUSTED AGENT PROGRAM (TAP)

The Trusted Agent Program (TAP), formerly called the Agent Identification Service (AIS),
informs acquirers of merchants that are using unregistered agents (including third-party
servicers and merchant servicers) to submit transactions to VisaNet using the acquirers'
BINs. Unauthorized VisaNet access compromises the security of the Visa payment system
and exposes Visa members to considerable risk from theft and fraud. Although acquirers
are financially liable for all transactions submitted under their BINs, they can be unaware
of the merchant-agent arrangements because the transactions pass through agents to
VisaNet, bypassing the acquirers.
TAP greatly reduces acquirers' risk by monitoring transactions submitted through acquiring
agents to VisaNet and then reporting unauthorized use of BINs to acquirers. Tap identifies
unregistered agents and logs them for acquirer registration and Visa risk analysis.
TAP applies to all 0100 and 0200 authorization and full financial request messages
System Fundamentals
processed through BASE I, SMS POS, and SMS Interlink.
Visa assigns each agent a secret code and unique ID. When an agent receives a request
from a merchant, the agent constructs the contents of Field 126—Agent Unique Account
Result (AUAR), by hashing the secret code, unique ID, and the account number according
to a Visa-specified algorithm. The agent forwards the AUAR to the acquiring VisaNet
processor along with the other merchant information for submisission to VisaNet.
If an acquiring processor receives the merchant's authorization request or full financial

request message from the agent but the agent did not include the AUAR, the acquiring
processor uses a Visa-supplied default AUAR for the VisaNet submission. If an acquiring
processor receives requests directly from a merchant, VisaNet does not require field 126.18
and the field must not be present in the request.
V.I.P. does not edit the field; it also does not send it to the issuer processor nor does it
return field 126.18 in the response. VisaNet validates the field offline and sends summary
reports to the acquirers or to their designates.
Currently, U.S. acquirers and their processors optionally can support TAP. They must
successfully complete testing to show they can send field 126.18. Visa will require all U.S.
acquirer processors to support TAP at a later date.
2.16 VISA PRODUCT ELIGIBILITY INQUIRIES

Visa product eligibility inquiries provide consumer and commercial product information
associated with the cardholder’s account number. V.I.P. does not forward these requests
to issuers. V.I.P. bases its responses on card-level information or on account-range details
that V.I.P. retrieves from the system files. These 0100 authorization requests and 0110
responses are non-financial, information-only transactions. Product eligibility inquiries are
valid for BASE I and SMS POS.

Chapter 2 For More Information
The key product eligibility inquiry fields in 0100 authorization request are:
• Field 3—Processing Code: Positions 1–2, must contain 39 to indicate a product eligibility
inquiry.
• Field 4—Amount, Transaction: The field must contain zero zero. If the acquirer sends a
zero.
different amount, V.I.P. changes it to zero
• Field 25—POS Condition Code: The code must be 51 for verification only.
0110 responses includes the key field, Field 62.23—Card-Level Results. V.I.P. populates
this field with the cardholder’s consumer credit platform rewards program information from
the Cardholder Database, the system files, or both.
Acquirers must successfully complete testing that they can process the codes in field 3 and
field 25, along with the ability to receive and process field 62.23. Participation is limited.
Members can contact their Visa representatives for complete details.
2.17 FOR MORE INFORMATION

For details about topics described in this chapter, refer to the following:
• The V.I.P. System Overview describes the basics of STIP processing. Refer to
V.I.P. System BASE I Processing Specifications for complete details of STIP processing.
• The various BASE I and SMS processing specifications manuals describe service
processing specifics.
System Fundamentals
Refer to “For More Information” in About This Manual for a list of processing specifications
manuals.

Part 2 Routing Services
Part 2, Routing Services, contains descriptions of the routing services Visa offers in addition
to the basic routing capabilities of VisaNet. For an overview of basic routing concepts and
processing, refer to Chapter 2, V.I.P. System Fundamentals.
Services—This chapter provides an overview of each

Chapter 3, Introduction to Routing Services—
of these services. It also contains quick-reference charts showing which entities can use
the services and for which product types.
Chapter 4—ATM/POS Split Routing Service
Chapter 5—Check Acceptance Service
Chapter 6—Gateway Services
Chapter 7—PIN Debit Gateway Service (PDGS)
Chapter 8—PIN/No-PIN Split Routing Service
Chapter 9—Priority Routing Service
Chapter 10—Visa Shortest Online Path (VSOP) Service


Chapter 3 Introduction to Routing Services
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
IN BRIEF 3-33
CAPABILITIES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
ENHANCED ROUTING CAPABILITIES 3-33
AVAILABLE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
ROUTING SERVICES AVAILABLE 3-33
TABLES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
ROUTING TABLES 3-66
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-
Introduction to Routing Services


Chapter 3 Introduction to Routing Services
3.1 IN BRIEF
The basic routing functionality provided by the V.I.P. System consists of message switching
and Gateway Services. Basic routing includes:
• Message editing to help ensure that recipients receive valid messages.
• Message delivery:
- To VisaNet endpoints.
- To other national and multinational payment systems, using Gateway Services as
the bridge.
NOTE
The routing services described in this chapter and in the other routing chapters in this manual are not to be
confused with the routing function V.I.P. uses to determine if a message can or should go to available issuers,
or if V.I.P. should divert it to the stand-in processor (STIP).
For general information about V.I.P. basic routing, refer to “Routing Basics” in Chapter 2,
System Fundamentals. Chapter 6, Gateway Services, provides details about available
gateways to other payment systems.
3.2 ENHANCED ROUTING CAPABILITIES

V.I.P. provides basic routing functionality, including the ability for members to indicate
transaction destinations by specifying the forwarding institution.
In addition, Visa offers a variety of enhanced routing services that enable issuers and
acquirers to route their transactions as they specify. These services provide delivery
options to processing centers that need to split interchange, settlement, and non-financial

data into separate files, delivered at customized delivery times. Both issuers and acquirers
can specify routing options and VisaNet stores them in the appropriate system routing table.
Most Visa routing services, which address different transaction types and routing
conditions, are optional in all regions. Issuers can designate an alternate path for routing
particular transaction types. For instance, issuers can route point-of-sale or point-of-service
(POS) transactions differently from the way they route ATM transactions; issuers can route
exception transactions differently from the way they route authorizations and financial
transactions.
3.3 ROUTING SERVICES AVAILABLE

This chapter briefly describes the additional V.I.P. routing services. Table 3-1 lists eligible
service participants, which system or systems provide the service, and for which product
types the service is available. Table 3-2 indicates which system routing tables the service
uses.
For detailed information about these routing services, see the pertinent chapters that follow
in Part 2.
Additional routing services include:

Chapter 3 Routing Services Available
Service—
Chapter 4, ATM/POS Split Routing Service —This service enables acquirers and issuers to
separate message traffic according to the following options:
• The ATM/POS Split Routing option allows BASE I and SMS acquirers and issuers to use
separate processing centers for ATM and POS transactions.
• The ATM/POS Account-Type Split Routing option is available to BASE I and SMS issuers
that process ATM and POS transactions. This option allows issuers to direct V.I.P. to
route ATM and POS transactions based on the account the cardholder selects when
using a multipurpose card at an ATM or the POS. Issuers can specify two endpoints:
one for deposit account processing, and one for credit account processing.
• The Alternate Routing option is available to SMS acquirers and issuers. This option
allows SMS entities to choose separate routing for certain transaction types, including
exception items and other back-office transactions. Issuers and acquirers may designate
their primary processing center to process online original transactions and designate one
or more alternate processing centers to process exception and back-office transactions.
Service—
Chapter 5, Check Acceptance Service —This service allows merchants to submit to VisaNet
requests for approval of a check by a selected check acceptance vendor.
Services—
Chapter 6, Gateway Services —The BASE I component and the SMS component of the
V.I.P. System have connections, or gateways, to various systems and networks.
Gateway Services link acquirers accepting non-Visa card products and services to other
networks outside of VisaNet using the same connections they use for Visa transactions.
(PDGS)—
Chapter 7, PIN Debit Gateway Service (PDGS) —The PIN Debit Gateway Service (PDGS)
allows participating merchants in all Visa regions to accept payments made with debit cards
and ATM cards bearing a national or regional direct-debit POS mark and accessed with a
PIN. PDGS also allows SMS participants to accept bill payment transactions submitted
without PINs for ACCEL, STAR, NYCE, PULSE, and other PDG networks. The V.I.P.
System routes these transactions through the VisaNet PIN Debit Gateway (PDG) to the
appropriate direct-debit POS network and the issuer. Routing options give merchants
flexibility to access the various debit POS networks.
The PIN Debit Gateway Service (PDGS) supports the Electronic Benefits Transfer (EBT)
Service. The EBT Service is a federally sponsored program under which a nationwide
program of card-accessed, electronically delivered, government-funded benefits are issued
through a federal-state partnership. Currently, EBT's primary function is the electronic
delivery of food stamps and cash benefits.
NOTE
Members that want to participate in the PIN Debit Gateway Service (PDGS) and its related EBT Service can
access the service with Priority Routing Service transactions if they participate in both services.
Service—
Chapter 8, PIN/No-PIN Split Routing Service —This service enables issuers to separate
message traffic according to the following options:
• The PIN/No-PIN Split Routing option enables issuers to separate transaction
message traffic requiring PINs from message traffic not requiring PINs (called “no-PIN
transactions”).
• The POS PIN Routing option allows issuers to route POS financial transactions with PINs
to SMS and route other transactions to BASE I.

Chapter 3 Routing Services Available
Service—
Chapter 9, Priority Routing Service —This service allows SMS acquirers that accept more
than one card brand (or mark) to assign each of them a priority. Prioritization enables V.I.P.
to determine the desired network and the set of program rules to use for each transaction.
Priority Routing Service does not require the acquirer to assign a specific network identifier
to a transaction.
Members can use the Priority Routing Service with the Alternate Routing service option.
Members can also use the Priority Routing Service to prioritize non-Visa programs destined
for VisaNet's gateways to other systems and networks provided by Gateway Services.
Refer to Chapter 6, Gateway Services, for information about this service.
10,, Visa Shortest Online Path (VSOP) Service

Chapter 10 Service——This service enables BASE I card
issuers to receive MasterCard authorization requests for POS balance inquiry, purchase,
and cash transactions through their VisaNet connection instead of routing the requests to
Banknet (the MasterCard processing network).
Specific routing services are available for issuers, acquirers, BASE I users, and SMS
users. Table 3-1 lists the systems and the products and the corresponding routing services
available.
Table 3-1 Routing Service Availability
AVAILABLE FOR...
Routing Service Acquirer Issuer BASE I SMS Products
ATM/POS Split Routing Service
ATM/POS Split Routing Option ✓ ✓ Visa Electron,
Plus ATM, Visa
ATM/POS Account-Type Split ✓ ✓ ✓ Visa and Visa
Routing Option Electron, Plus

ATM
Alternate Routing Option ✓ ✓ ✓ Visa POS and
Visa Electron,
Interlink, Plus
ATM
Check Acceptance Service ✓ ✓ ✓
Gateway Services ✓ ✓ ✓ Available for all
product types
PIN Debit Gateway Service ✓ ✓ Visa POS
(PDGS)
PIN/No-PIN Split Routing Service
PIN/No-PIN Split Routing ✓ ✓ ✓ Visa Electron
Option and Visa
POS PIN Routing Option ✓ ✓ ✓ Visa Electron
and Visa
Priority Routing Service ✓ ✓ Visa Electron,
Interlink, Plus
ATM, Visa

Chapter 3 Routing Tables
Table 3-1 Routing Service Availability (continued)

AVAILABLE FOR...
Routing Service Acquirer Issuer BASE I SMS Products
Visa Shortest Online Path (VSOP) ✓ ✓ MasterCard
Service
3.4 ROUTING TABLES

The routing services available to participating members rely on access to processing
specifications supplied both by Visa and by members. VisaNet stores these processing
specifications in the BASE I and SMS system tables and in specific system routing tables.
The BASE I and SMS system tables contain records of the relationships of issuers
to account numbers, of issuers and acquirers to processing centers, of processing
centers to VisaNet Interchange Centers (VICs), and of processing centers to network
stations. Users control V.I.P. processing by the parameters and the options they select,
which VisaNet stores in the tables. Users control routing by establishing appropriate
relationships among card account number ranges, types of transactions, and processing
center stations.
NOTE
BASE I acquirers must use Visa-supplied account range routing tables for ATM transactions. SMS acquirers
must also use the Visa routing tables and must specify the preferred card program in which they want to
participate in Field 63.1—Network Identification Code. If the acquirer subscribes to the Priority Routing
Service, the acquirer must specify a network ID of 0000 in field 63.1, and V.I.P. selects the preferred network.
Both BASE I and SMS acquirers must use Visa-supplied account range routing tables for POS transactions.
If SMS POS acquirers subscribe to the Priority Routing Service, they must provide a network ID of 0000 in
field 63.1, and V.I.P. selects the preferred network.
Visa POS acquirers in the U.S. region must use the Visa POS Debit Device routing table.
Routing parameters in the system tables include those for:

• Network IDs.
• Card types.
• Account ranges.
• Acquirer and issuer stations.
• User preferences for priority routing and for PIN processing.
With basic routing, V.I.P. checks the data in specific fields within a request message and
looks at the parameters in the system tables to determine how to route the message.
To support additional routing services, V.I.P. checks additional member-supplied data in

specific system routing tables. For participating routing service members, V.I.P. uses this
additional data in routing tables to make processing decisions.

Table 3-2 lists routing services and their applicable V.I.P. system tables. For general
information about system tables, refer to Chapter 2, System Fundamentals, in this manual,
and to Chapter 2, V.I.P. Transaction Processing, in the V.I.P. System Overview.
Table 3-2 BASE I and SMS Routing Tables
BASE I BASE II
System SMS System Configuration
Routing Service Tables Tables File
ATM/POS Split Routing Service ✓ ✓
ATM/POS Account-Type Split Routing ✓ ✓ ✓
Option
Alternate Routing of Exceptions—BASE I ✓ ✓
Alternate Routing of Exceptions—SMS ✓ ✓
PIN/No-PIN Split Routing Service ✓ ✓
Priority Routing Service ✓

For further information about V.I.P. routing services, refer to chapters 4 through 10.
Each service description chapter provides specifics about eligibility and about participation
requirements as well as process flows, message flows, and key fields.
Chapter 2, System Fundamentals, contains information about basic message routing

principles.


Chapter 4 ATM/POS Split Routing Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
IN BRIEF 4-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
ELIGIBLE PARTICIPANTS 4-33
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
SERVICE SUMMARY 4-44
ATM/POS Split Routing Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
ATM/POS Account-Type Split Routing Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
Alternate Routing Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
PARTICIPATION REQUIREMENTS 4-55
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
HOW ATM/POS SPLIT ROUTING SERVICE WORKS 4-55
PROCESS FLOWS
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
4-55

FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
MESSAGE FLOWS 4-99
KEY FIELDS GLOSSARY

GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
4-11
11
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-
12


Chapter 4 ATM/POS Split Routing Service
4.1 IN BRIEF
The ATM/POS Split Routing Service enables BASE I and SMS acquirers and issuers to
separate types of transactions and to accept or to route these transactions to or from two or
more processing access points. The service offers the following options:
• ATM/POS Split Routing option for separating ATM transactions from point-of-sale or
point-of-service (POS) transactions.
• ATM/POS Account-Type Split Routing option for separating deposit, credit, and universal
and non-specified requests. The POS option is available only in the Asia-Pacific (AP)
region.
• The Alternate Routing option for separating original transactions and exception
transactions. The Alternate Routing option is for SMS endpoints only.
4.2 ELIGIBLE PARTICIPANTS

The ATM/POS Split Routing Service is available to members in all Visa regions.
NOTE:
Not all regions recommend use of the ATM/POS Split Routing Service. Members
should contact their Visa representatives to discuss participation.

The ATM/POS Split Routing Service is available both to BASE I System users
BASE I and to Single Message System (SMS) users. System eligibility varies according
SMS to the options chosen:
• The ATM/POS Split Routing option supports Visa, Visa Electron, and Plus
ATM.
BASE I and SMS
• The ATM/POS Account-Type Split Routing option supports Visa ATM and
Plus ATM. The POS option supports POS and multipurpose card transactions
for BASE I and SMS issuers in the AP region only.
• The Alternate Routing option for exception and back-office transactions is
available to SMS endpoints only and supports Visa, Visa Electron, Interlink,
and Plus ATM.
I Participation in the ATM/POS Split Routing Service is optional for Visa,

Visa Electron, and Plus issuers.
Issuer
A Participation in the ATM/POS Split Routing Service is optional for acquirers

for the Alternate Routing option. The ATM/POS Account-Type Split Routing
option is not available to acquirers.
Acquirer

Chapter 4 Service Summary
4.3 SERVICE SUMMARY

The ATM/POS Split Routing Service enables acquirers and issuers to route transactions
to different processing centers.
This service includes the following options:

• ATM/POS Split Routing
• ATM/POS Account-Type Split Routing
• Alternate Routing (available only to SMS users)
Issuers can use these routing options individually or in combination.
4.3.1 ATM/POS Split Routing Option

The ATM/POS Split Routing option provides BASE I and SMS acquirers and issuers that
process Visa, Visa Electron, and Plus transactions the ability to use separate processing
centers for ATM transactions and for POS transactions.
4.3.2 ATM/POS Account-Type Split Routing Option

This option enables V.I.P. to route ATM and POS transactions by BASE I or SMS
account type. (The capability to route a POS transaction is currently available only in the
Asia-Pacific [AP] region.)
BASE I and SMS issuers can specify that VisaNet route ATM transactions based on the
account the cardholder selects when using a multipurpose card at an ATM. BASE I and
SMS issuers in the AP region can specify that VisaNet route transactions based on the
account the cardholder selects when using a multipurpose card at the point of service.
Issuers can specify up to three access points: one for deposit accounts, one for credit
accounts, and one for universal and non-specified accounts. V.I.P. routes a transaction
based on the contents in Field 3—Processing Code.
• If field 3, positions 3–4 contains 00 or 4040, V.I.P. routes the transaction to the
issuer-specified access point for universal and non-specified accounts.
• If field 3, positions 3–4 contains 10 or 2020, V.I.P. routes the transaction to the
issuer-specified access point for deposit accounts.
• If field 3, positions 3–4 contains 30
30, V.I.P. routes the transaction to the issuer-specified
access point for credit accounts.
See Figure 4-2 for an illustration of the processing V.I.P. performs for this option.
4.3.3 Alternate Routing Option

With the Alternate Routing option, acquirers and issuers can designate one or two alternate
processing centers to handle exception and other back-office transactions. The alternate
processing center may be connected to the SMS component of the V.I.P. System or to an
exception processing system, such as Visa Resolve Online (VROL).
This option allows SMS issuers to receive back-office items from acquirers connected
either to BASE I and BASE II or to SMS.
Alternate routing can apply to:

• Members using third-party processors for back-office items at alternate sites.
• Members using regional centers that want to consolidate back-office processing by
product, rather than by region.

Chapter 4 Participation Requirements
• Issuers attached both to SMS and to BASE II.

• Issuers using separate systems for ATM and POS transaction processing.
For exception transactions, fee-related transactions, back-office adjustments, and
administrative messages, service participants can specify distinct processing centers for
ATM or POS transactions (or for both).
IMPORTANT
If participants use two alternate processing centers, one processing center must be designated for ATM
transactions and the other designated for POS transactions.
The Alternate Routing option also allows issuers that operate as alternate processors to
update and to access exception file or PIN Verification File account records on behalf of
the primary issuer.
VisaNet settles transactions routed to an alternate destination according to the settlement

attributes specified for the original issuer or acquirer unless the access point specifies
alternate settlement.
Refer to the Cardholder Database Overview chapter in Volume 2 for information about
updating the Exception File and the PIN Verification File.
4.4 PARTICIPATION REQUIREMENTS

This section describes participation requirements for the ATM/POS Split Routing Service,

including the ATM/POS Account-Type option and the Alternate Routing option.
4.4.1 Testing
While participating members do not have to be tested to participate in the ATM/POS
Split Routing Service, members must be tested to send and to receive ATM and POS
transactions. Members can contact their Visa representatives to make arrangements
for testing.

Service monitoring is not available for the ATM/POS Split Routing Service or for its three
options.
4.4.3 Planning and Implementation

To fully benefit from the service and to better understand available routing parameters,
issuers can contact their Visa representatives.
4.5 HOW ATM/POS SPLIT ROUTING SERVICE WORKS

The following section describes how the service and its three available service options work.
4.6 PROCESS FLOWS

The following subsections describe the process flows for each of the available service
options.
ATM/POS Split Routing Option Process Flow

For the ATM/POS Split Routing option, V.I.P. routes incoming ATM or POS requests
from acquirers according to the routing option (or options) specified by the issuer.

Chapter 4 Process Flows
Figure 4-1 illustrates the process flow for an issuer that has one processing center
designated for ATM transactions (Issuer Center 1) and another processing center
designated for POS transactions (Issuer Center 2).
Figure 4-1 ATM/POS Split Routing Option Process Flow
Acquirer V.I.P. Issuer Center 1
ATM Requests
PO
SR Issuer Center 2
eq
ue
s ts
The acquirer sends its ATM V.I.P. performs standard The issuer centers receive
and POS requests to V.I.P. request processing and their designated requests
routes ATM requests to and send the appropriate
Issuer Center 1 and response messages.
POS requests to Issuer
Center 2.
V.I.P. forwards the issuers’

responses to the acquirer.
ATM/POS Account-Type Split Routing Option Process Flow

For participants that select the ATM/POS Account-Type Split Routing option, V.I.P. routes
incoming ATM or POS requests from acquirers according to the routing option (or options)
specified by the issuer.
Issuers may optionally designate up to three centers to process:

• Deposit transactions
• Credit transactions
• Universal and non-specified transactions

Figure 4-2 illustrates the ATM/POS Account-Type Split Routing option process flow.
Figure 4-2 ATM/POS Account-Type Split Routing Option Process Flow
Deposit Requests
Credit Issuer Center 2

Reque
sts
Un
No ive
n -Sp rsa
ec la
i fi e nd
dR
eq
ue
s ts
Issuer Center 3
The acquirer sends its V.I.P. performs standard The issuer centers receive
ATM and POS requests request processing and

their designated requests
to V.I.P. may optionally route and send the appropriate
deposit requests to Issuer response messages.
Center 1, credit requests
to Issuer Center 2, and
universal and non-specified
account requests to Issuer
Center 3.

ISO-Standard Account Numbers: V.I.P. uses the value in Field 2—Primary Account number
to identify the issuer BIN for routing. VisaNet accepts ISO-standard account numbers
up to 19 digits in length.
Non-Standard Account Numbers: For non-standard account numbers, V.I.P. uses other
fields to determine the issuer for routing:
• Field 100—Receiving Institution Identification Code. V.I.P. uses the code in this field
included in requests when it cannot identify the issuer from the account number in field 2.
Check acceptance requests and certain non-Visa card transactions include this field.
• Field 102—Account Identification 1 and Field 103—Account Identification 2. V.I.P. uses
the codes in these fields for proprietary or private-label cardholder transactions when
the account number contains alphabetic characters or is otherwise non-standard. If the

account number includes alphabetic characters, VisaNet requires an issuer identifier in

Field 121—Issuing Institution Identification Code.
• Field 121—Issuing Institution Identification Code. This field contains an issuer identifier.
The field applies only to transactions with Visa card account numbers that are not
ISO-registered numbers (and thus may conflict with a registered number). If present,
field 121 overrides all other account number-related fields for determining the issuer.
Issuers that want to use fields 100, 102, 103, or 121 for non-standard account and issuer
identification must first contact Visa.
Alternate Routing Option Process Flow

To determine routing, VisaNet maintains information about network IDs, account ranges,
processing centers, acquirer and issuer stations, and user preferences in its system tables.
Figure 4-3 shows an acquirer that has one alternate processing center and an issuer that
has two alternate processing centers. In this scenario, the primary acquirer center submits
original ATM or POS transactions, while the alternate acquirer center submits exception
and back-office items.
For the issuer, V.I.P. diverts all non-original POS transactions to one center (Alternate
Center 1), and diverts all non-original ATM transactions to the other center (Alternate
Center 2).

Chapter 4 Message Flows
NOTE
Members can also use alternate processing centers for settlement processing. Issuers can specify where
V.I.P. is to route ATM cash disbursement issuer credits. Different processing centers for SMS issuers can
receive ATM fee adjustments than the SMS issuer centers that receive POS adjustments.
Figure 4-3 Alternate Routing Option Process Flow
Acquirer (Primary) V.I.P. Issuer (Primary)
PIN
Original Verification Original
File
Transactions Transactions
Exception
File
s
on s Ex
Acquirer (Alternate) p ti Ite
m an cep Issuer (Alternates 1 and 2)
xce e dB tion
E ffic ac
k-O s
k-O ffic
ac eI
dB tem
an s
The primary acquirer V.I.P. performs standard The primary or alternate

handles original ATM and request processing and issuer processes the

POS requests, while the routes the requests based requests and sends the
alternate acquirer handles on the availability of the appropriate response
exception and back-office issuer. messages.
requests.
V.I.P. forwards the issuer’s

responses based on the
availability of the acquirer.
4.7 MESSAGE FLOWS

Figure 4-4 illustrates the Alternate Routing option message flow.

NOTE
To simplify the flow diagram, the diagram excludes the following messages: 0200, 0282, 0292, 0430, 0490,
0600 copy request, 9620, and 9630.
Figure 4-4 Alternate Routing Option Message Flow
Acquirer (Primary) V.I.P. Issuer (Primary)
PIN
Original Verification Original
File
Transactions Transactions
Exception
File
s
Acquirer (Alternate) p ti
on ms Ex Issuer (Alternates 1 and 2)
ce e Ite an cep
x fic dB
E Of ack tions
a ck- -O
ffic
dB eI
an tem
s
0220 Representment 0220 Representment 0220 Representment

Field 2: Primary Account No. Field 2: Primary Account No. Field 2: Primary Account No.
0230 Advice Response 0230 Advice Response 0230 Advice Response
0302 File Update Request 0302 File Update Request
0312 File Update Response 0312 File Update Response
0322 File Update Advice 0322 File Update Advice

Response Response
0422 Chargeback Advice 0422 Chargeback Advice 0422 Chargeback Advice

Field 32: Acquirer ID Field 32: Acquirer ID Field 32: Acquirer ID
0432 Advice Response 0432 Advice Response 0432 Advice Response
0600 Admin. Request 0600 Admin. Request 0600 Admin. Request

Field 33: Forwarding Institution Field 33: Forwarding Institution Field 33: Forwarding Institution
(or) (or)
Identification Code Identification Code Identification Code
Field 63.1: Network ID Code Field 63.1: Network ID Code Field 63.1: Network ID Code
Field 100: Receiving Institution Field 100: Receiving Institution Field 100: Receiving Institution
(or) (or)

Chapter 4 Key Fields Glossary
NOTE
This message flow shows 0600 free text messages that can flow either from the acquirer or from the issuer.
0600 copy requests originate from the issuer.
4.8 KEY FIELDS GLOSSARY

This section lists and describes key fields associated with the ATM/POS Split Routing
Service and its options.
Table 4-1 ATM/POS Split Routing Service Key Fields
Field Service Option Description

Field 2—Primary Account ATM/POS, ATM/POS This field contains the customer account number, which V.I.P.
Number Account-Type, and uses to determine the routing. Field 2 appears in 0100 and
Alternate Routing 0200 requests, and in 0110 and 0210 responses for all three
split routing options.
Field 3—Processing Code ATM/POS Account-Type This field contains coding that identifies (1) the customer
Routing transaction type and (2) the customer account types, if any,
specified by the transaction. For the ATM/POS Account-Type
Routing option, V.I.P. diverts the requests according to the
account type specified in positions 3 and 4.
• Universal or non-specified accounts:
- 00 (not applicable or not specified)
- 40 (universal account)

• Deposit accounts:
- 10 (savings account)
- 20 (checking account)
• Credit accounts: 30 (credit card account)
Alternate Routing This field contains coding that identifies the customer
transaction type in positions 1 and 2. For the Alternate
Routing option, these positions may indicate if the request is
a purchase or an exception transaction.
Field 18—Merchant Type ATM/POS, ATM/POS This field appears in all requests and in all advices related to a
Account-Type, and customer transaction or to electronic banking payments. For
Alternate Routing ATM-only transactions, the merchant category code must be
6011 for all original 0100 and 0200 authorizations and related
exception item messages.
Field 63.1—Network ATM/POS, ATM/POS Field 63.1 specifies the network V.I.P. is to use for transmission
Identification Code Account-Type, and of the message. Acquirers have the option of determining the
Alternate Routing network ID and specifying it in this field.
Field 63.3—Message Reason Alternate Routing This field appears in any request or advice related to
Code a customer transaction that follows the original 0200 or
0220 message. It also appears in 0120 acquirer or STIP
authorization advices, and in STIP 0220 and 0420 advices.
It does not appear in responses. For the Alternate Routing
option, field 63.3 indicates the reason for the exception
transaction (for instance, chargeback or representment).
Field 100—Receiving Alternate Routing Field 100 contains a code that identifies the institution that
Institution should receive the request or the advice. V.I.P. uses this
ID when it is not possible to determine the issuer from the
account number in field 2.

Table 4-1 ATM/POS Split Routing Service Key Fields (continued)

Field Service Option Description
Field 121—Issuing Institution ATM/POS, ATM/POS V.I.P. uses this ID code when it is not possible to route a
Identification Code Account-Type, and message using non-ISO-standard account numbers. If this
Alternate Routing field is present, it supersedes all other account number fields.
V.I.P. uses it for routing if it is present in the request.

For additional information about the ATM/POS Split Routing Service, refer to the following
documents:
• V.I.P. System BASE I Processing Specifications
• V.I.P. System International SMS ATM Processing Specifications
• V.I.P. System International SMS POS (Visa & Visa Electron) Processing Specifications
• V.I.P. System SMS Processing Specifications (U.S.)

Chapter 5 Check Acceptance Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
IN BRIEF 5-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4
Contracts With Check Acceptance Vendors. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .5-4
Processing Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4
Delivery Method for Check Approval Requests. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .5-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
RELATED MESSAGES 5-44
HOW CHECK ACCEPTANCE SERVICE WORKS

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
5-55
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
PROCESS FLOWS 5-55
Processing Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
MESSAGE FLOWS 5-66
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
KEY FIELDS GLOSSARY 5-77
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-
Check Acceptance Service


Chapter 5 Check Acceptance Service
5.1 IN BRIEF
The Check Acceptance Service allows merchants in the Visa U.S.A. (U.S.) region to
route check approval requests through VisaNet to selected check acceptance vendors.
One of five companies, Equifax Card Services (TeleCredit Los Angeles and TeleCredit
Tampa), ETC Scan (Deluxe Data Systems), JBS/NPC, State Street Bank, or TeleCheck,
can approve a check a customer uses at a merchant location through the Check
Acceptance Service. The vendor guarantees acceptance of the check by the drawee bank
and assumes responsibility for collection if the check is returned.
The Check Acceptance Service is available currently to acquirers in the

U.S. region only.
BASE I
SMS The Check Acceptance Service is available both to BASE I System acquirers
and to Single Message System (SMS) acquirers.
BASE I and SMS
A Participation in the Check Acceptance Service is optional for U.S. region

acquirers. The Check Acceptance Service is available to merchants whose
acquirers participate in the service.
Acquirer
5.3 SERVICE SUMMARY

The Check Acceptance Service enables acquirers to use VisaNet to route check approval
requests from the merchant site to a VisaNet-connected check acceptance vendor.
Check acceptance companies guarantee payment of the customer's check if their company
approves the check. Merchants and vendors establish the governing rules. VisaNet
performs only a routing function.
For basic information about routing through V.I.P., refer to Chapter 2, System
Fundamentals, and to Chapter 3, Introduction to Routing Services.


Service participants must meet the requirements stated in this section.
IMPORTANT
All participants that access VisaNet with a VisaNet Access Point (VAP) must have VAP software PS/2
Release 10.23 or greater to use the Check Acceptance Service.
5.4.1 Testing
Testing for Check Acceptance Service is mandatory for all new and existing acquirers that
want to participate in the service.
Testing ensures that the acquirer can send Check Acceptance Service authorization
requests (0100s) and can successfully process fields in Check Acceptance Service
responses (0110s).
The VisaNet Certification Management Service (VCMS) provides testing assistance for
Check Acceptance Service participants. Members can contact their Visa representatives to
make the arrangements.

Service participants should consider the following key points to benefit fully from the Check
Acceptance Service.
5.4.2.1 Contracts With Check Acceptance Vendors

Acquirers are responsible for executing agreements with check acceptance vendors.
Visa currently limits access to the Check Acceptance Service to the following vendors:
• Equifax Card Services (TeleCredit Los Angeles And TeleCredit Tampa)
• ETC Scan (Deluxe Data Systems)
• JBS/NPC
• State Street Bank
• TeleCheck
5.4.2.2 Processing Considerations

VisaNet has no system restrictions that prohibit the use of Check Acceptance Service
messages.
Acquirer centers collect funds by sending checks through a clearing process that is external
to VisaNet.
5.4.2.3 Delivery Method for Check Approval Requests

Acquirers can send check acceptance requests directly from their host. If an acquirer
chooses to send requests from its host, it must modify its application programs and its host
interface to create check acceptance requests that it can send through its VisaNet Access
Point (VAP) to the VisaNet Interchange Center (VIC).

Service monitoring is not available for the Check Acceptance Service.
5.5 RELATED MESSAGES

The following messages pertain to the Check Acceptance Service:

Chapter 5 How Check Acceptance Service Works
Request—This message is a request to confirm the availability of funds

and to verify the cardholder's identity. Acquirers use this message for check acceptance
transactions when the acquirer has an agreement with one of the VisaNet-connected check
acceptance vendors. For the Check Acceptance Service, an 0100 message requests
the guarantee of a customer's check from a check acceptance vendor. A standard
check-clearing process collects the check.
Response—This message is a response to an 0100 message.

For the Check Acceptance Service, the 0110 response includes the check authorization
information from the vendor. If appropriate, it includes the vendor's error reason code in
Field 48—Additional Data—Private.
5.6 HOW CHECK ACCEPTANCE SERVICE WORKS

U.S. acquirers can process check acceptance requests with BASE I or SMS authorization
messages using VisaNet-connected check acceptance vendors only.
When an acquirer signs an agreement with a check acceptance vendor, the vendor agrees
to assume liability for any check that a drawee refuses.
The following sections explain the Check Acceptance Service process flow and message
flow.
5.7 PROCESS FLOWS

Most check acceptance requests originate at electronic authorization terminals and involve
a VAP. Any participating acquirer, however, can originate check acceptance requests.
When a customer presents a merchant with a check, the merchant sends the check
information to the acquirer through an electronic terminal that scans bank account and
customer information from the check. The merchant keys in the amount of the check.
The acquirer generates a check acceptance request based on the information submitted
by the merchant and sends it to V.I.P., which then processes the request and forwards it
to a check acceptance vendor. The check acceptance vendor returns an acceptance or
a denial response to the merchant using the same path.
Refer to Chapter 6, Gateway Services, for information about VisaNet gateways to check

acceptance vendors.
The acquirer collects the funds by sending the checks through a separate clearing process.
If a check acceptance vendor approves a check that is subsequently not paid, the vendor
assumes liability based on agreements made with the acquirer center.
NOTE
Check acceptance transactions cannot be reversed.

Figure 5-1 illustrates the process flow for check acceptance transactions.
Figure 5-1 Check Acceptance Process Flow
Acquirer V.I.P. Check Acceptance Vendor
The acquirer sends V.I.P. V.I.P. performs standard The check acceptance
the Check Acceptance request processing and vendor sends back an
Service request. forwards the Check approval or denial
Acceptance Service response.
information to the check
acceptance vendor.
V.I.P. forwards the check

acceptance vendor’s
response to the acquirer.
5.7.1 Processing Methods

Acquirer centers can send check acceptance requests directly from their host through their
VisaNet access device.
For SMS-connected acquirers, VisaNet routes requests to BASE I and then on to the
check acceptance vendors.
5.8 MESSAGE FLOWS

The acquirer generates an 0100 authorization request. The V.I.P. System forwards
the request based on the vendor ID specified in Field 100—Receiving Institution
Identification Code. The vendor sends back its response through V.I.P. in an 0110
authorization response message with information about the check approval indicated
in Field 48, Usage 3—Error Reason Text in check acceptance responses or in
Field 48, Usage 15—Billing/Reporting/Other Data for Visa Use (the field that includes
Usage 6—Check Acceptance Information, in which vendors can place check approval
codes).
If the vendor is unavailable, V.I.P. returns an 0110 response to the acquirer with response
code 91 (destination unavailable) in Field 39—Response Code, indicating that V.I.P. could
not process the request. Stand-in processing (STIP) is not available for check acceptance
requests.

Figure 5-2 illustrates the Check Acceptance Service message flow.
Figure 5-2 Check Acceptance Message Flow
Acquirer V.I.P. Check Acceptance Vendor
0100 Request 0100 Request 0100 Request

Field 3: Processing Code = Field 3: Processing Code = Field 3: Processing Code =
030000 030000 030000
Field 4: Amount, Transaction Field 4: Amount, Transaction Field 4: Amount, Transaction
Field 25: POS Cond. Code = 10 Field 25: POS Cond. Code = 10 Field 25: POS Cond. Code = 10
Field 32: Acquirer ID Field 32: Acquirer ID Field 32: Acquirer ID
Field 42: Card Acceptor ID Field 42: Card Acceptor ID Field 42: Card Acceptor ID
Field 49: Currency Code (SMS) Field 49: Currency Code (SMS) Field 49: Currency Code (SMS)
= 840 = 840 = 840
Field 63.1: Network ID (SMS) Field 63.1: Network ID (SMS) Field 63.1: Network ID (SMS)
Field 73: Date, Action Field 73: Date, Action Field 73: Date, Action
Field 100: Vendor ID Field 100: Vendor ID Field 100: Vendor ID
Field 102: Customer ID Field 102: Customer ID Field 102: Customer ID

Field 3: Processing Code = Field 3: Processing Code = Field 3: Processing Code =
030000 030000 030000
Field 4: Amount, Transaction Field 4: Amount, Transaction Field 4: Amount, Transaction
Field 38: Authorization Field 38: Authorization Field 38: Authorization
Identification Response Identification Response Identification Response
Field 39: Response Code Field 39: Response Code Field 39: Response Code
Field 44.1 Response Source/ Field 44.1 Response Source/ Field 44.1 Response Source/
Reason Code = 4 or 5 Reason Code = 4 or 5 Reason Code = 4 or 5

Field 48 Usage 3: Error Reason Field 48 Usage 3: Error Reason Field 48 Usage 3: Error Reason
Field 48 Usage 15: Billing/Re- Field 48 Usage 15: Billing/Re- Field 48 Usage 15: Billing/Re-
porting/Other Data for Visa Use porting/Other Data for Visa Use porting/Other Data for Visa Use
Field 102: Customer ID Field 102: Customer ID Field 102: Customer ID

This section describes key fields associated with Check Acceptance Service transactions.
The fields required by check acceptance vendors to process check approvals are subsets of
the fields used by card issuers in a card authorization request. However, check acceptance
requests have unique requirements that do not apply to card authorization requests.

IMPORTANT
For check acceptance requests, acquirers enter the cardholder ID in Field 102—Account Identification 1 rather
than in Field 2—Primary Account Number. Also, acquirers should enter the driver's license or the Visa card
expiration date in Field 73—Date, Action.
Field 3—Processing Code

This field identifies the customer transaction type and the customer account types, if any,
specified by the transaction. The processing code must be 030000 (check acceptance).
Field 4—Amount, Transaction

Field 4 specifies the check acceptance transaction amount in U.S. dollars. The amount
in an original authorization request excludes any transaction fees. No decimal point
appears in this field; the decimal place is implied, based on the currency.
Field 25—Point-of-Service Condition Code

This field describes the condition under which the transaction takes place at the point
of sale or point of service (POS). POS condition code 10 indicates that the customer's
identify has been verified for a check acceptance transaction. This code is not used for
Visa and Visa Electron card transactions.

This code identifies the financial institution acting as the acquirer for this customer
transaction.
Field 38—Authorization Identification Response

Approval responses to check acceptance requests require field 38 when the vendor
00). VisaNet allows all zeros or all spaces.
approves a transaction (field 39 contains 00
Field 39—Response Code

Field 39 contains a code that defines the response to a request or identifies the
message disposition. Vendor codes in check acceptance responses include: 00 00, 01
01, 03
03,
05, 06
05 06, 13
13, 14
14, 54
54, 57
57, 80
80, 91
91, and 96
96.
Field 42—Card Acceptor Identification Code

All BASE I and SMS 0100 check acceptance requests require this field.
Field 44.1—Response Source/Reason Code

Only Visa uses this field. It contains a Visa-defined advice or response reason code or
an authorization source code that identifies the entity responding to a request. Valid
values for check acceptance transactions are 4 or 5 (when the issuer is unavailable).
Field 48, Usage 3—Error Reason Text in Check Acceptance Responses

When a check acceptance vendor detects an error in an authorization request, it has
the option to use this field in an 0110 response for text that explains the error condition
in field 39. The field contains the exact text that the vendor wants displayed on the
terminal at the POS.
Field 48, Usage 15—Billing/Reporting/Other Data for Visa Use (the new field name that
includes Usage 6—Check Acceptance Information)
For BASE I acquirers, this field indicates the source of the check acceptance request (a
center host) in an 0100 request.

Field 49—Currency Code, Transaction

This is a required field in SMS check acceptance requests. The code must be 840
(U.S. dollars).

Field 63.1 is a key field only for SMS check acceptance requests. This field contains
a code that specifies the network that V.I.P. is to use to transmit the message, which
determines the program rules that apply to the transaction. Acquirers must specify 0002
for the network ID in this field.
Field 73—Date, Action (Optional)

Visa defines this field for check acceptance transaction expiration dates. Whenever a
check acceptance vendor requires a date (for instance, the expiration date of a driver's
license or the expiration date on a card used for ID) in its requests, acquirers must place
it in this field. The date may be in any format selected by the vendor, with lead-zero-fill if
needed. When no date is available at the POS, acquirers omit this field.
Field 100—Receiving Institution Identification Code

This field identifies the vendor for check acceptance requests. It does not appear in
0110 responses. Vendor codes are:
Table 5-1 Check Acceptance Vendors
Vendor
Code Company Routing ID
1 TeleCredit, Los Angeles (Equifax Card Services) 894300
2 Telecheck 861400
3 JBS/NPC 810000
4 TeleCredit, Tampa (Equifax Card Services) 894400
5 State Street Bank 862000
6 ETC Scan (Deluxe Data Systems) 813500
Field 102—Account Identification 1

This field must appear in all check acceptance requests and responses. Acquirers must
place the customer ID (for instance, the driver's license number) in this field even when
the cardholder uses a card with a standard account number for identification.

For more information about the Check Acceptance Service, refer to the following
documents:
• V.I.P. System BASE I Technical Specifications, Volume 1 and Volume 2
• V.I.P. System SMS POS (Visa & Visa Electron) Technical Specifications, Volume 1
and Volume 2


Chapter 6 Gateway Services
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
IN BRIEF 6-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
Gateway Services
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
HOW GATEWAY SERVICES WORKS 6-55
Field 62.17—Gateway Transaction Identifier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
Gateway Governing Contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
Available Gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-
PROCESS FLOWS 6-77
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-

Gateway Services

Chapter 6 Gateway Services
6.1 IN BRIEF
Both the BASE I System component and the Single Message System (SMS) component
of the V.I.P. System have connections, or gateways, to various other systems and
networks. Gateway Services enable acquirers to obtain authorizations for non-Visa-brand
transactions through the same VisaNet connections they use for Visa transactions.
Gateway Services
With Gateway Services, acquirers and merchants can route all terminal traffic to V.I.P.,
which converts non-Visa-brand transactions to the appropriate network's message format
and then routes them for responses. The conversion process includes transferring data
between Visa fields and fields in the other network's message format. The service also
enables issuers to use their V.I.P. System connections to receive requests from other
networks or services.
Gateway Services are available to members in all Visa regions.
BASE I
SMS Gateway Services are available both to BASE I System users and to Single
Message System (SMS) users.
BASE I and SMS
I
Participation in Gateway Services is optional for issuers.
Issuer
A
Participation in Gateway Services is optional for acquirers.
Acquirer
6.3 SERVICE SUMMARY

As described in “Routing Basics” in Chapter 2, System Fundamentals, V.I.P. is responsible
for routing messages to their proper destinations. Message destinations include:
• The other V.I.P. System component (BASE I or SMS)
• BASE I issuer centers

• SMS issuer centers

• Networks outside of VisaNet
If the destination is a VisaNet endpoint, V.I.P. routes the message to its appropriate
destination. If the destination is a system or a network outside of VisaNet, V.I.P. uses
Gateway Services to reformat the message, if necessary, and to deliver it to the other
system or network. Message format conversion occurs based on the format of the receiving
station; for instance, if the receiving station is a MasterCard station, V.I.P. converts the
message to Banknet format.
Gateway Services provide a number of card authorization gateways and gateway services,
Gateway Services
including:
• ATM Gateways
• Check Acceptance Gateways (for the U.S. region only)
• Credit Gateway Services
• Fuel Gateway
• PIN Debit Gateway (PDG) and PIN Debit Gateway Services (PDGS)
• Private-Label Gateways
NOTE
V.I.P. processes check acceptance requests only for issuers that participate in the Check Acceptance Service.
See Chapter 5, Check Acceptance Service, for information about check acceptance requests and this service.
Gateway Services can process:

• Non-bank cards (for instance, cards issued by oil companies).
• MasterCard POS transactions, including contactless, for MasterCard issuers connected
to Banknet (the MasterCard network). For security reasons, VisaNet does not process
PIN-based ATM MasterCard transactions destined for Banknet. However, the Visa
PIN/No-PIN Split Routing Service or the Visa Shortest Online Path (VSOP) Service can
process PIN-based POS or ATM MasterCard transactions. See Chapter 8, PIN/No-PIN
Split Routing Service, for information about this service. See chapter 10 for information
about the VSOP Service.
• Proprietary cards (for instance, ATM cards issued by financial institutions, savings and
loans, and credit unions).
• Private-label cards (for instance, cards issued by specialty stores and department stores).
• Electronic Benefits Transfer (EBT) transactions. See Chapter 7, PIN Debit Gateway
Service (PDGS), for information about EBT.
Gateway Services provide a variety of capabilities, including:
• Authorization access to non-Visa networks.
• Format conversion necessary before switching messages between various networks,
enabling acquirers to use one message format for all messages.
• Use of a single VisaNet connection point, which enables:
- Acquirers to support multiple card types and payment accommodations using their
existing VisaNet (Visa card, Interlink, and Plus) connections.
- Merchants to process transactions for a range of card types using a single terminal.
• Full redundancy to ensure that back-up, alternate switching, and routing capabilities
are available.

• Support for the Priority Routing Service for SMS acquirers that access multiple networks.
These acquirers can have V.I.P. choose the most cost-effective path for their transactions.
See Chapter 9, Priority Routing Service, for information about this service.
• V.I.P. stand-in processing (STIP) capabilities for some card products when issuers or
issuer networks are unavailable.
• Access to single-message processing capability required by regional and national ATM
and POS networks.

Gateway Services are available both to BASE I acquirers and to SMS acquirers.
Gateway Services
Participation in Gateway Services requires member enrollment with Visa or non-Visa
card issuers, or with both. Contractual enrollment agreements specify the acquirer's
responsibilities when accepting cards and processing transactions for non-Visa institutions.
6.4.1 Testing
To test Gateway Services, members can contact their Visa representatives.

Visa does not require service monitoring before full participation in Gateway Services.
6.5 HOW GATEWAY SERVICES WORKS

V.I.P. maintains gateway and format information about linked networks in its system tables.
V.I.P. uses this internal data along with data in messages to route transactions to the
appropriate destinations. When V.I.P. receives a request from an acquirer that is destined
for a non-Visa issuer, V.I.P. reformats the request according to the recipient's gateway
requirements (if necessary) and sends it through the gateway. Depending on inter-network
agreements, the reformatting process can include transferring data from the Visa-format
message to the other network's message format.
NOTE
For PIN Debit Gateway Service (PDGS) and Electronic Benefits Transfer (EBT) transactions, the external
gateway reformats the message rather than V.I.P.
V.I.P. receives the issuer's response, reformats it as a Visa response, and forwards it to
the acquirer. VisaNet may perform other services as indicated in this chapter, such as
forwarding or building and forwarding Field 62.17—Gateway Transaction Identifier,
in American Express, Discover, and MasterCard responses.
NOTE
While V.I.P. does reformat non-Visa-card transactions into the Visa-card format, acquirers are still responsible
for ensuring that the transactions include all required fields and field values for the type of message sent.
For instance, acquirers processing MasterCard transactions through VisaNet must include Field 42—Card
Acceptor Identification Code in all 0100 and 0110 authorization messages and in 0400 and 0410 reversal
messages.
V.I.P. usually routes requests destined for non-bank institutions to non-Visa processors.
For these requests, if the processor is unavailable, V.I.P. returns the transactions to the
acquirer with response code 01 (refer to issuer) in Field 39—Response Code.
Proprietary cards and private-label cards receive the full range of routing and processing
options. However, stand-in processing is not available for PDGS and EBT transactions.

Chapter 6 How Gateway Services Works
The BASE I credit POS gateways do not provide stand-in processing for MasterCard or
Diners Club transactions. However, they do provide limited stand-in processing support for
Discover transactions by specific account ranges determined by Discover. Members can
contact their Visa representatives for more information about V.I.P. stand-in processing
support for non-Visa-card transactions.
NOTE
SMS POS messages sent through Gateway Services that originate from entities that do not participate in
the Priority Routing Service must specify the gateway in Field 63.12—Sharing Group Code to identify the
destination network. PIN Debit Gateway Service (PDGS) participants using the Priority Routing Service
0000) must also include field 63.12.
(field 63.1 contains 0000
Gateway Services
Members can contact their Visa representatives for more detailed information and for
available options.
6.5.1 Field 62.17—Gateway Transaction Identifier

V.I.P. generates field 62.17 for American Express and MasterCard responses to transmit
transaction information to acquirers. For Discover responses, if issuers populate the field,
V.I.P. forwards it to acquirers that choose to receive it.
• For American Express, the American Express Global Network source data for the Visa
0110 response comes from Field 31—Acquirer Reference Data in the American Express
response.
• For MasterCard, the MasterCard Interchange Compliance (MIC) source data for the Visa
0110 response comes from DE 63 in the MasterCard response.
• For Discover, issuers supply the contents of the field.
NOTE
Acquirers that process non-Visa transactions should be prepared to receive field 62 subfields, for instance,
field 62.17, in response messages. Acquirers must support new financial network codes in field 62.17.
Refer to the Credit Gateway Service Cross-Reference Guide for further information about
how V.I.P. converts VisaNet, MasterCard, and American Express messages.
6.5.2 Gateway Governing Contracts

A contract between the individual company or association and Visa governs each gateway.
Visa International Operating Regulations, the individual company's operating regulations,
and the terms of agreement between both parties determine processing specifications
for each gateway.
6.5.3 Available Gateways

Table 6-1 lists the credit and debit gateways available to BASE I users and to SMS users.
Table 6-1 BASE I and SMS Gateways
Network Type BASE I SMS Availability

ACCEL POS ✓ U.S. region only
AFFN POS ✓ U.S. region only
Alaska Option POS ✓ U.S. region only
American Express Credit ✓ Varies by region

Table 6-1 BASE I and SMS Gateways (continued)

Network Type BASE I SMS Availability
Bankmate POS ✓ U.S. region only
Cash Station POS ✓ U.S. region only
CIRRUS ATM ✓ ✓ U.S. region only
Diners Club International (DCI) Credit ✓ Varies by region
Discover Network Credit ✓ U.S. region only
EBT Gateway POS and ✓ U.S. region only
Gateway Services
ATM
eFunds POS ✓ U.S. region only
Interlink POS ✓ U.S. region only
Japan Credit Bureau (JCB) Card Credit ✓ ✓ Varies by region
MAESTRO POS ✓ Varies by region
MasterCard (Banknet Network) POS and ✓ ✓ Varies by region
Credit
Money Station POS ✓ U.S. region only
NYCE POS ✓ U.S. region only
Proprietary and private-label cards Credit ✓ Varies by region
PULSE POS ✓ U.S. region only
Shazam POS ✓ U.S. region only
Societe Internationale International ✓ All Visa regions
de Telecommunications Credit
Aeronautiques (SITA) Authorization
STAR Northeast POS ✓ U.S. region only
STAR Southeast POS ✓ U.S. region only
STAR West POS ✓ U.S. region only
Tyme POS ✓ U.S. region only
NOTE
Visa maintains direct connections with selected debit networks and connects to other debit networks
through intermediate third-party gateways such as Elan Financial Services. Visa uses the Elan gateway for
transactions involving networks such as Accel, AFFN, Alaska Option, CU-24, EBT (POS), Maestro, and NETS.
Field 63.1—Network Identification Code contains the network ID. Refer to the field 63.1
information in the pertinent V.I.P. technical specifications manual for a list of network IDs.
6.6 PROCESS FLOWS

V.I.P. forwards transactions to the appropriate network gateway based on the account
number, the network identification, acquirer reference data, and other routing information
contained in the message or stored in the acquirer's system files.
V.I.P. routes Interlink transactions directly to Interlink issuers.

For Plus transactions, VisaNet handles clearing and settlement in one of two ways,
depending on the card type and on the acquirer. One of the following sets of rules govern
the processing of the transaction:
• Visa rules, regulations, and pricing structures, which VisaNet uses when cardholders
make the transactions with Visa or Visa Electron cards bearing the Visa wordmark or with
Visa Electron cards bearing the Visa wordmark and the Plus symbol.
• Plus rules, regulations, and pricing structures, which VisaNet uses when cardholders
make the transactions with proprietary cards or with Visa Electron cards bearing only the
Plus symbol.
Before delivery, V.I.P. converts the messages to the formats required by each network.
Gateway Services
However, for PIN Debit Gateway Service (PDGS) and EBT transactions, the external
gateway reformats the message rather than V.I.P.
Figure 6-1 illustrates the Gateway Services process flow.

NOTE
All message types supported by Gateway Services follow the processing path shown in Figure 6-1.
Figure 6-1 Gateway Services Process Flow
Acquirer V. I.P. VisaNet Issuer

Transactions Destined
for VisaNet Endpoints
Gateway Services
Transactions Destined for
Networks Other Than VisaNet
VisaNet
Gateway
External
Network
Non-VisaNet Issuer Non-VisaNet Issuer

For additional information about Gateway Services, refer to the following documents:
• V.I.P. System SMS ATM Technical Specifications, Volume 1 and Volume 2
• V.I.P. System SMS Interlink Technical Specifications

and Volume 2
• Visa Global ATM Planning Guide
• Credit Gateway Service Cross-Reference Guide
• VisaNet POS Services Business Guide
• VisaNet POS Services Technical User's Guide
• VisaNet PIN Debit Gateway Small Merchant Market Implementation Guide
• SITA Sales Guide
Gateway Services

Chapter 7 PIN Debit Gateway Service (PDGS)
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
IN BRIEF 7-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
PIN Debit Gateway Service Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
RELATED MESSAGES
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
7-44
PIN Debit Gateway Service (PDGS)

WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
HOW PIN DEBIT GATEWAY SERVICE (PDGS) WORKS 7-55
Report and File Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
Settlement of PDGS Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
Reconciliation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
Billing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
PROCESS FLOWS 7-77
PIN Debit Gateway Processing Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
Assessing Surcharges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
MESSAGE FLOWS 7-13
13
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
18
(EBT).. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
ELECTRONIC BENEFITS TRANSFER (EBT) 7-19
19
Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19
Related Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19
EBT Processing Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20
EBT.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
KEY FIELDS GLOSSARY FOR EBT 7-20
20
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-
21


Chapter 7 PIN Debit Gateway Service (PDGS)
7.1 IN BRIEF
The PIN Debit Gateway Service (PDGS) enables merchants in the Visa U.S.A. (U.S.)
region to accept payments customers make with debit cards, ATM cards, and credit
cards bearing a national or regional debit point-of-sale or point-of-service (POS) mark.
The service also supports Electronic Benefits Transfer (EBT) transactions through an ATM
gateway for selected EBT states.
Merchants send transactions that cardholders initiate with these cards (accessing them
with personal identification numbers [PINs]) to VisaNet. Merchants can also submit U.S. bill
payment transactions cardholders submit without PINs for ACCEL, STAR, NYCE, PULSE,
and other PDG networks. The Single Message System (SMS) component of V.I.P. routes
these transactions through the PIN Debit Gateway (PDG) to the appropriate POS debit
network for delivery to the issuer.

The PIN Debit Gateway Service (PDGS) is available to acquirers in the U.S.
region.
BASE I
SMS PDGS is available to SMS acquirers.
SMS only
A
Participation in PDGS is optional for SMS POS acquirers in the U.S. region.
Acquirer
7.3 SERVICE SUMMARY

The PIN Debit Gateway Service (PDGS) enables U.S. region merchants to accept
payments that cardholders make with debit cards and ATM cards bearing a national or
regional POS debit mark and access with a PIN. PDGS also allows participants to accept
bill payment transactions cardholders submit without PINs for ACCEL, STAR, NYCE,
PULSE, and other PDG networks. The V.I.P. System routes these transactions through the
VisaNet PIN Debit Gateway to the appropriate POS debit network.
VisaNet settles transactions with the merchant's acquirer as a part of VisaNet settlement
and processes exception items for PDGS participants.

To use PDGS, a merchant must access VisaNet directly with an SMS VAP, access VisaNet
indirectly, or access VisaNet through its acquirer.
7.3.1 PIN Debit Gateway Service Options

Routing options give merchants flexibility to access the various POS debit networks.
There are three routing options available:
• The merchant can specify the network identification code to route transactions to the
selected network.
• SMS can determine the network using the acquirer priority list in the system tables.
Acquirers specify their list in the Customer Online Repository (CORE).
• SMS can determine the network using the share group priority transmitted in the online
message.
NOTE
SMS checks the debit BIN files to determine if there are issuer routing preferences for any of the networks
specified by the acquirer. If an issuer preference exists for one of the debit networks, SMS makes a routing
selection based on the issuer preference. If an issuer preference exists for more than one of the debit
networks or if no issuer preference exists, SMS makes a selection based on the acquirer’s routing priorities.
Refer to the routing services chapters in this manual for detailed information about available
routing options.

Participation in PDGS is optional for SMS POS acquirers in the U.S. region. Participation
in PDGS may require member enrollment with Visa and with the POS debit networks.
Each network has a contractual enrollment agreement that specifies the acquirer's
responsibilities when accepting cards and processing transactions.
7.4.1 Testing
Visa requires testing for this service for acquirers and for merchant access points that have
not been tested to send and to receive SMS POS transactions.
The VisaNet Certification Management Service (VCMS) provides testing assistance

for PDGS participants. Members can contact their Visa representatives to make
the arrangements.

Service monitoring is not available for PDGS.

Members can contact their Visa representatives to make all service activation
arrangements.

The following messages pertain to PDGS:
• 0100 preauthorization
• 0200 purchase, purchase with cashback, and U.S. bill payment
• 0200 resubmission
• 0200 and 0220 merchandise returns or credits
• 0220 adjustment
• 0220 representment

Chapter 7 How PIN Debit Gateway Service (PDGS) Works
• 0220 preauthorization completion

• 0400 preauthorization reversal
• 0400 and 0420 reversal
• 0422 chargeback
• 0520 reconciliation
• 0800 network management
NOTE
Not all POS debit networks support each of these transactions; support of these transactions is optional.
Check with each network to verify the type of cardholder transactions it supports. In addition, the merchant
assumes full responsibility for any losses as a result of denied or unprocessed transactions.
7.6 HOW PIN DEBIT GATEWAY SERVICE (PDGS) WORKS

Participating merchants receive and validate POS transactions. They specify the network
to which V.I.P. is to route the transactions in one of three ways:
• By placing the appropriate network identification code in Field 63.1—Network
Identification Code.
• By specifying the acquirer's priority routing list in the system tables (through CORE).
• By specifying the share group priority in the online message.
SMS performs all required transaction processing and routes the transactions to the

appropriate network through the PIN Debit Gateway (PDG). See Chapter 6, Gateway
Services, for information about VisaNet gateways.
SMS receives the responses from the issuers through the debit gateways and returns the
responses to the acquirers for delivery to the merchants. Merchants have two VAP options:
• Direct Exchange (DEX)—Directly-connected merchants can use DEX to access VisaNet.
(All directly-connected merchants in the U.S. region use DEX.)
• Visa Extended Access Servers (EA Servers)—Directly connected merchants in all other
Visa regions can use DEX, or EA Servers to access VisaNet. (If they are not directly
connected to VisaNet, they can connect through their acquirer or acquirer processor
VAPs.
For information about VisaNet Access Points (VAPs), refer to About This Manual for
documentation. Members can contact their Visa representatives for information about
VisaNet Access Points (VAPs).
V.I.P. supports manual adjustments for small network PDG transactions by allowing
0422 fee collection and funds disbursement messages to enter through Visa Resolve
Online (VROL). The current SMS Universal Message Format (UMF) feed to RSI transmits
all manual adjustments.

Chapter 7 How PIN Debit Gateway Service (PDGS) Works
Table 7–1Table 7-1 lists the fee collection and funds disbursement reason codes that
identify the manual adjustments for each small network.
Table 7-1 Fee Collection and Funds Disbursement Reason Codes
Adjustment Message Reason Code

ACCEL Manual Adjustments 6181
AFFN Manual Adjustments 6182
ALASKA Option Manual Adjustments 6183
CU-24 Network Adjustments 6184
EBT Manual Adjustments 6185
MAESTRO Manual Adjustments 6186
NETS Manual Adjustments 6187
7.6.1 Report and File Delivery

VisaNet creates settlement reports and detailed transaction reconciliation data (raw data)
files for PDGS transactions. Raw data files reflect the authorization, clearing, and
settlement activity for each business day and acquirers can use them to perform transaction
reconciliation. VisaNet constructs the files from the SMS transaction logs it uses to
calculate the acquirer's VisaNet settlement position.
VisaNet delivers these reports and raw data files to acquirers in one of several ways.
Members can choose methods for receiving reports and raw data, and for routing files.
Options vary by region. Members can contact their Visa representatives for information
about available options.
7.6.2 Settlement of PDGS Transactions

VisaNet settles PDGS transactions each day through settlement processing. Settlement
of fees and charges includes Visa charges and network pass-through fees and charges.
VisaNet moves funds Monday through Friday. Settlement details appear on the member's
monthly integrated bill sent from the Global Member Billing System (GMBS).
The acquirer receives settlement for PDGS transactions as part of standard VisaNet
settlement processing. Visa bases daily settlement for PDGS transactions on an 3:00 p.m.
Pacific standard time (2:00 p.m. during Pacific daylight savings time) cutoff. VisaNet
records PDGS transactions occurring after the cutoff in the next business day's activity.
7.6.3 Reconciliation
Reconciliation involves the comparison of merchant PDGS settlement data with VisaNet's
record of transaction activity. Both VisaNet and members use reconciliation to:
• Validate the acquirer's daily VisaNet settlement with the acquirer's daily merchant
account funding position.
• Identify differences between the VisaNet transaction record and the merchant's
transaction record to highlight potential exception items.
• Match information about each transaction from both sources of data. Unmatched
transactions may require further research and adjustments through exception transaction
processing.

7.6.4 Billing
VisaNet and debit network fees and charges apply to PDGS transactions. GMBS bills
acquiring members monthly on integrated bills.
Some networks require fee settlement with the network. VisaNet does not bill the fees for
these networks. Members must check with each network to determine its billing policy.
For more information about VisaNet fees, refer to the Visa International Operating
Regulations.
7.7 PROCESS FLOWS

The PIN Debit Gateway Service (PDGS) processing flow consists of the following steps:
1. A POS device initiates and identifies the transaction at the point of sale when the
merchant, clerk, or cardholder presses the ATM or Debit key or the terminal decides
it is a debit transaction. The merchant, clerk, or cardholder slides the card through
the magnetic stripe reader and enters the purchase amount. The cardholder enters
a personal identification number (PIN). In the case of bill payment transactions,
the merchant receives the transaction over the Internet or acts according to
pre-established cardholder instructions.
2. The merchant's or the acquirer's host system receives and validates the financial

request message from the POS or creates the transaction according to cardholder
instructions, ensures compliance with VisaNet standards, routes the message to
VisaNet, and logs the message.
3. SMS receives the financial request message and performs system transaction request
processing.
4. Before SMS routes the message to the appropriate gateway, it checks the value in
0000, the acquirer or
Field 63.1—Network Identification Code. If the field contains code 0000
the merchant participates in the Priority Routing Service. SMS validates the programs
available to the acquirer and makes a selection based on the sharing group order
specified by the value in field 63.12. If the transaction contains values in field 63.12,
SMS validates them against the acquirer's priority list in the system tables and checks
whether there are conflicting issuer preferences or no preferences to determine routing.
If the transaction contains no values in field 63.12, SMS uses the acquirer's priority list
in the system tables to determine routing.
SMS checks the debit BIN files to determine if there are issuer routing preferences for
any of the networks specified by the acquirer. If an issuer preference exists for one of
the debit networks, SMS makes a routing selection based on the issuer preference.
If an issuer preference exists for more than one of the debit networks or if no issuer
preference exists, SMS makes a selection based on the acquirer’s routing priorities.
Once it identifies the appropriate network, SMS replaces code 0000 in field 63.1 with
0012,
the appropriate network ID code (0012
0012 for instance). SMS then routes the transaction
request to the POS debit network through the VisaNet Debit Gateway or through the
PIN Debit Gateway.
NOTE
If VisaNet is to route the transaction request to Interlink, SMS routes it directly to the issuer because SMS
is the Interlink routing switch.

If the card is not eligible for use at the merchant location, SMS returns a message to the
originator indicating that the card does not have a POS debit mark that the merchant
location accepts.
5. The card issuer approves or declines the transaction. The appropriate network returns
the issuer's response to the VisaNet Debit Gateway or to the PIN Debit Gateway, which
routes the response to SMS.
6. SMS accepts the response and performs system transaction response processing.
It matches the response with the original financial request and performs settlement
for approved transactions.
7. SMS routes the response to the acquirer's or the merchant's host system.
8. The merchant or the acquirer receives the response.
9. The POS device displays the approval response and generates a receipt as appropriate.
If the transaction cannot be completed, the system that detects the error sends a
reversal message to SMS. SMS sends the reversal message through the PIN Debit
Gateway to the issuer to credit the cardholder's account.
Acquirers can use Visa Resolve Online (VROL), or an exception item processing system
that communicates with VisaNet to process exception transactions. Visa Resolve Online
(VROL) sends and receives exception transactions between the acquirer's back-office staff,
VisaNet, the debit POS networks, and the issuers.

Figure 7-1 illustrates the basic PIN Debit Gateway Service (PDGS) transaction process flow.
Figure 7-1 PIN Debit Gateway Service (PDGS) Process Flow
Merchant Acquirer/Processor V.I.P. Interlink Issuer

Transactions Destined
for Interlink Endpoints
Transactions Destined for

VisaNet-Connected
Networks Other Than VisaNet
Merchant (MDEX)
Exception Processing System,
Visa Exceptions, or Visa Resolve Online

PIN Debit Gateway
External
Network
Non-VisaNet Issuer Non-VisaNet Issuer
7.7.1 PIN Debit Gateway Processing Rules

The following processing rules apply to PDGS transactions:

• Visa does not allow priority routing, for which the network ID code in field 63.1
0000, for adjustments, chargebacks, representments, preauthorization completions,
is 0000
resubmissions, or any of their related reversals.
• Visa also does not allow priority routing in 05xx, 06xx, and 08xx messages.
• Participants must use the value from the original 0210 response in all exception items
and in their responses.
Table 7-2 lists the rules governing the field values for specified transactions.
Table 7-2 Field Values for PDGS by Transaction Type
Transaction Field Number and Name Rule

Preauthorization (0100) Field 28—Amount, Transaction Fee This value is conditional.
Field 35—Track 2 Data This value is required.
Field 52—Personal Identification This value is required except in bill
Number (PIN) Data payment transactions.
Field 53—Security-Related Control This value is required except in bill
Information payment transactions.
Field 54—Additional Amounts Contains account balance information.
Field 61.1—Other Amount, Transaction Contains the cashback value.

Field 63.1—Network Identification Code The value can be 0000 for Priority
Routing or can be the 4-digit network ID.
Field 63.2—Time (Preauth Time Limit) 0002.
The value must be 0002
Field 63.10—Gateway Merchant Data This value is required.
Field 63.11—Reimbursement Attribute This value is required.
Field 63.12—Sharing Group Code This value is optional if Priority Routing
0000).
Service is used (network ID is 0000
Preauthorization Completion (0220) Field 11—System Trace Audit Number The value must be unique.
Field 28—Amount, Transaction Fee This value is conditional.
Field 37—Retrieval Reference Number This value must correlate with the value
in the 0100 preauthorization request.
Field 54—Additional Amounts Contains account balance information.
Field 61.1—Other Amount, Transaction Contains the cashback value.
Field 63.1—Network Identification Code The value must be copied from the
value in the 0110 response.

Table 7-2 Field Values for PDGS by Transaction Type (continued)

Original Financial Transaction (0200) Field 11—System Trace Audit Number The value must be unique.
Field 35—Track 2 Data This value is conditional.
Field 37—Retrieval Reference Number The value must be unique.
Field 61—Other Amounts This value is required if the transaction
requests cashback.
Field 63.1—Network Identification Code The value can be 0000 for priority
routing or can be the 4-digit network ID.
Field 63.11—Reimbursement Attribute This value is conditional.
Field 63.12—Sharing Group Code This value is optional if the network ID

0000.
code is 0000
Merchandise Return or Credit (0200) Field 11—System Trace Audit Number The value must be unique.
Field 37—Retrieval Reference Number The value must be unique.
Field 63.1—Network Identification Code The value can be 0000 for priority
routing or can be the 4-digit network ID.
Representment (0220) Field 28—Amount, Transaction Fee This field is required.
Field 48—Additional Data—Private This field is required.
Preauthorization Reversal (0400) Field 11—System Trace Audit Number The value must correlate with the value
in the 0100 preauthorization.
Field 28—Amount, Transaction Fee This field is conditional.
Field 37—Retrieval Reference Number The value must correlate with the value
in the 0100 preauthorization.
0100 preauthorization. The value can
be 0000 if the acquirer never receives a
response to the 0100 preauthorization
request.

Table 7-2 Field Values for PDGS by Transaction Type (continued)

Reversal of Preauthorization Field 11—System Trace Audit Number The value must correlate with the
Completion (0400) value in the 0220 preauthorization
completion.
Field 28—Amount, Transaction Fee This value is required.
Field 37—Retrieval Reference Number The value must correlate with the
value in the 0220 preauthorization
completion.
value in the 0220 preauthorization
completion.
Field 63.12—Sharing Group Code This value is optional if the network ID
0000.
code is 0000
Field 90—Original Data Elements This value is required. The message
contains field 7 and field 11 values from
the original 0100 message.

Chargeback (0422) Field 28—Amount, Transaction Fee This field is required.
Field 63.10—Gateway Merchant Data This field is required.
7.7.1.1 Assessing Surcharges

Acquirers participating in the PIN Debit Gateway Service (PDGS) can use
Field 28—Amount, Transaction Fee in 0100 and 0200 POS requests for surcharge
amounts, depending on specific debit network requirements. Visa does not allow
surcharges on Electronic Benefits Transfer (EBT) food transactions. (Visa does allow
surcharges on cash benefits.) VisaNet adds the surcharge to or subtracts it from the
field 4 amount in the request to determine the actual amount of the purchase. If field 28 is
present in a request, it must be present in the response, and in any reversal, adjustment,
chargeback, or representment and their advices.
V.I.P. declines a surcharge-based transaction if it involves an EBT food stamp

transaction. V.I.P. also declines a surcharge-based transaction if the issuer has not
successfully completed testing for receiving field 28: the field 39 decline response code
B2—Surcharge Amount Not Supported by Debit Network Issuer. In decline response
is B2
code cases, V.I.P. drops field 28 from advices to the issuer.
Field 28 is also valid for acquirer-assessed surcharges in Interlink transactions. Because

the surcharge amount is included in the transaction's field 4 amount, field 28 is informational
only and VisaNet does not use it for settlement purposes. V.I.P. removes it from the request
before it forwards the message to the issuer if the issuer cannot accept it, and restores
it in the response to the acquirer. For further information, refer to V.I.P. System SMS
Interlink Technical Specifications.

7.8 MESSAGE FLOWS

Figure 7-2 illustrates the message flow when the acquirer submits an 0100 preauthorization
request. V.I.P. forwards the request to the issuer. The issuer sends the 0110 response,
and V.I.P. forwards the response to the acquirer.
Figure 7-2 PDGS Preauthorization Request Message Flow
Merchant Acquirer V.I.P. Issuer
Cardholder 0100 Preauthorization 0100 Preauthorization 0100 Preauthorization

Transaction Request Request Request
Field 35 Field 28 (conditional) Field 28 (conditional) Field 28 (conditional)
Field 52 (conditional) Field 35 Field 35 Field 35

Field 53 (conditional) Field 42: Card Acceptor ID Field 42: Card Acceptor ID Field 42: Card Acceptor ID
Field 54 Field 49: Currency Code, Field 49: Currency Code, Field 49: Currency Code,
Field 61.1 Transaction Transaction Transaction
Field 63.1 Field 52 (conditional) Field 52 (conditional) Field 52 (conditional)
Field 63.10 Field 54 Field 54 Field 54
Field 63.12 (conditional) Field 61.1 Field 61.1 Field 61.1
Field 63.1 Field 63.1 Field 63.1
Field 63.12 (conditional)
Transaction 0110 Response 0110 Response 0110 Response

Response Field 28 (conditional) Field 28 (conditional) Field 28 (conditional)
Field 28 (conditional) Field 63.1 Field 63.1 Field 63.1
Field 39 Field 63.2 Field 63.2 Field 63.2
Field 44.5

Figure 7-3 illustrates the message flow when the acquirer submits an 0220 preauthorization
completion request. V.I.P. forwards the request to the issuer. The issuer sends the 0210
response, and V.I.P. forwards the response to the acquirer.
Figure 7-3 PDGS Preauthorization Completion Request Message Flow
Cardholder 0220 Preauthorization 0220 Preauthorization 0220 Preauthorization

Transaction Completion Request Completion Request Completion Request
Field 11 Field 11 Field 11
Field 54 Field 28 (conditional) Field 28 (conditional) Field 28 (conditional)

Field 63.12 (conditional)

Field 44.5
Field 44.8

Figure 7-4 illustrates the message flow when the acquirer submits an 0200 financial
Figure 7-4 PDGS Financial Request Message Flow
Cardholder 0200 Request 0200 Request 0200 Request

Transaction Field 11 Field 11 Field 11
Field 28 (conditional) Field 28 (conditional) Field 28 (conditional)
Field 54 Field 35 Field 35 Field 35
Field 61.1

Field 37 Field 37 Field 37
Field 63.10 Field 61.1 Field 61.1 Field 61.1

Field 44.5
Field 44.8

Figure 7-5 illustrates the message flow when the acquirer submits an 0200 merchandise
return or credit request. V.I.P. forwards the request to the issuer. The issuer sends the
0210 response, and V.I.P. forwards the response to the acquirer.
Figure 7-5 PDGS Merchandise Return or Credit Request Message Flow
Cardholder 0200 Request 0200 Request 0200 Request

Transaction Field 11 Field 11 Field 11
Field 28 (conditional) Field 28 (conditional) Field 28 (conditional)


Field 44.5
Field 44.8

Figure 7-6 illustrates the message flow when the acquirer submits an 0400 reversal
Figure 7-6 PDGS Reversal Request Message Flow
Cardholder 0400 Reversal 0400 Reversal 0400 Reversal

Transaction Request Request Request

(conditional)

Field 44.5
Field 44.8


This section describes key fields associated with the PIN Debit Gateway Service (PDGS).
Field 28—Amount, Transaction Fee

Field 28 contains the surcharge amount that the acquirer assesses for a POS
transaction, in the following format:
• Position 1: Prefix—The prefix identifies the surcharge as a credit or a debit. The code
in position 1 is either C (credit to cardholder) or D (debit to cardholder).
For account funding transactions (AFT) money transfer service fees, the code in
position 1 is D (debit to cardholder) for originals, reversals, and adjustments.
• Positions 2–9: Fee Amount—These positions contain the surcharge amount,
right-justified with leading zeros if necessary. The surcharge currency must match
the currency in field 4 and the field 49 currency code.
If this field is present in the request, it must be present in the response, and in
any reversal, adjustment, chargeback, or representment. VisaNet does not use
the surcharge for settlement purposes. It is not valid for EBT food stamp transactions.

Field 63.1 specifies the network VisaNet is to use to transmit the message.
Acquirers have the option of determining the network ID and specifying it in this field.
For acquirers that participate in the Priority Routing Service and set this field code
0000, the presence of field 63.12 is optional.
to 0000
Once the acquirer or V.I.P. sets the network ID, that same code must appear in every
subsequent message for that customer transaction.
Field 63.10—Gateway Merchant Data

This field contains two positions that define the financial institution identifier and the
merchant's pseudo American Bankers Association (ABA) number:
• Positions 1–4: Financial Institution Identifier
• Positions 5–13: Merchant Pseudo ABA Number
V.I.P. forwards the financial institution identifier and acquiring merchant data to the
PDGS issuer. This field is mandatory in all 01xx, 02xx, 04xx, and 06xx transactions
from merchants and from acquirers participating in PDGS.
Field 63.12—Sharing Group Code

Merchants and acquirers use this field to define the routing priority of POS financial
requests. The merchant location sends the sharing group code to SMS. The sharing
group code is left-justified and may contain up to 30 network designators. Systems must
fill all remaining positions to the right of the code with spaces.
A single printable character indicates each network that is available at the merchant
location. The character's string position indicates the network priority.
EXAMPLE
Setting the sharing groups to VGQ followed by 27 spaces means that the merchant's access priority
is set to VisaNet, to Interlink, and to Star West.

Chapter 7 Electronic Benefits Transfer (EBT)
7.10 ELECTRONIC BENEFITS TRANSFER (EBT)

Electronic Benefits Transfer (EBT) is a federally sponsored program under which a
nationwide program of card-accessed, electronically delivered, government-funded benefits
are issued through a federal-state partnership. Currently, EBT's primary function is the
electronic delivery of food stamps and cash benefits.
Issuers of EBT cards are called Government Designated Issuers (GDIs). The GDIs
brand their own cards, issue the cards, establish their own operating rules, and register
participating merchants.
The PIN Debit Gateway provides routing support for EBT transactions from VisaNet to each
GDI. EBT uses the full financial messages, the reversals, and the reporting structures that
currently support the PIN Debit Gateway Service (PDGS).
VisaNet support for the EBT program includes an EBT ATM gateway that enables acquirers
to route and process ATM transactions for selected EBT states. Acquirers may also
use a sharing group code in an ATM request that invokes the Priority Routing Service
to designate a unique routing priority for the transaction. The fields associated with the
EBT ATM gateway and the sharing group designation are:
• Field 63.1—Network Identification Code. The code for EBT is 0030 0030.

• Field 63.12—Network and Sharing Group Code. The EBT code is T.
The network identification code for EBT POS is 0029 and the sharing group code is K.
7.10.1 Participation Requirements

Basic regulations for all EBT states require that acquirers and merchants receive approval
from the Food and Consumer Services (FCS) department of the United States Department
of Agriculture (USDA) for food stamp acceptance. Each acquirer and each merchant must
register with the local GDI for food stamp and cash account acceptance. Merchants may
accept either benefit type or may accept both.
7.10.2 Related Messages

The PIN Debit Gateway Service supports the full set of PDGS transactions for EBT.
In addition, PDGS supports 0200 EBT voucher transactions and balance inquiries.
These transactions allow voice authorization of EBT purchases. These messages contain:
• Code 0180 in Field 22—Point-of-Service Entry Mode Code, which indicates manual
entry, PIN pad down.
NOTE
The term “voice” in the V.I.P. documentation manuals refers to the way cardholder information is obtained
for the 0100 authorization request message. For instance, the field 22 field description in the technical
specifications manuals specifies that the field is included in a request for which the card number is entered
directly into a computer through a series of digitized voice prompts, for instance, through VoiceTec. This use
of the term "voice" is different than the term's usage in the Visa International Operating Regulations, which
addresses voice authorizations as a method of responding to an authorization request.
• No track data (Field 35—Track 2 Data).

Chapter 7 Key Fields Glossary for EBT
• Field 48, usage 33—Integrated EBT Voucher Serial Number and Food and Consumer
Service (FCS) ID
• No PIN data (Field 52—Personal Identification Number [PIN] Data and
Field 53—Security-Related Control Information).
7.10.3 EBT Processing Rules

Table 7-3 lists the rules governing the field values for specified EBT transactions.
Table 7-3 Field Values for EBT by Transaction Type
Transaction Field Name and Number Rule

EBT Voucher Transaction Field 38—Authorization Identification This field is required.
(0200) Response
EBT Voucher Reversal (0400) Field 38—Authorization Identification This field is required.
Response
7.11 KEY FIELDS GLOSSARY FOR EBT

The following fields apply specifically to EBT processing.
Field 3—Processing Code

Positions 3–4, Account Type (From), requires one of the following codes:
• 96
96—Cash Benefits Account
• 98
98—Food Stamp Account
Both code 96 and code 98 are for EBT transactions only.
Field 48, Usage 32—Integrated EBT Food and Consumer Service (FCS) ID
In a PDGS EBT food stamp transaction, this field contains the Food and Consumer
Services (FCS) ID. The FCS ID identifies the merchant as having successfully
completed testing to accept food stamps. Two subfields following the length subfield
are defined as follows:
• Positions 1–2, Field Identifier: This 2-character code, EB EB, identifies the type of
information in this field. This code indicates that this field contains the FCS ID.
• Positions 3–x, FCS ID: This subfield is unformatted text that contains the FCS ID.
This field 48 usage applies only to the following PDGS EBT food stamp request
messages:
• 0200 balance inquiries
• 0200 purchases and related 0400 and 0420 reversals
• 0200 and 0220 merchandise returns and 0400 and 0420 reversals
The FCS ID is not present in response messages and is not used in any exception
(chargeback or representment) messages.

Field 48, Usage 33—Integrated EBT Voucher Serial Number and Food and Consumer
Service (FCS) ID
In a PDGS EBT voucher transaction, this field contains the voucher serial number and
the FCS ID. This field is mandatory in an EBT voucher transaction. Four subfields
following the length subfield are defined as follows:
• Positions 1–2, Field Identifier: This 2-character code, VN VN, identifies the type of
information in this field. The code indicates that this field contains the EBT voucher
serial number (as well as an FCS ID subfield, following the voucher serial number).
• Positions 3–17, Voucher Serial Number: This subfield contains the 1–15-digit serial
number (with blank space fill to position 17).
• Positions 18–19, Field Identifier: This 2–character code, EB EB, indicates that the
subfield that follows contains the FCS ID.
• Positions 20–x, FCS ID: This subfield is unformatted text that contains the FCS ID.
This field 48 usage applies only to 0200 PDGS EBT food stamp voucher requests and
related 0400 reversals.
Field 54—Additional Amounts

This field contains account balance information for balance inquiries and for EBT
transactions when the issuer returns this information in responses.

NOTE
If the converted transaction currency amount in field 54 exceeds the 12-character converted amount
limit, the converted currency amount value is 999999999999 (12 nines).
Balance information is for the cardholder’s benefit. Acquirers can display balances
at the terminal and can also print them on the receipt. For PDGS EBT transactions,
the issuer may return this information in the response.
Positions 1–2, Account Type, contain one of the following codes:

• 96
96—Cash Benefits Account
• 98
98—Food Stamp Account
These codes apply to PDGS EBT transactions only.

Code 0030 specifies the EBT ATM network.
Field 63.3—Message Reason Code

VisaNet only allows reason codes 2521 and 5201 for PDGS EBT transactions.
Field 63.12—Nework and Sharing Group Code

Acquirers should insert EBT code 0030 in this field when field 63.1 contains 0000
(invoking priority routing).

For additional information about the PIN Debit Gateway Service (PDGS), refer to the
following documents:
and Volume 2

Members can also contact their Visa representatives for additional information.

Chapter 8 PIN/No-PIN Split Routing Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
IN BRIEF 8-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
PIN/No-PIN Split Routing Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3
POS PIN Routing Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
HOW PIN/NO-PIN SPLIT ROUTING SERVICE WORKS 8-44
How the POS PIN Routing Option Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5
KEY FIELDS GLOSSARY

GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-
8-77
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-


Chapter 8 PIN/No-PIN Split Routing Service
8.1 IN BRIEF
The PIN/No-PIN Split Routing Service allows issuers to separate transactions requiring PIN
verification from those that do not and to route these transactions to a separate processing
center. The service offers the following options:
• PIN/No-PIN Split Routing option for separating PIN-based transactions from transactions
not requiring a PIN.
• The POS PIN Routing option for routing all POS financial transactions with PINs to the
Single Message System (SMS) within the VisaNet Integrated Processing (V.I.P.) System
and routing all other transactions to the BASE I System.

The PIN/No-PIN Split Routing Service is available to issuers in all Visa regions.
The service is also available to non-Visa card issuers such as MasterCard and
Diners Club issuers.
NOTE:
Not all regions recommend use of the PIN/No-PIN Split Routing Service.
Issuers should contact their Visa representatives to discuss participation.
The PIN/No-PIN Split Routing Service is available both to BASE I System

BASE I users and to Single Message System (SMS) users. System eligibility varies
SMS according to the options chosen:
• The PIN/No-PIN Split Routing option supports Visa and Visa Electron.
BASE I and SMS • The POS PIN Routing option supports Visa POS.

I Participation in the PIN/No-PIN Split Routing Service is optional for Visa and
Visa Electron issuers.
Issuer
8.3 SERVICE SUMMARY

The PIN/No-PIN Split Routing Service provides issuers with the option to route PIN-based
transactions to a separate processing center.
The service offers two split routing options:

• PIN/No-PIN Split Routing
• POS PIN Routing
Issuers can use these split routing options individually only; they cannot combine them.
8.3.1 PIN/No-PIN Split Routing Option

The PIN/No-PIN Split Routing option is available to both BASE I and SMS issuers that
process Visa and Visa Electron transactions. Issuers may use this option when their own
card processing centers do not have the ability to verify PINs in a secure environment.
Issuers can designate one processor to receive all PIN-based transactions and designate

another processor to receive transactions not requiring a PIN. This service supports
MasterCard transactions as long as the issuer accesses VisaNet directly and can receive
the transactions directly through VisaNet.
8.3.2 POS PIN Routing Option

The POS PIN Routing option is available to issuers that use both BASE I and SMS to
process transactions. With this option, V.I.P. routes all POS 0200 financial transactions
requiring PIN verification to SMS and routes all other transactions to BASE I.

This section describes participation requirements for the PIN/No-PIN Split Routing Service.
8.4.1 Testing
While participating issuers do not have to test for participation in the PIN/No-PIN Split
Routing Service, issuers must successfully complete testing to send and to receive POS
transactions.
Members can contact their Visa representatives to make arrangements to test the
PIN/No-PIN Split Routing Service.

Service monitoring is not available for the PIN/No-PIN Split Routing Service.

To benefit fully from the service and better understand available routing parameters,
issuers can contact their Visa representatives.
8.5 HOW PIN/NO-PIN SPLIT ROUTING SERVICE WORKS

For the PIN/No-PIN Split Routing option, V.I.P. routes incoming PIN and no-PIN requests
from acquirers according to the routing option, or options, specified by the issuer.

Chapter 8 How PIN/No-PIN Split Routing Service Works
Figure 8-1 illustrates the process flow for an issuer that has one processing center
designated for no-PIN transactions (Issuer Center 1) and has another processing center
designated for PIN transactions (Issuer Center 2).
Figure 8-1 PIN/No-PIN Split Routing Option Process Flow
No-PIN Requests
P IN
Re Issuer Center 2
qu
es
ts
The acquirer sends its V.I.P. performs standard The issuer centers receive
PIN and no-PIN requests request processing and their designated requests
to V.I.P. then routes no-PIN and send the appropriate
requests to Issuer Center 1 response messages.
and PIN requests to Issuer
Center 2.

Visa members that also issue MasterCard cards can use the PIN/No-PIN Split Routing
Service to receive their PIN-based and non-PIN MasterCard transactions. PIN-based
transactions can include cash disbursement transactions if they are acquired as SMS
full financial transactions destined for Plus or CIRRUS SMS issuer BINs. VisaNet clears
and settles these transactions in the same manner as Visa SMS full financial cash
disbursement transactions.
8.5.1 How the POS PIN Routing Option Works

For participants that select the POS PIN Routing option, V.I.P. routes incoming 0200
financial requests from acquirers to SMS according to the routing options specified by the
issuer, and routes all other transactions to BASE I.

Chapter 8 How PIN/No-PIN Split Routing Service Works
Figure 8-2 illustrates the POS PIN Routing option process flow.
Figure 8-2 POS PIN Routing Option Process Flow
Acquirer V.I.P. SMS Issuer
Financial Requests Financial Requests

with PINs
SMS
Non-Financial Requests
Fin
wit anci
a
N o hout l R e BASE I Issuer
n-F PIN qu
i na s es
n c a n d ts
i al
Re
qu
es
ts
The acquirer sends its V.I.P. routes all 0200 The issuer center receives
PIN and no-PIN requests financial request messages its designated request and
to V.I.P. with PINs to its SMS sends the appropriate
component for processing. response message.
V.I.P. routes all other
request messages to
the BASE I System for
processing.



This section lists and describes key fields associated with the PIN/No-PIN Split Routing
Service.
Field 2—Primary Account Number

This field contains the customer account number, which V.I.P. uses to determine the
routing. Field 2 appears in 0100 and 0200 requests and in 0110 and 0210 responses.
Field 52—Personal Identification Number (PIN) Data

If field 52 is present, Field 53—Security-Related Control Information must also be
present.
Field 53—Security-Related Control Information

Field 53 must appear in any message containing a PIN (field 52); otherwise, it does
not appear.

For additional information about the PIN/No-PIN Split Routing Service, refer to the following
documents:


Chapter 9 Priority Routing Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
IN BRIEF 9-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
HOW PRIORITY ROUTING SERVICE WORKS 9-55
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
PROCESS FLOWS 9-55
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
MESSAGE FLOWS 9-88
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-
Priority Routing Service

INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-


Chapter 9 Priority Routing Service
9.1 IN BRIEF
The Priority Routing Service determines the destination of authorization, financial, and
reversal requests based on the acquirer's processing order preference.
The Priority Routing Service is available to members in all Visa regions.
BASE I
SMS The Priority Routing Service is available to Single Message System (SMS)
users.
SMS only
A Participation in the Priority Routing Service is optional for acquirer processors,

including third-party processors, that support two or more card programs in
SMS.

Acquirer
9.3 SERVICE SUMMARY

With the Priority Routing Service, acquirers do not have to assign a network identification
(ID) code to transactions to make routing decisions. To initiate the Priority Routing Service,
acquirers insert a value of 0000 in the request, allowing V.I.P. to determine which network
and card program rules apply based on the account number and on acquirer-provided
preferences.
To use the Priority Routing Service, participating acquirers assign processing priorities to
each of their card programs. By setting up a preferred processing path, acquirers can
choose how V.I.P. should process a transaction that qualifies for more than one card
program.
SMS checks the debit BIN files to determine if there are issuer routing preferences for any
of the networks specified by the acquirer. If an issuer preference exists for one of the debit
networks, V.I.P. makes a routing selection based on the issuer preference. If an issuer
preference exists for more than one of the debit networks or if no issuer preference exists,
V.I.P. makes a selection based on the acquirer’s routing priorities.
The Priority Routing Service allows acquirers to send all ATM transactions to V.I.P.
regardless of network or program destination. V.I.P. determines which network and
card program rules apply based on the account number and the acquirer-established

preferences. Currently, V.I.P. determines priority routing using a fixed priority list that
acquirers maintain within the system tables. Acquirers invoke the Priority Routing Service
by submitting a value of 0000 in Field 63.1—Network Identification Code instead of
identifying a specific network ID code.
For ATM transactions, the Priority Routing Service also allows acquirers to submit a sharing
group code to identify the priority order they want V.I.P. to use for ATM gateway networks.
The sharing group code is valid for 0200 and 0210 full financial requests and responses,
and 0400 and 0410 financial reversals and responses.
Each terminal may have its own unique sharing priority. V.I.P. requires that Plus and Visa
values must be placed in position 1 and 2 of this field. Acquirers must specify the networks
they support. They may be in any order as defined by the acquirer.
Acquirers that use priority routing and submit a value of 0000 in field 63.1 should submit
Field 63.12—Sharing Group Code, which identifies the priority order they want V.I.P. to use
for ATM gateway networks. The value in field 63.12 is left-justified and the field may contain
up to 30 network designations. Acquirers must right-justify any unused positions and fill
them with spaces. Table 9-1 shows the valid sharing group codes for ATM transactions.
Table 9-1 Field 63.12—Sharing Group Code Values
Network ID Code Network

0002 V VisaNet
0003 G Interlink
0004 B Plus
0006 O CIRRUS
0007 J MasterCard
0030 T Electronic Benefits Transfer (EBT)
0040 A American Express
0041 D Discover
0042 1 AFFN

BASE I acquirers must use Visa-supplied account range routing tables for ATM
transactions. SMS acquirers must also use the Visa routing tables and must specify the
preferred card program in which they want to participate in the network ID field. If the
acquirer subscribes to the Priority Routing Service, the acquirer must insert the value
of 0000 in Field 63.1—Network Identification Code.
Both BASE I and SMS acquirers must use Visa-supplied account-range routing tables
for POS transactions. If SMS POS acquirers subscribe to the Priority Routing Service,
they must insert a value of 0000 in the network ID field, and V.I.P. selects the preferred
network.
Acquirers must not assign the value 0000 to any of their BINS in the Customer Online
Repository (CORE). They must assign the appropriate network ID to each acquirer BIN
in CORE.

Chapter 9 Related Messages
Priority Routing Service participants must fulfill the following requirements.
9.4.1 Testing
Testing is mandatory to participate in the service. The VisaNet Certification Management
Service (VCMS) provides testing assistance for Priority Routing Service participants.
Members can contact their Visa representatives to make the arrangements.
NOTE
PIN Debit Gateway Service (PDGS) participants can use priority routing transactions to initiate PDGS. To do
so, Visa requires PDGS participants to include Field 63.12—Sharing Group Code in 0100 and 0200 requests
to identify and validate routing priorities.
For more information about that service, refer to Chapter 7, PIN Debit Gateway Service (PDGS).

Service monitoring is not available for the Priority Routing Service.

Acquirers using the Priority Routing Service must consider the following key points in
planning. Acquirers must:
Supply Visa with card programs and preferred processing path— path—Each participating SMS
acquirer must supply Visa with a list of supported card programs, in the preferred order of
processing. For instance, an acquirer that supports Interlink and Visa can choose to route
its Visa transactions before its Interlink transactions to take advantage of Visa incentives.
Comply with the most stringent field requirements of all networks in which it
participates—If an acquirer participates in the Visa and Plus networks and a given field is
participates—

mandatory for Visa but conditional for Plus, the mandatory requirement takes precedence.
See “For More Information” in this chapter for a list of V.I.P. reference documents containing
information for the field requirements.

The Priority Routing Service applies to preauthorizations, authorizations, original credits,
and financial messages and their reversals when the acquirer inserts the value 0000 in
field 63.1.
For all exception transactions in a transaction set (for instance, an adjustment transaction),
the acquirer must specify the same network ID that VisaNet returns in the response to
the original transaction.
9.6 HOW PRIORITY ROUTING SERVICE WORKS

This section contains the process flow and message flow information for the Priority
Routing Service.
9.7 PROCESS FLOWS

SMS acquirers insert the value 0000 in field 63.1 of the request message to activate the
Priority Routing Service. If an acquirer wants V.I.P. to process a transaction through a
particular network, the acquirer should use the specific network ID for that network. If the
Priority Routing Service is supporting a PIN Debit Gateway Service (PDGS) request,
the message must also contain Field 63.12—Sharing Group Code.

NOTE
Field 63.12 does not apply to original credit transactions.
Upon receipt of the request, SMS compares the networks of the acquirer and of the issuer,
identifies a common network, and routes the message accordingly. If SMS detects more
than one common network, it selects the appropriate network based on the merchant's
sharing group order and on available networks that the issuer-supplied BIN file defines.
NOTE
SMS checks the debit BIN files to determine if there are issuer routing preferences for any of the networks the
acquirer specifies. If an issuer preference exists for one of the debit networks, SMS makes a routing selection
based on the issuer preference. If an issuer preference exists for more than one of the debit networks or if no
issuer preference exists, SMS makes a selection based on the acquirer’s routing priorities.
V.I.P. assigns the appropriate network ID and forwards the request to the issuer with only
those fields that pertain to the network's programming rules.
The issuer processes the request and returns the response to the acquirer.
V.I.P. includes the assigned network ID in the response to the acquirer.

IMPORTANT
If the acquirer requests priority routing for a customer transaction message, each field in each message must
comply with all of the field requirements for all of the card programs supported by that acquirer.
Further processing must comply with any program rules associated with that specific
network.

Figure 9-1 illustrates the Priority Routing Service process flow.
Figure 9-1 Priority Routing Service Process Flow
The acquirer submits the V.I.P. performs standard The issuer performs
request to V.I.P. using request processing, selects standard processing and
network ID 0000. the acquirer’s preferred returns the response to the
card program, and assigns acquirer using the assigned
a network ID to the network ID.
request.
V.I.P. applies the proper

card program rules for the
assigned network and
routes the issuer’s

9.8 MESSAGE FLOWS

Acquirers can request priority routing only for authorizations, preauthorizations, original
credits, and original financial transactions and their reversals.
Figure 9-2 illustrates the message flow when the acquirer submits an 0100, an 0200,
or an 0400 request and inserts the value 0000 in field 63.1. After assigning a network ID
0002),
that corresponds to the acquirer's preferred network (for instance, network ID 0002
V.I.P. forwards the request to the issuer. The issuer sends the appropriate 0110, 0210,
0002).
or 0410 response and includes the preferred network ID (0002
0002
Figure 9-2 Priority Routing Service Message Flow
0100, 0200, 0400 Request 0100, 0200, 0400 Request 0100, 0200, 0400 Request
Field 2: Account Number Field 2: Account Number Field 2: Account Number
Field 63.1: Network ID Code = 0000 Field 63.1: Network ID Code = 0002 Field 63.1: Network ID Code = 0002
0110, 0210, 0410 Response 0110, 0210, 0410 Response 0110, 0210, 0410 Response
Field 63.1: Network ID Code = 0002 Field 63.1: Network ID Code = 0002 Field 63.1: Network ID Code = 0002
PIN Debit Gateway Service (PDGS) participants also include Field 63.12—Sharing Group
Code in their requests. Refer to Chapter 7, PIN Debit Gateway Service (PDGS), for more
information.


This section describes key fields associated with the Priority Routing Service.
Field 2—Primary Account Number

This field contains a number identifying the customer account or relationship; that is,
a card account number of 13, 16, or 19 numeric digits encoded on Track 1 and on
Track 2 of the magnetic stripe. Field 2 appears in any message related to a customer
transaction and in 0302 and 0312 file maintenance messages.
Field 100—Receiving Institution Identification Code takes priority over field 2 if the
acquirer provides both fields.

Field 63.1 contains a code that specifies the network V.I.P. is to use for transmitting the
message. The network determines the program rules that apply to the transaction.
V.I.P. checks the programs available to the acquirer and makes a selection based
on the merchant's routing priorities. Once V.I.P. identifies a network, it places the
appropriate network ID in this field.

For additional information about the Priority Routing Service, refer to the following
documents:

For basic information about transaction routing, see the following chapters in this manual:
• Chapter 1, Introduction to System Services
• Chapter 2, System Fundamentals
• Chapter 3, Introduction to Routing Services


Chapter 10 Visa Shortest Online Path (VSOP) Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
IN BRIEF 10-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
WORKS.. . . . . . . . . . . . . . . . . . .10-
HOW VISA SHORTEST ONLINE PATH (VSOP) SERVICE WORKS 10-55
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-
Visa Shortest Online Path (VSOP) Service


Chapter 10 Visa Shortest Online Path (VSOP) Service
10.1 IN BRIEF
The Visa Shortest Online Path (VSOP) Service allows all issuers, except those in
the Visa U.S.A. (U.S.) region, that issue both Visa and MasterCard card products to
receive MasterCard authorization requests for POS balance inquiry, purchase, and cash
transactions acquired through VisaNet directly from VisaNet. This service eliminates the
need to route requests to Banknet (the MasterCard processing network) before they go
to the issuer.
The VSOP Service always tries to send the transaction to the issuer for the approval or
decline decision. If the VisaNet-connected issuer is unavailable, VSOP tries to route the
transaction through Gateway Services to Banknet. If Banknet or the issuer fails to respond,
V.I.P. declines the transaction.
VSOP is available to members in the Asia-Pacific (AP) region.

VSOP is available to members in the Visa Canada (CAN) region.
VSOP is available to members in the Central and Eastern Europe, Middle East,
and Africa (CEMEA) region.
VSOP is available to members in the Visa Europe (VE) region.

VSOP is available to members in the Latin America and Caribbean (LAC)

region.
BASE I
SMS VSOP is available to BASE I System users.
BASE I only
I
Participation in VSOP is optional for BASE I issuers.
Issuer
10.3 SERVICE SUMMARY

When an issuer that issues both Visa and MasterCard card products chooses to use
the Visa Shortest Online Path (VSOP) Service, V.I.P. routes MasterCard PIN-based
and no-PIN authorization requests directly to the issuer (when that issuer is available),
bypassing MasterCard's Banknet network. V.I.P. recognizes VSOP transactions by the
account number. A participating issuer sets up account ranges to point to the issuer's
BIN instead of to Banknet.
If the VSOP issuer is unavailable, V.I.P. does not process the request through the VSOP
Service. Instead, V.I.P. routes the transaction through Gateway Services to Banknet.
If Banknet, or the issuer fails to respond, V.I.P. declines the transaction.
VSOP participants can also separate the routing of PIN and no-PIN MasterCard
authorizations to different processing centers, using the PIN/No-PIN Split Routing Service.
For information about this service, refer to Chapter 8, PIN/No-PIN Split Routing Service.
For information about routing transactions through the VisaNet Gateway, refer to Chapter 6,
Gateway Services. Refer to Chapter 2, System Fundamentals, for basic information about
STIP routing.

VSOP is available to BASE I issuers in all regions except for the U.S. region. Participating
issuers must fulfill the following requirements.
10.4.1 Testing
Testing is mandatory for participation in the VSOP Service. The VisaNet Certification
Management Service (VCMS) provides testing assistance for VSOP participants. Members
can contact their Visa representatives to make the arrangements for testing.

Service monitoring is not available for VSOP.


To participate in the service, issuers must define their MasterCard account ranges in the
split-BIN table to link them to the same BIN as their Visa card account ranges. Additionally,
issuers must review the following system parameters to accommodate timed-out PIN
authorization requests.
Parameters—The PIN Verification Service (PVS) can

PIN Verification Service (PVS) Parameters—
verify MasterCard PINs if issuers supply Visa with their encryption keys. Refer to the PIN
Verification Service (PVS) chapter in Volume 2 for information about establishing PIN
verification parameters.
VSOP MasterCard authorization requests are eligible for system processing features and
options that apply to Visa card processing.

The VSOP Service supports 0100 authorization requests and their 0110 responses.
10.6 HOW VISA SHORTEST ONLINE PATH (VSOP) SERVICE WORKS

When an issuer that issues both Visa and MasterCard card products chooses to use the
VSOP Service, V.I.P. routes MasterCard PIN-based and no-PIN authorization requests
directly to the issuer (when that issuer is available), bypassing MasterCard’s Banknet
network.
The issuer establishes a Visa BIN for MasterCard PIN-based transactions, and establishes
a BIN for MasterCard non-PIN transactions. (These BINs may also be the same ones that
the issuer uses for its Visa PIN and non-PIN transactions.) These BINs are in addition to
any Banknet-connected BINs the issuer may have. Because V.I.P. recognizes VSOP
transactions by account number, issuers set up their MasterCard account ranges to point
to their Visa BINs.

VisaNet always sends VSOP MasterCard requests to VisaNet-connected issuers in Visa
format. Because these BINs are connected to VisaNet, Visa-to-MasterCard message
format conversion is not necessary.
When V.I.P. receives a VSOP request, it checks for issuer availability. If the issuer is
available, it approves or declines the request and returns the response message through
VisaNet to the acquirer. If the VisaNet-connected issuer is unavailable, V.I.P. tries to
deliver the VSOP request by sending it to Banknet. If the issuer or Banknet does not
respond, V.I.P. declines the transaction.
As an alternative routing method, issuers can use the PIN/No-PIN Split Routing Service
to receive its PIN and non-PIN requests. Again, because issuers must access VisaNet
directly, V.I.P. performs no format conversion.
NOTE
For transactions involving multicurrency conversion, Visa acquirers that participate in the Visa Multicurrency
Service can by default send and receive their MasterCard transactions in the initially defined local currency.
For more information about PIN and non-PIN request routing, refer to Chapter 8,
PIN/No-PIN Split Routing Service. For further information about routing transactions

through the VisaNet Gateway, refer to Chapter 6, Gateway Services. Refer to Chapter 2,
System Fundamentals, for basic information about STIP routing.
MasterCard can bypass VisaNet and send Visa transactions directly to Visa issuers
connected to Banknet. This capability does not apply to Custom Payment Service (CPS)
transactions; MasterCard always forwards them to V.I.P.

For additional information about the Visa Shortest Online Path Service, refer to the
following documents:

Part 3 Risk Management Services
Part 3, Risk Management Services, describes fraud risk reduction services Visa offers
members through the V.I.P. System.
Chapter 11—Card Recovery Bulletin (CRB) Service
Chapter 12—Fraud Reporting System (FRS)


Chapter 11 Card Recovery Bulletin (CRB) Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
IN BRIEF 11-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
Card Recovery Bulletin (CRB) Service

REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
HOW CARD RECOVERY BULLETIN (CRB) SERVICE WORKS

WORKS.. . . . . . . . . . . . . . . . . . . . . . . .11-
11-55
CRB Service Regions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
File Update Deadlines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
Exception File Update Deadline. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
PROCESS FLOWS 11-66
CRB Process Flow (Acquirer). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6
CRB Process Flow (Issuer). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-7
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
MESSAGE FLOWS 11-88
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-
11


Chapter 11 Card Recovery Bulletin (CRB) Service
11.1 IN BRIEF
The Card Recovery Bulletin (CRB) Service is an international risk control service that
creates card recovery files containing account numbers of cards reported as lost, stolen,
or misused. The CRB Service publishes card recovery bulletins electronically for issuers
and acquirers, and maintains merchant mailing files for all acquirers. It also helps control
fraud on below-floor-limit transactions outside of the U.S.

The CRB Service helps participants protect cardholders from fraudulent use of their lost
or stolen cards. It also supports chargeback rights of issuers, acquirers, merchants,
and cardholders.
CRB is available to members in all Visa regions.
BASE I
SMS CRB is available both to BASE I System users and to Single Message System
(SMS) users, based on the listings in the Exception File.
BASE I and SMS
I
Participation in CRB is optional for issuers and for issuer processors.
Issuer
A Participation in CRB is optional for acquirers and for acquirer processors.

CRB is available to all merchants whose acquirers participate in the service.
Acquirer

The CRB Service uses the information in the issuer-maintained Exception File to identify
account numbers that are listed with pick-up response codes and bulletin codes. Visa then
publishes these account numbers in card recovery files, which Visa distributes to
participants.
The CRB Service provides the following types of electronic bulletins (card recovery files):

• Regional Card Recovery Files (RCRFs)—for non-U.S. acquirers

• National Card Recovery Files (NCRFs)—for U.S. and participating non-U.S. acquirers
The CRB Service also produces billing reports and calculates distribution charges.
IMPORTANT
While acquirers are not obligated to use any of the CRB services, they are liable for chargebacks arising from
use of a listed card. A participating acquirer must decide how best to use the Card Recovery Bulletin system,
subject to Visa International Operating Regulations and to regional requirements.

Members that want to participate in the CRB Service must follow the requirements
documented in this section.
11.4.1 Testing
Testing is not required for participation in the CRB Service unless the acquirer changes
the record format for TC 55. To test this service, members can contact their Visa
representatives.

Service monitoring is available for the CRB Service.

The CRB Service uses the following messages. (This list includes exception item
messages.)
Request—This message supports several functions related to

authorization and to verification of a card or a customer transaction. V.I.P. checks the
account number in the 0100 request message to determine if it is listed in the Exception File.
Response—This message is the authorization response (with the file

update to the Exception File). V.I.P. removes update information before it forwards a
response from the issuer to the acquirer. If applicable, Field 39—Response Code contains
04, 07
the card pick-up response code: 04 07, 41
41, or 43
43.
NOTE
The CRBs contain only accounts with negative or pick-up action codes; that is, 04 (pick up card, unspecified,
non-fraudulent), 05 (do not honor, domestic use only), 07 (pick up card (special conditions [other than lost,
41 (pick up card, lost card [fraud]), or 43 (pick up card, stolen card [fraud]).
stolen, or counterfeit card]), (41
The negative response code 05 only causes U.S.-domestic accounts to be listed in CRBs. Issuers in all other
regions use pick-up action codes only to list accounts in CRBs.
Advice—This 0120 advice notifies the issuer that V.I.P. has updated
0120: File Update Advice—
the Exception File on its behalf.
Request—This message supports various financial, purchase,

0200: Financial Transaction Request—
and cash transactions that require concurrent authorization and clearing. V.I.P. checks the
account number in the 0200 request message to determine if it is listed in the Exception File.
Response—This message is the response to an 0200 or 0201

0210: Financial Transaction Response—
financial transaction request. For a customer purchase or a cash withdrawal, the response
provides the issuer's decision to approve or to decline that transaction. If applicable,

Chapter 11 How Card Recovery Bulletin (CRB) Service Works
04, 07
field 39 contains the card pick-up response code: 04 07, 41
41, or 43 (or 05
05, in U.S.-domestic
transactions only).
Request—This message is a request to update (add, change,

0302: Issuer File Update Request—
delete) or to retrieve the information in a cardholder record stored in the Exception File.
V.I.P. generates an 0312 response.
Response—This message is the response to an 0302 file update

0312: Issuer File Update Response—
or file inquiry. A file update response indicates whether V.I.P. performed the requested
maintenance.

NOTE
A file inquiry response contains the information from the requested file record.
Advice—This message is a notice to an issuer that V.I.P. updated

0322: Issuer File Update Advice—
the Exception File on the issuer's behalf. The advice includes the updated record content
(unlike the 0120 advice, which simply notifies the issuer that V.I.P. made an update).
Response—This message is the response to an 0322

0332: Issuer File Update Advice Response—
file update advice from issuers.
The CRB Service uses the following BASE II transaction codes (TCs):
(RCRF)—VisaNet uses this transaction code to

TC 55: Regional Card Recovery File (RCRF)—
transmit updates to the Regional Card File to non-U.S. acquirers.
No specific transactions types are associated with the National Card Recovery File.
11.6 HOW CARD RECOVERY BULLETIN (CRB) SERVICE WORKS

The CRB Service uses extracts from the Exception File pick-up records to create regionally
sorted lists of cardholder account numbers, which VisaNet converts to electronic card
recovery files.
To list an account in a bulletin, issuers specify the account number, a pick-up code,
the date that VisaNet should purge the listing, and the merchant region in which VisaNet
is to list the account number. VisaNet can list accounts for issues that participate in the
Automatic Cardholder Database Update (Auto-CDB) Service, which allows VisaNet to
update the Exception File when issuers return a pick-up response code in authorization
response messages. Refer to the Automatic Cardholder Database Update (Auto-CDB)
Service chapter in Volume 2 for information about this service. Issuers that directly connect
to VisaNet using Direct Exchange (DEX) can also use the Open File Delivery (OFD) option
to update the Exception File. Issuers are responsible for the accuracy of the cardholder
records in the Exception File.
NOTE
The CRBs contain only accounts with negative or pick-up action codes; that is, 04 (pick up card, unspecified,
non-fraudulent), 05 (do not honor, U.S.-domestic use only), 07 (pick up card (special conditions [other than
41 (pick up card, lost card [fraud]), or 43 (pick up card, stolen card [fraud]).
lost, stolen, or counterfeit card]), (41
See the Cardholder Database Overview chapter in Volume 2 for information about the
Exception File.

11.6.1 CRB Service Regions

Issuers can list an account number in individual CRB regions or in a combination of
individual regions plus one or more groups of regions.
11.6.2 File Update Deadlines

This section identifies the processing deadlines for the Exception File.
For information about the consequences incurred when members miss these deadlines,
see the Card Recovery Bulletin Service User's Guide.
11.6.2.1 Exception File Update Deadline

Each week, the CRB Service extracts records from the Exception File to produce regional
lists of pick-up account numbers. The CRB Service uses the lists to create electronic
bulletins that become effective on or after Saturday of that week. The CRB Service includes
the Exception File pick-up records in the next version of the bulletins only when the account
is listed before the cutoff time for that version.
Table 11-1 provides the update deadline for the Exception File.
Table 11-1 Exception File Update Deadline
Update Method Delivery Established Deadline

Online To a VIC through a VisaNet 20:00 on the Monday preceding
Access Point (VAP) the bulletin issuer effective date
NOTE
Visa no longer allows members to send updates to VICs by any method other than electronically to ensure
information security.
11.7 PROCESS FLOWS

This section describes the process flows both for acquirers and for issuers.
11.7.1 CRB Process Flow (Acquirer)

Acquirers participating in the CRB Service must ensure that their merchants follow the
guidelines for transaction authorizations. These guidelines should include verifying the
account number against the CRB using the electronic card recovery file. Acquirers are
responsible for contacting Visa to receive CRB Service electronic bulletins and files.

Figure 11-1 illustrates the CRB process flow for acquirers.
Figure 11-1 CRB Process Flow (Acquirer)
Exception
File

The acquirer checks its V.I.P. performs standard The issuer provides the
electronic card recovery request processing. appropriate authorization
files for a pick-up listing. response.

11.7.2 CRB Process Flow (Issuer)

To update the Exception File, issuers submit updates to V.I.P. through their Direct
Exchange connection, a Visa Extended Access Server, or automatically using the
Auto-CDB Service. The CRB Service combines the Exception File records with counterfeit
card accounts and with blocked BINs to produce the pick-up file. Visa distributes the sorted
pick-up list through electronic files.
See the Automatic Cardholder Database Update (Auto-CDB) Service chapter in Volume 2,
for more information about the Auto-CDB Service.

Figure 11-2 illustrates the CRB Service process flow for issuers.
Figure 11-2 CRB Process Flow (Issuer)
Issuer V. I.P. Acquirer
Exception
File
The acquirer submits V.I.P. adds the updates to The acquirer receives the
updates for the Exception the Exception File. electronic file from V.I.P.
File through DEX, the
V.I.P. Terminal of a VAP,
an EA Server, or
automatically using the
Auto-CDB Service.
11.8 MESSAGE FLOWS

The CRB Service message flow for authorization, financial, and reversal requests includes
these steps:
1. The acquirer sends the 0100 or 0200 request to V.I.P.
2. V.I.P. checks the Exception File to verify if the account is listed.
- If the account is listed, V.I.P. inserts the appropriate pick-up action code in
Field 39—Response Code of the 0110 or 0210 response message and forwards the
request to the issuer. (V.I.P. forwards the request to the issuer only if the response
code is a forward referral.)
- If the account is not listed, V.I.P. forwards the request to the issuer for additional
message processing.
- If STIP processes the request on the issuer's behalf, V.I.P. generates an 0120 or 0322
advice, as appropriate. SMS issuers must acknowledge the 0322 advice with an 0332
advice response. BASE I issuers that choose to receive 0322 advices optionally may
acknowledge the 0322 advice with an 0332 advice response.
3. The issuer processes the request and sends the 0110 or 0210 response to the acquirer
through V.I.P.
For the following Exception File update request message flow, Issuers send an 0302
message to V.I.P., containing the Exception File update information. V.I.P. sends the
issuers an 0312 response message. The flow also shows the flow of an 0120 advice to
illustrate this processing option.

Figure 11-3 illustrates the CRB message flow for authorization, financial, reversal, and file
update requests.
Figure 11-3 CRB Message Flow
Acquirer V. I.P. Issuer

BASE I
Exception
File

(includes updated record contents) (includes updated record contents)

Response Response
0120 Advice 0120 Advice
0130 Advice Response 0130 Advice Response

(Optional) (Optional)
0302 File Update Request 0302 File Update Request

Field 91: File Update Code Field 91: File Update Code
Field 101: File Name Field 101: File Name
Field 127: CDB Data Field 127: CDB Data
0312 File Update Response 0312 File Update Response

This section describes the fields members use to update the Exception File with the
CRB Service.


Field 39 appears in the 0110 or 0210 response and contains one of the following card
negative or pick-up codes:
04 = Unspecified, non-fraudulent
05 = Do not honor (U.S.-domestic only)
07 = Special conditions (other than lost, stolen, or counterfeit card)
41 = Lost card (fraud)

43 = Stolen card (fraud)
Field 91—File Update Code

This field contains a code that specifies the type of file processing required.
See Table 11-2 for valid codes. All 03xx messages require this field.
If this field contains code 5 for inquiry requests, the requests do not use Field 73—Date,
Action and Field 127—CDB Data; if they are present, V.I.P. ignores them.
Table 11-2 Field 91 File Update Codes
Code Definition Explanation

1 Add Add a new record only if one does not already exist.
2 Change Change an existing record.
3 Delete Delete an existing record.
4 Replace Add a new record if none exists or replace an existing record
if one does exist.
5 Inquire Send a copy of an existing record.
Field 101—File Name

This field identifies the VIC-resident cardholder or merchant file V.I.P. is to access by a
file update or inquiry, and the update or inquiry request format.
All 03xx messages use this field. The file name is necessary to determine the system
file affected, but it also identifies the 03xx message content and the field 127 layout.
See Table 11-3 for valid file names.
Table 11-3 Field 101 File Names
Name File
E2 Exception File
E3 Exception File
E4 Exception File

FIELD 127—CDB DATA

Field 127 is used in 0300 or 0302 messages that request file updating. The field
identifies the file and the action requested. It is needed in all file add or change requests.
It is not used in delete requests. It is not used in 0302 file inquiry requests. It is present
in the 0312 response to a file inquiry only when the response code is 00 00. When present
in an 0302 file update request, this field is returned in the 0312 response.

For more information about the Card Recovery Bulletin Service, refer to the following
documents:

• Card Recovery Bulletin Service User's Guide
• Visa International Operating Regulations and Operating Regulations for the six Visa
regions
and Volume 2


Chapter 12 Fraud Reporting System (FRS)
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
IN BRIEF 12-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4
Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-5
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
WORKS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
HOW FRAUD REPORTING SYSTEM (FRS) WORKS 12-55
Fraud Reporting System (FRS)

Fraud Reporting Timeframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
Unique New Transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
Correct Notification Code for Identical Transaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
Rejected Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
PROCESS FLOWS 12-77
The Fraud Reporting Decision Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-9
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
MESSAGE FLOWS 12-11
11
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
11
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-
15


Chapter 12 Fraud Reporting System (FRS)
12.1 IN BRIEF
Fraud occurs when an individual who is not the cardholder or the cardholder designee
uses a card (or a counterfeit of a card) or its account number to obtain goods or services
without the cardholder's consent. Fraud also occurs when someone obtains a card through
misrepresentation of identification or of financial status. V.I.P. provides the Fraud Reporting
System (FRS) to help members report, track, and analyze fraudulent transactions.
FRS consolidates fraud information, helping members detect fraud patterns and reduce
losses. It performs the following functions:
• Validates submitted fraud advices and adds the information to the Visa Fraud Master File.
• Provides status reporting to indicate whether a member accepts or rejects a fraud advice,
or needs further validation.
• Consolidates fraud report information and sends fraud activity reports to members on a
regular basis.
• Allows SMS-attached members to send fraud information through V.I.P.

• Allows members to use their existing VisaNet Access Points (VAPs) connecting them to
the BASE II System to send and receive reports.
• Ensures eligibility for maximum fraud-related chargeback rights on correctly reported
fraud transactions.
The Fraud Reporting System is available to members in all Visa regions.
BASE I
SMS The Fraud Reporting System is available to Single Message System (SMS)
users.
SMS only
I
Participation in the Fraud Reporting System is mandatory for issuers.
Issuer
A
Participation in the Fraud Reporting System is mandatory for acquirers.
Acquirer


The Fraud Reporting System (FRS) offers members an electronic way to report and monitor
fraud activity. FRS allows members to report fraud using the following systems:
• SMS
• BASE II
• Visa Resolve Online (VROL)
This chapter only describes the FRS reporting options available through the V.I.P. System.
See the Fraud Reporting System User's Guide for information about BASE II System
procedures.
For 0100 and 0110 authorizations and 0200 and 0210 full financials, issuers can insert
response code 59 in Field 39—Response Code to alert VisaNet that they suspect fraud in
the transaction under consideration. When V.I.P. receives response code 59 (suspected
fraud), it changes the code to 05 (decline) in the response to the acquirer. Code 05
minimizes the possibility of a confrontation between the merchant and the cardholder.
Reporting—The SMS Online Fraud Reporting option, available through

SMS Online Fraud Reporting—
V.I.P., allows single-message, Interlink, and Plus users to report POS or PIN-based fraud
using SMS advice messages.
(V.I.P.)—Members can also send their fraud

Visa Resolve Online–Fraud Advice (V.I.P.)—
notifications through Visa Resolve Online.
Visa Resolve Online users send and receive exception transactions automatically through
the Visa Resolve Online application’s VisaNet Access Points (VAPs). Participating
members use their own personal computers, Web browser, and Internet gateway to access
Visa Resolve Online to send fraud notifications.
The same reporting procedures, data edits, and reports apply to both V.I.P. options.
Form—In emergency situations such as the unavailability

Notification of Confirmed Fraud Form—
of Visa systems, members can submit transactions using the Notification of Confirmed
Fraud Form. (See the Fraud Reporting System User's Guide.)

Participants must be connected to VisaNet to use the Fraud Reporting System.
Also, participants must be able to create 9620 advice messages. Use of this service
requires no other programming changes.
12.4.1 Testing
Testing is required in some Visa regions. Visa, however, encourages all participants
to complete testing before using the service. Members can check with their Visa
representatives for testing requirements.
The VisaNet Certification Management Service (VCMS) provides testing assistance for FRS
participants. Members can contact their Visa representatives to make the arrangements.

Service (compliance) monitoring applies for the Fraud Reporting System; however,
the process varies according to region. Service participants can contact their Visa
representatives for information about service monitoring.


Visa acquirers and issuers must comply with the fraud reporting rules as defined in the
Visa International Operating Regulations.
IMPORTANT
Members must report all confirmed fraud activity with all original transaction data. Members should not modify
or omit available original transaction information.
Members should consider the following key points in their planning and their implementation
of the Fraud Reporting System:
Requirements—Issuers and acquirers must report all confirmed fraud activity.

Reporting Requirements—
Failure to comply with the fraud reporting rules as defined in the Visa International Operating
Regulations can result in the loss of chargeback rights and in potential fines and penalties.
Options—Members must report confirmed fraud transactions on all

Electronic Reporting Options—
Visa cards electronically, either online or through Visa Resolve Online.
Reports—Participants receive fraud reports from Visa through BASE II, through
Receiving Reports—
the Report Distribution Management System (RDMS), through remote job entry (RJE),

or through job entry subsystem 2 (JES2) endpoints.

The following messages pertain to the Fraud Reporting System.
Advice—SMS issuers and acquirers use this message to report confirmed

9620: Fraud Advice—
fraud transaction messages online. These messages originate from any SMS issuer or
acquirer. V.I.P. holds these messages until end-of-day processing, when it forwards them
to the Fraud Reporting System. SMS generates a 9630 message type response to the
member and logs the message.
Response—SMS sends this message in response to 9620 messages

9630: Fraud Advice Response—
sent by acquirers or by issuers.
The message details include information about the cardholder and the merchant and about
how the transaction was processed. To identify the type of fraud, members specify a
fraud type code. (See “Field 63.9—Fraud Data” in “Key Fields Glossary” in this chapter
for a list of codes.)
12.6 HOW FRAUD REPORTING SYSTEM (FRS) WORKS

The following guidelines for reporting fraud are specific to members processing directly
with VisaNet.
• Fraud Reporting Timeframes
• Unique New Transaction
• Correct Notification Code for Identical Transaction
Members using a third-party processor must follow the procedures established by the
processor and can usually obtain reports from the processor.

Chapter 12 How Fraud Reporting System (FRS) Works
12.6.1 Fraud Reporting Timeframes

Members must report all fraudulent transactions upon detection or as soon as possible
but no later than 90 days from the transaction date. Timely reporting ensures the highest
level of risk management effectiveness to reduce member losses.
VisaNet generates fraud advice records for the Visa Fraud Master File on a daily basis and
assigns a posting date on the day that FRS processes them. VisaNet uses the posting
date to determine how many days from the transaction date the member reports the fraud
transaction and whether the report meets specific reporting timeframes.
IMPORTANT
Reporting a transaction late may affect the eligibility of the transaction for acceptance by various Visa
programs, such as the Merchant Fraud Performance Program, or eligibility for fraud-related chargebacks.
Table 12-1 lists reporting timeframes for adding transactions to the Visa Fraud Master File.
Table 12-1 Fraud Reporting Timeframes
From the Transaction Date Transaction Status

0–90 days V.I.P. accepts the transaction.
91–180 days V.I.P. accepts the transaction but flags it as late. V.I.P.
assigns the transaction a W20 warning status code.
Over 180 days V.I.P. rejects the transaction and does not report it. Reject
status code R82 appears on Fraud Activity Report Reject
Activity reports.
For more information about reporting timeframes, refer to the Visa International Operating
Regulations.
12.6.2 Unique New Transaction

If member is adding a new transaction, check records to see if they have or if their
processors have already reported a transaction. Before FRS adds a new transaction to
the Visa Fraud Master File, it determines if another transaction with identical data (except
for the sequence number) already exists. The member must use notification code 2, to
add identical transactions.
12.6.3 Correct Notification Code for Identical Transaction

If member is adding an identical transaction, ensure that the notification code 1 is used for
the first transaction and notification code 2 is used for the second transaction.
12.6.4 Rejected Transactions

FRS performs all edits on submitted fraud transactions.
When adding or when modifying a fraud transaction, VisaNet rejects the transaction if one
or more fields contain data that does not comply with stated fraud advice record data edit
requirements or was submitted using incorrect procedures.
If reporting errors occur, Visa notifies the member of the specific reporting problems in the
daily or weekly fraud activity warning and reject reports. Service participants can receive
one of the following status codes that indicate a rejected transaction:

transaction)—FRS rejects transactions with status code R82 when

Status code R82 (late transaction)—
the member submits the transaction after the 180-day reporting timeframe.
transaction)—FRS rejects a transaction with status code R80 if

Status code R80 (duplicate transaction)—
another transaction with identical data (except for the sequence number) already exists in
the Visa Fraud Master File.
To add identical transactions, the member must use notification code 2.
code)—FRS rejects transactions with status

Status code R81 (incorrect use of notification code)—
code R81 when:
• Members try to add a transaction to the Visa Fraud Master File using notification code 2,
and FRS cannot find an identical transaction already posted in the file.
• Members try to add more than one fraud transaction to the Visa Fraud Master File on a
given posting date, and the transactions contain identical information.
• No other transaction with identical information has already posted. This reject reason
applies when the member did not use notification code 1 for the first transaction, and
does not use notification code 2 for each subsequent identical transaction.
VisaNet does not apply rejected fraud transaction additions or modifications to the Visa
Fraud Master File. Members must correct and resubmit rejected transactions to VisaNet. If

reporting errors occur, Visa notifies the member of the specific reporting problems in the
daily or weekly fraud activity warning and reject reports.
R82, which
Members cannot resubmit a rejected transaction with reject status code R82
indicates a late transaction.
However, member can edit and resubmit rejected transactions with reject status codes
R81.
R80 or R81
12.7 PROCESS FLOWS

This section explains how members report fraudulent transactions to Visa and what Visa
does with the information.
Members must report confirmed fraud transactions for domestic and international
transactions. Fraud reporting consists of the following steps:
1. The member gathers the required fraud advice data as specified by the individual
program or by the regional fraud reporting requirements.
- Some Visa programs, by regional directive, by program regulations, or by both, require
reporting of specific fraud advice information, such as the transaction amount and date.
- Some Visa regions require mandatory reporting of specific fraud advice fields.
Members obtain the required information from several sources, which include the
cardholder, the original transaction draft, and the authorization message.
2. The member submits the completed fraud advice to VisaNet using the appropriate
fraud reporting method:
- V.I.P.—SMS Online Fraud Reporting Option
- Visa Resolve Online—Fraud Notification/Not Received as Issued (NRI)/Issuers'
Clearinghouse Service (ICS)
3. FRS reviews the transaction and edits it for record structure and for data content. It then
adds the transaction information to the Visa Fraud Master File and to related programs.

4. Visa consolidates all fraud information and sends the members either daily or weekly
reports. Visa also sends monthly and quarterly reports to members with summarized
reporting information. These reports enable members to:
- Verify their submitted transactions.
- Correct and resubmit rejected transactions.
- Accurately track their fraud activity.
NOTE
Transactions that VisaNet rejects or assigns a warning status may require additional action.
For information about FRS reports, see the Fraud Reporting System User's Guide.
5. The member must verify fraud reporting on the daily or weekly fraud activity reports
to determine if the reported transaction was:
- Accepted.
- Accepted but requires additional verification.
- Rejected and requires correction and resubmission.
Once VisaNet accepts a fraud transaction, members can modify or delete it by using
the appropriate notification code and resubmitting the transaction.
6. Before modifying a transaction on the Visa Fraud Master File, it is important for the
member to confirm on the Fraud Activity Report Confirmed Activity reports that the
transaction to be modified was actually added and that it resides on the Visa Fraud
Master File.
If the transaction is not on the Visa Fraud Master File and a member tries to change or
R83, indicating
to delete it, V.I.P. rejects the modification request with reject status code R83
that it could not find the record in the file.
IMPORTANT
Members must modify a previously submitted transaction if it determines that the data in the fraud record
has changed, was incorrect, or was incomplete. However, members should not delete fraud transactions
just because the transaction was charged back or was charged off.

Figure 12-1 provides a simplified view of the fraud reporting transaction process.
Figure 12-1 Fraud Transaction Process Flow
Acquirer Issuer V.I.P.
or Fraud
Master
File
The member researches V.I.P. performs standard

fraud transactions and request processing.
submits fraud advices to FRS adds valid fraud
V.I.P. transactions to the Visa
Fraud Master File.

Visa routes fraud reports
to issuers and acquirers.
12.7.1 The Fraud Reporting Decision Tree

Figure 12-2 illustrates the major steps both for issuers and for acquirers during the fraud
reporting process. This process flow represents a general overview of the reporting process
and the expected outcomes in a decision-tree format.

NOTE
The member's organization may not follow each step or may perform steps concurrently.
Figure 12-2 Fraud Reporting Decision Tree
Is s uer gathe rs Issue r re views

Iss uer as signs
Fra ud trans a ction Is s uer confirms Is s ue r blocks the re quired data a nd Vis a fra ud a ctivity
inves tigato r to the
occurs . fraud. a ccount. re ports trans action reports to verify
case.
to Vis a . correct reporting.
Is s uer s e nds Is s uer may

Cha rge ba ck to
a ffidavit and gets re que s t a copy of Has original dra ft
acquirer us ing
car dholder the origina l s a les copy b een re ceive d No End
correct Visa
certification o f the dra ft from the from acquirer?
charge back code .
fra ud trans action. acquir e r.
Yes
Is s ue r re vie ws the
dra ft for correct
mercha nt and
cardholder
informa tion.
Did me rcha nt
correctly process the No
tra ns a ction?
Ye s
Wa s acc ount Is s ue r a bs orbs

Wa s t he tr ansac tion numbe r lis ted on the trans a ction los s .
No No End
above the floor limit? No cha rge ba ck
CRB? *
rights .
Ye s Yes
Vis a notifie s is s uer

Vis a Charge back
Wa s tra ns action of rejecte d
Reduction S ervice
a uthorize d but cle ared trans a ction End
send s transact ion
to a different a ccount? through the TC 33
back to a cquire r.
a dvice .
No
Ye s
Acquirer
re pres ents
Acquire r re ports Is s ue r a bs orbs the
tra ns action to End
counterfeit trans a ction los s .
iss uer with sales
trans a ction (Fra ud
draft a nd log data .
Type 9) to Vis a .
Acquire r abs orbs

the tra ns a ction
los s . May revie w End
the s ta tus of the
mercha nt.

*CRB = Card Recovery Bulletin. Refer to Chapter 11, Card Recovery Bulletin (CRB)
Service, for further details.
12.8 MESSAGE FLOWS

SMS issuers and acquirers use 9620 messages to report confirmed fraud transactions.
V.I.P. holds these messages until end-of-day processing, when it forwards them to FRS.
When V.I.P. receives a 9620 message from a member, it generates a 9630 response.
Figure 12-3 illustrates the message flow when an acquirer or an issuer sends a 9620
message to SMS.
Figure 12-3 Fraud Reporting System Message Flow
Acquirer Issuer V.I.P.
or
Fraud
Master
File

9620 Fraud Message 9620 Fraud Message
Field 4: Transaction Amount Field 4: Transaction Amount
Field 15: Settlement Date Field 15: Settlement Date
Field 32: Acquirer BIN Field 32: Acquirer BIN
Field 33: Issuer or Acquirer BIN Field 33: Issuer or Acquirer BIN
Field 37: Retrieval Reference Field 37: Retrieval Reference
Number Number
Field 63.1: 0002 Field 63.1: 0002
Field 63.9: Fraud Data Field 63.9: Fraud Data
Field 70: 940 or 941 Field 70: 940 or 941
Field 100: Receiving Institution ID Field 100: Receiving Institution ID
= 400050 = 400050
Field 125: Additional Fraud Data Field 125: Additional Fraud Data
9630 Fraud Response 9630 Fraud Response

Message Message
Field 15: Settlement Date Field 15: Settlement Date
Field 32: Acquirer BIN Field 32: Acquirer BIN
Field 37: Retrieval Reference Field 37: Retrieval Reference
Number Number
Field 70: 940 or 941 Field 70: 940 or 941

This section lists and describes key fields associated with the Fraud Reporting System.

Field 4—Amount, Transaction

Field 4 must appear in 9620 messages unless the message is reporting Not Received
as Issued (NRI) or Issuer's Clearing Service (ICS) fraud (field 125 = 04 or 0505), in which
case the message does not use field 4. When present, it contains the billing amount
from the original transaction in the issuer's currency (if submitted by the issuer) or in the
acquirer's currency (if submitted by the acquirer). Only when an acquirer reports fraud
(fraud type = 9) should this field contain the purchase amount in the merchant's currency.
Additional Fraud Reporting System edits exist with respect to transactions exceeding
USD$50,000.00 and to those below USD$0.95.
Field 15—Date, Settlement

SMS adds field 15 in 9620 messages; this field also must appear in 9630 responses.

Field 32 must appear in 9620 messages and in their 9630 responses except for those
05), in which case the messages or the
reporting NRI and ICS fraud (field 125 = 04 or 05
responses do not use it. When present, it contains the acquirer BIN.
Field 33—Forwarding Institution Identification Code

Field 33 contains a code, usually a Visa-assigned BIN, that identifies the institution that
forwards a request to VisaNet, that is, the message originator. The field contains the
BIN of the issuer or of the acquirer submitting the transaction. For NRI and ICS fraud
reporting, this code is the BIN of the issuer submitting the transaction. The ID code can
be a Visa BIN or can be a prearranged institution ID.
Field 33 must appear in all 9620 messages. Only 9630 responses for NRI or ICS
reporting use this field.
Field 37—Retrieval Reference Number

Field 37 must appear in 9620 messages and in their 9630 responses except those
05), in which case the messages or the
reporting NRI or ICS fraud (field 125 = 04 or 05
responses do not use it. When present, this field must contain the value from the
original transaction.

If member-generated, the field contains the code provided by SMS to acknowledge
receiving the 9620 message. The code must be 00 00.
If VisaNet-generated, the field contains a code provided by the member to acknowledge

receiving the 9620 message. The code must be 00 00.
NOTE
0110 and 0210 messages from issuers can contain field 39 transaction decline response code 59
(suspected fraud). V.I.P. converts 59 to 05 (decline) to minimize problems between merchants and
cardholders.

The network ID must be 0002 (Visa), 0003 (Interlink), or 0004 (Plus) in all 9620
messages. Members must return the field in 9630 responses.

Field 63.6—Chargeback Reduction/BASE II Flags

Field 63.6 appears in 9620 messages and identifies the existing debt indicator. The
valid value is 9 (payment on existing debt transaction). Field 63.6 is mandatory for
9620 messages.
Field 63.9—Fraud Data

Field 63.9 appears in 9620 messages and identifies the type of fraud being reported.
It also designates whether the member is adding, modifying, or deleting the transaction
in the Visa Fraud Master File. Field 63.9 is mandatory for 9620 messages.
Type—This 1-position subfield identifies the type of fraud being

Position 1, Fraud Type—
reported. The fraud type codes are:
• 0—Lost card
• 1—Card reported stolen
• 2—Card not received (NRI)
• 3—Card issued on basis of fraudulent card application
• 4—Issuer reported counterfeit
• 5—Miscellaneous
• 6—Fraudulent use of account number

• 9—Acquirer reported counterfeit
Code—This subfield designates whether the member is
Position 2, Fraud Notification Code—
adding, modifying, or deleting the transaction in the Visa Fraud Master File. It also
indicates whether the transaction being added is unique or is an identical (duplicate)
transaction.
NOTE
Identical means that each field, except the account sequence number field, in a fraud advice record
contains identical data to the corresponding fields in another fraud advice record (or other records).
Table 12-2 lists the fraud notification codes used in position 2 of field 63.9.
IMPORTANT
Failure to use the notification codes as described in Table 12-2 may result in VisaNet rejecting fraud
advice transactions.
Table 12-2 Field 63.9, Position 2, Notification Codes
Notification Code Description

1—Addition Members can use this code to add unique transactions to the Visa
Fraud Master File when:
• No other transaction already posted on the Visa Fraud Master File
has identical information to the transaction being added.
• They are submitting multiple identical transactions on the same
posting date, and they have posted no previous transaction with
identical information to the Visa Fraud Master File. In this case,
members use notification code 1 for the first transaction posting
that day.

Table 12-2 Field 63.9, Position 2, Notification Codes (continued)

Notification Code Description
2—Addition of Members use this code to add non-unique transactions (legitimate
subsequent identical duplicates) to the Visa Fraud Master File when:
(duplicate) transaction • They are adding multiple identical transactions to the Visa Fraud
Master File on the same posting date, and no previous transaction
with identical information has posted to the Visa Fraud Master
File. The member uses notification code 1 for the first transaction,
then uses notification code 2 for all but the first transaction.
The code notifies FRS that the subsequent identical transactions
are correctly reported duplicates and instructs FRS to apply them
to the file.
• They are adding one or more transactions to the file and they
already posted a previous transaction with identical information
to the Visa Fraud Master File.
The code notifies FRS to apply the transaction to the Visa Fraud
Master File even though there are already transactions posted
with identical information.
3—Change Members use this code to modify data elements in all fields,
except the file key fields.
NOTE:
File key fields include the account extension, the account sequence,
and the account number.
4—Delete Members use this code to delete the entire record from the Visa
Fraud Master File.
5—Reactivate Members use this code to restore a Visa Fraud Master File record
that has been deleted.
If the fraud type being reported is NRI (position 1 = 2), position 2 must contain 1, 3, or 4.
If the fraud type is ICS (position 1 = 7 or 8), position 2 must contain 1. (This option
applies to the Visa U.S.A. [U.S.] region only.)
For non-NRI and non-ICS reporting, the following codes are valid: 0, 1, 2, 3, 4, 5, 6,
and 9.
For NRI and for ICS reporting, the following codes are valid: for NRI, a value of 2;
9 (U.S. only).
for ICS, a value of 0–9
For NRI, the code must be 1, 3, or 4. For ICS, the code must be 1.
3–14—Reserved.
Positions 3–14—
Field 70—Network Management Information Code

Acquirers must use 0940 in this field for 9620 messages. Issuers must use the
0941. Only issuers (0941
value 0941 0941)
0941 can initiate NRI or ICS fraud reporting messages.
Field 100—Receiving Institution Identification Code

Field 100 is a message routing field. It contains a code that identifies the institution
that should receive a request or an advice. This field must contain 400050 in all 9620
messages, including NRI and ICS reporting. It does not appear in 9630 responses.

Field 125—Reporting Non-NRI/ICS Individual Fraud Transactions

Field 125 appears in the 9620 message when issuers and acquirers report fraud
for the Visa Network 0002 and the Plus Network 0004. The field contains further
information about the fraud transaction, such as the type of fraud notification, whether
the transaction was authorized, a fraud reporting sequence number, the merchant postal
code, and the fraud investigative status.
Type—This required subfield contains a 2-digit code.

Positions 1–2, Fraud Notification Type—
The value 03 reports individual fraud transactions. The value 04 indicates NRI fraud;
the value 05 indicates ICS fraud.

For more information about the Fraud Reporting System, refer to the following documents:
• Fraud Reporting System User's Guide

and Volume 2


Part 4 Visa Secure Electronic Commerce (VSEC) Services
Services, contains a brief overview of

Part 4, Visa Secure Electronic Commerce (VSEC) Services
VSEC, Verified by Visa, and 3-D Secure.
Part 4 contains the following chapter:
Chapter 13, Visa Secure Electronic Commerce (VSEC) With Verified by Visa (3-D Secure)


Chapter 13 Visa Secure Electronic Commerce (VSEC) With
Verified by Visa (3-D Secure)
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-
IN BRIEF 13-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-
VSEC With Verified by Visa (3–D Secure)


Chapter 13 Visa Secure Electronic Commerce (VSEC) With
Verified by Visa (3-D Secure)
13.1 IN BRIEF
The Visa Secure Electronic Commerce (VSEC) initiative provides security for transactions
sent over the Internet and over other open networks. Implemented as part of the VSEC
initiative, this Visa technology authenticates the cardholder during an online purchase.
The authentication technology is called 3-D Secure; the authentication service available
to cardholders is called Verified by Visa (VbV).
Verified by Visa is available to members in all Visa regions.
BASE I
Verified by Visa is available both to BASE I System users and to Single
SMS Message System (SMS) users that process point-of-sale or point-of-service
(POS) Visa and Visa Electron transactions.
BASE I and SMS
I Each region determines requirements for issuer participation in Verified by

Visa. Participation is mandatory for issuers in the United States (U.S.) regiion.

Issuer
A Participation in Verified by Visa is mandatory for acquirers that have

electric-commerce merchants.
Acquirer

Verified by Visa (VbV) reduces the number of disputed online purchases by enabling
issuers to verify that the person making the electric commerce (e-commerce) purchase
is an authorized cardholder. This verification process is called payment authentication.
Payment authentication gives issuers the ability to authenticate cardholders during an
online purchase to:
• Reduce the likelihood of fraudulent usage of Visa cards.
• Improve transaction performance to benefit all participants.
VbV gives cardholders control over card use for online purchases and provides payment
security that adds an extra level of protection both for consumers and for merchants.

VbV enables all parties in an e-commerce payment transaction to transmit confidential

payment data and provides authentication that the buyer is an authorized user of a
particular account. VbV is a global program that supports magnetic-stripe Visa cards, Visa
Smart Debit/Smart Credit (VSDC) cards, and commercial cards. It also supports a variety
of Internet access devices including, but not limited to:
• Personal computers
• Mobile phones
• Personal digital assistants (PDAs)
VisaNet validates the results of authentication during authorization. Refer to the Cardholder
Authentication Verification Value (CAVV) Verification Service chapter in Volume 2, which
provides detailed information about the Cardholder Authentication Verification Value
(CAVV) Verification Service. The CAVV Verification Service is part of the suite of functions
provided by Verified by Visa.

For more information about the authentication technology 3-D Secure, refer to the following
documents:
• Introduction (70001-01) v1.0.2—Provides a high-level description of the Visa Secure
Electronic Commerce (VSEC) Initiative, including 3-D Secure. The document describes
how VSEC With 3-D Secure works; the benefits to members, to merchants, and to
cardholders; and member considerations for adoption and for implementation. Readers
interested in 3-D Secure should read this document first.
• System Overview (70015-01) v1.0.2—Provides an introduction and a guide to the entirety
of 3-D Secure. Interested individuals should read this document after the Introduction
and before any other 3-D Secure publication. This document is published in two versions:
an internal version for Visa members and an external version for non-members.
• Protocol Specification—Core Functions (70000-01), Licensed
v1.0.1/1.0.2—Provides details about setting up 3-D Secure, cardholder enrollment,
protocol, and processing steps, along with detailed message formats. The document
focuses primarily on messages exchanged across the Interoperability Domain. The
protocol specified in document 70000-01 is referred to throughout the publication
suite as the “core protocol.”
• Functional Requirements—Access Control Server (70002-01),
Licensed v1.0.1/1.0.2—Describes functional requirements for Access Control Server
software, including configuration, enrollment, interaction with the Visa Directory,
authentication message processing, message transmission to the Authentication History
Server, transaction logging, internationalization, and data formats.
• Functional Requirements—Merchant Server Plug-In (70003-01), v1.0.1/1.0.2,
Licensed—Describes functional requirements for merchant server plug-in software,
including configuration, interaction with the Visa Directory, message processing,
signature validation, transaction logging, formats, and implementation options.
• Functional Specification—Chip Card Authentication (70005-01), Licensed—Identifies and
describes the technical and security specifications of an authentication method for Visa
Smart Debit/Smart Credit (VSDC) cards.
• Protocol Specification—Extension for Mobile Internet Devices (70006-01), v1.0.1/1.0.2,
Licensed—Describes the implementation issues and specifies the protocol changes
required for 3-D Secure to support Internet-capable mobile devices, such as WAP phones.

• Service Specification—Visa Directory Service (70007-01)—Describes the Visa-operated

Directory Server, which facilitates message routing between merchants and issuers and
plays a role in determining whether a cardholder is enrolled in 3-D Secure.
• Service Specification—Authentication History Service (70008-01) v1.0.2—Describes the
Visa-operated Authentication History Server, to which Access Control Servers send a
record of each payment transaction authentication attempt for dispute resolution and
for other purposes.
• Implementation Guide—Issuer (70013-01) v1.0.2—Provides issuers with detailed
information about the functions, the use, and the benefits of 3-D Secure; guidance in
developing a marketing strategy to help meet their goals; and assistance in developing
and executing a project plan to develop, to test, and to launch the 3-D Secure program.
• Implementation Guide—Acquirer (70014-01) v1.0.2—Provides acquirers with detailed
information about the functions, the use, and the benefits of 3-D Secure, and with
guidance in developing implementation programs for themselves and for their merchants.
• Implementation Guide—Merchant (70020-01) v1.0.2—Provides merchants with detailed
information about the functions, the use, and the benefits of 3-D Secure, and with
guidance in developing implementation programs.
• Compliance Testing Facility—Policies & Procedures (70017-01)—Describes the
compliance and auditing program, including policies, procedures, facilities, fees, kinds of
products tested, and legal agreements.
• Compliance Testing Facility—User Guide (70018-01)—Supplies detailed information
about using the compliance testing facility provided by Visa, including facility procedures;
the test tools and how to use them; the kinds of testing that are performed; controls;
and equipment configurations.
• Compliance Testing Facility—Test Scripts (70019-01), Licensed—Provides functional
descriptions and outlines of the test scenarios that vendors must perform to test their
products for compliance. Vendors use the scenarios to develop actual test scripts.
• System Test Facility—Policies and Procedures (70021-01)—Describes a testing
environment intended for use by vendors of 3-D Secure software components and by

Visa members to functionally test a software component (Access Control Server or
merchant server plug-in) for end-to-end payment transaction execution.
• Security Requirements—Enrollment and Access Control Servers (70016-01),
Licensed—Describes Visa requirements and standards that participants must meet, and
the process for approval and activation of a 3-D Secure Enrollment or Access Control
Server.


Part 5 Chip Card Services
Services, describes the services available through the V.I.P. System

Part 5, Chip Card Services
that use chip cards and terminals capable of reading chip cards in addition to magnetic
stripe cards.
Chapter 14, Visa Contactless Payment Service
Chapter 15, Visa Smart Debit/Smart Credit (VSDC) Service


Chapter 14 Visa Contactless Payment Service
Visa Contactless Payment Service


Chapter 14 Visa Contactless Payment Service
The V.I.P. System service description for the Visa Contactless Payment Service is under
development.


Chapter 15 Visa Smart Debit/Smart Credit (VSDC) Service
BRIEF.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
IN BRIEF 15-33
PARTICIPANTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
SUMMARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
REQUIREMENTS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
Authorization Feature Participation Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-6
Participation Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-6
Issuer Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-6
Acquirer Participation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-6
Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-7
Visa Test System (VTS /3). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-7
VisaNet Certification Management Service (VCMS). . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .15-8
Card Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-8
Preparation Activities to Avoid Erroneous Declines. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .15-8
Card Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-8
Cryptogram Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-10
Format Options for Chip Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-11
Third Bitmap Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-11

Field 55 Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-11
Field 55 Supplemental Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12
Field 55 vs. Third Bitmap Fields 130–149. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12
Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12
Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12
Offline Authorization Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12
Enhanced Cardholder Verification. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .15-13
Offline Data Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-14
Online Card and Issuer Authentication. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .15-14
Post-Issuance Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-15
Visa iCVV Convert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-16
VSDC PIN Management Service. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .15-17
Integrated Circuit Card CVV (iCVV). . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .15-17
Dynamic Card Verification Value (dCVV). . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .15-18
Alternative Primary Account Numbers. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .15-19
MESSAGES.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
20
WORKS.. . . . . . . . . . . .15-
HOW VISA SMART DEBIT/SMART CREDIT (VSDC) SERVICE WORKS 15-20
20

Chapter 15
V.I.P. Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22

SMS Routing and STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22
BASE I Routing and STIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22
Online Card and Issuer Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-26
Offline PIN Entry Attempt Limit Exceeded. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .15-27
dCVV Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28
“Fallback” Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-28
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
PROCESS FLOWS 15-28
28
FLOWS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
MESSAGE FLOWS 15-29
29
GLOSSARY.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
29
0100 Authorization and 0200 Financial Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-29
Third Bitmap Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-34
INFORMATION.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-
37

Chapter 15 Visa Smart Debit/Smart Credit (VSDC) Service
15.1 IN BRIEF
The Visa Smart Debit/Smart Credit (VSDC) Service provides members with a safe
and controlled means to incorporate credit and debit functionality into chip cards.
VSDC supports Visa, Visa Electron, and Plus card products, as well as contactless
transactions. The VSDC baseline product, the chip card, provides all debit and credit
functions currently available in a magnetic stripe product; it also has additional features that
allow issuers to customize their products and to accommodate their market strategy and
their customers' needs.
NOTE
A separate service description for contactless transactions and Dynamic Card Verification Value (dCVV)
processing is in development.
Whenever a cardholder uses a VSDC card at a chip-capable contact or contactless

terminal, the interaction between card and terminal provides new transaction security and
functionality. Based on issuer-selected features, the card and terminal interaction results
in a payment transaction similar to that performed with today's magnetic stripe cards.
However, with the VSDC Service, the card and terminal interaction can provide a suite of
optional risk control features, such as Offline Authorization Controls, Expanded Cardholder
Verification, and Data, Card and Issuer Authentication. Issuers can activate any or all of
these features (summarized below) during the card personalization process when they put
account information on the chip.

The VSDC Service features three VSDC card types:
• Visa Integrated Circuit Card Specifications (VIS)
• Common Core Definition (CCD)
• Generic EMV Transport
Each card type represents a set of specifications established by JCB, MasterCard, and Visa
(EMV) to maintain a common technical foundation for their respective chip-based payment
systems. Refer to “Card Types” in this chapter for a description of these card types.
Additionally, VSDC processing supports multiple formats for issuer application and
authentication data:
• Standard third bitmap format, which issuers that issue VIS or CCD cards can use.
Issuers that issue Generic EMV Transport cards do not use this format.
• Expanded third bitmap format, which acquirers can use.
• Field 55—Integrated Circuit Card (ICC)-Related Data format. Field 55 is a
tag-length-value (TLV) field that contains all of the data elements carried in the third
bitmap. Both acquirers and issuers can use this format, regardless of the VSDC card type.
NOTE
Visa recommends that acquirers that want to fully participate in the VSDC Service support the expanded
third bitmap format.

Chapter 15 Eligible Participants
IMPORTANT
Field 55 may contain tags that the receiving issuer or acquirer does not recognize or does not expect.
The receiver should ignore such tags and continue parsing the next tag in field 55.
Refer to “Third Bitmap Formats“ and to “Field 55 vs. Third Bitmap Fields 130–149“ in this
chapter for information about these formats.
The VSDC Service is available to members in all Visa regions.
BASE I
The VSDC Service is available both to BASE I System users and to Single
SMS Message System (SMS) users that process point-of sale or point-of-service
(POS) Visa and Visa Electron transactions, ATM transactions, or both.
BASE I and SMS
I
Participation in the VSDC Service is optional for issuers in all Visa regions.
Issuer
A Participation is mandatory for acquirers in the United States (U.S.) region and
is optional for acquirers in all other Visa regions.
Acquirer

The chip payment service framework was developed by three card associations:
JCB, MasterCard, and Visa (EMV).
The VSDC Service, which enables interaction between cards and terminals, only applies
to transactions initiated by the chip. Issuers can customize their programs to meet their
business requirements and control risk by incorporating any of the following features of
the VSDC Service:
Offline Authorization Controls—

Controls—The features allows issuers to set individual cardholder or
cardholder segment limits to control the circumstances in which transactions need to go
online for authorization. These controls reduce credit and fraud losses associated with
higher-risk accounts, especially in high-floor-limit environments.
Verification—The feature allows issuers to program the chip with

Expanded Cardholder Verification—
individual transaction characteristics so that a card and a terminal can determine the most

appropriate cardholder verification method to be used for a transaction. In addition, issuers

can use offline PIN verification to reduce exposure to lost and stolen cards.
Authentication—The chip provides protection against counterfeit at the point of

Offline Data Authentication—
transaction to reduce fraud losses. The terminal validates the card without requiring an
online message to the issuer. Two forms are available:
• Static Data Authentication (SDA)—SDA is similar to Card Verification Value (CVV and
iCVV) processing, but does not require an online message to the issuer.
• Dynamic Data Authentication (DDA)—DDA is similar to online card authentication method
(Online CAM) because it protects against skimming because, for each transaction, the
card generates a unique cryptographic value that the terminal validates offline.
Authentication—The feature offers online authentication as an
Online Card and Issuer Authentication—
anti-skimming method, through cryptographic control.
NOTE
Skimming means copying data from one card to another.
V.I.P. authenticates the card by validating the cryptogram in the request and sending the
results to the issuer. This ensures that the data on the card has not been altered and
that the card is genuine.
V.I.P. authenticates the issuer by generating the cryptogram and providing the results in
the response to the acquirer. This ensures that the card is communicating with its correct
issuer. This feature is valuable for electronic commerce (e-commerce) transactions.
Updates—Issuers can use the VSDC Service to change information on the

Post-Issuance Updates—
debit or credit application without reissuing the card. For instance, the issuer can change
the offline authorization controls when a cardholder's credit rating changes, or to block a

card, and enhance customer service by providing a way to change the cardholder’s PIN
immediately.

Participation in the VSDC Service is mandatory for acquirers in the United States (U.S.)
region and optional for members in all other Visa regions.
Participation requires that issuers place the magnetic stripe image (MSI), also referred to
as the Track 2-equivalent data, in the chip in all cards.
In addition to the requirements described in “Planning and Implementation” in this chapter,

issuers and acquirers must successfully complete testing to process VSDC transactions.
Additionally, issuers must establish V.I.P. stand-in processing (STIP) parameters for
issuer-available and issuer-unavailable conditions. Testing requirements include those for
the Dynamic Card Verification Value (dCVV), the third bitmap formats, field 55, and the
contactless indicator.
IMPORTANT
VisaNet uses the industry-standard Triple Data Encryption Standard (TDES) for all PIN-based Visa credit and
debit, Interlink, and Plus transactions processed through VisaNet. Refer to the Payment Technology Standards
Manual and to the Payment Card Industry PIN Security Requirements Manual for further information.

15.4.1 Authorization Feature Participation Requirements

Issuers can choose to use the Card Authentication feature and the Issuer Authentication
feature.
Online Card Authentication Method (Online CAM)—CAM)—V.I.P. validates the cryptogram in the
request and sends the results to the issuer. Issuers can choose to have V.I.P. perform the
validation for every transaction or only for those transactions processed by STIP, or can
choose not to use V.I.P. cryptogram authentication.
Authentication—V.I.P. generates the cryptogram and provides the results in the

Issuer Authentication—
response to the acquirer. Issuers can choose to have V.I.P. perform the process for every
transaction or only for those transactions processed by STIP, or can choose not to use
V.I.P. cryptogram generation.
To participate in these services, the issuer must securely transport its double-length
master key and related information to Visa—using a double-length Zone Control Master
Key (ZCMK)—or must allow VisaNet to generate the master key on the issuer's behalf.
For issuers choosing this option, VisaNet securely transports the key to the issuer (using
a double-length ZCMK).
15.4.2 Participation Levels
15.4.2.1 Issuer Participation

Issuers can participate in the VSDC Service at either the Full Data Option level or the
Early Data Option level. In addition to issuing VSDC cards, participation at the Full Data
Option level provides issuers with the full range of VSDC data and benefits, including
post-issuance updates to the cards.
IMPORTANT
Early chip BINs must be processed by processors that issuers establish as Early Data Option processors. Full
chip BINs must be processed by processors that issuers establish as Full Data Option processors.
If an issuer wants to receive early chip data for a BIN behind a Full Data Option processor, the processor
must convert full chip data to early chip data before forwarding the data to the issuer. VisaNet only sends
full chip data to the processor.
For more information about establishing participation parameters, issuers can contact
15.4.2.2 Acquirer Participation

Acquirers can choose to participate in the VSDC Service at a level called the Full Data
Option.
U.S. POS acquirers and acquirer processors must support contact and contactless chip
cards and must be able to carry full chip data in field 55.
With the Full Data option, acquirers support the third bitmap fields (fields 130–149) or
field 55. The Full Data option provides risk management capabilities such as checking the
validity of the card through offline data authentication, and verifying the cardholder through
offline PIN verification. Additionally, the Full Data option provides cryptographic controls

to improve data integrity and to protect against skimming, as well as dispute processing
protection to reduce requests for copies and for chargebacks.
IMPORTANT
Acquirers that want to fully participate in the VSDC Service must support field 55 or the third bitmap fields.
If acquirers do not support field 55 and use the standard third bitmap format, V.I.P. downgrades certain Visa
and Plus transactions. See “Card Types” in this chapter for more information.
15.4.3 Testing
This section summarizes the Visa Test System (VTS /3), the Visa Certification Management
Service (VCMS), card testing, and preparations for avoiding erroneous declines.
15.4.3.1 Visa Test System (VTS /3)

Visa has developed an enhanced test tool called Visa Test System - Version 3 (VTS /3)
that members can use for testing. This Visa provided software application simulates
V.I.P. transaction processing, and members use it for their host testing . VTS /3 includes
transaction databases that correspond to various Visa services, including VSDC. Members
use VTS /3 at their sites for internal testing. Regional staff also uses it to perform member
host testing.
When testing member host system changes for the VSDC Service, the region may run the
VTS /3 software on a PC connected to an EMV-compliant chip card reader. The PC also
connects to the member's VisaNet connection, which is connected to VCMS. To validate an
issuer's ability to process the new data in chip messages, the region uses this tool set-up
along with the issuer's test card to generate chip messages to the issuer.
For member internal testing, members can configure VTS /3 to run on a member's
dedicated PC connected to a test or production VisaNet connection or to run directly to

the member's host. Using test scripts obtained from the region, a member can use VTS /3
to initiate or to respond to transactions from its host. VTS /3 acts as an acquirer, as an
issuer, or as VisaNet, and responds with transactions residing in the appropriate database,
which are specified in the script.
Regional testing labs use VTS /3 to create test messages from issuer test cards for host
testing of VSDC programs. VTS /3 includes:
• Integrated chip card reader
• Chip-reading capability
• Data capture from chip read
• Transfer of chip data to VTS
• V.I.P. message formatting
Issuers can use VTS /3, version 19.0 or greater, to generate internal test data for
pre-testing. For members that still use an older version of VTS and older versions of
VTS2000, Visa will upgrade the software at no cost to the member.
The Visa region is responsible for distributing the software package to members together
with a Visa Test System - Version 3 User's Guide as part of the testing preparation process.
The Visa Test System - Version 3 User's Guide provides the region with tool set-up and
configuration specifications for VCMS. Existing testing procedures defined by the member's
Visa region for credit and debit cards apply to the VSDC Service.

15.4.3.2 VisaNet Certification Management Service (VCMS)

VCMS provides testing assistance for VSDC Service participants. Members can contact
their Visa representatives to make the arrangements. In preparing to support VSDC testing,
the regional testing lab should:
• Ensure regional functional connectivity to VCMS.
• Ensure member or processor connectivity to VCMS.
• Test regional VCMS connectivity and configuration with a magnetic stripe purchase
transaction.
• Review the VCMS Testing and Certification Guide, V.I.P. Services, to understand the
VCMS technical requirements.
15.4.3.3 Card Testing

For card testing, issuers must submit a card to their Visa regional representative.
15.4.3.4 Preparation Activities to Avoid Erroneous Declines

Additionally, Visa requires three activities to help issuers avoid erroneous declines at the
point of transaction. These activities vary, based on the features supported by the issuer.
• All issuers must synchronize magnetic stripe and chip information to ensure that the
information on the magnetic stripe (such as the account number or the expiration date)
is the same as in the chip magnetic stripe image (MSI), with the exception of the CVV
when the issuer supports iCVV or dCVV verification. See the Card Verification Value
(CVV) Service chapter in Volume 2 for information about CVVs and iCVVs.
• Issuers supporting Static Data Authentication (SDA) must successfully complete the SDA
process to ensure that the public key-related information has been correctly placed on
the card.
• Issuers supporting online card authentication method (Online CAM) and issuer
authentication must successfully complete the card authentication process to make sure
the Data Encryption Standard (DES) key information on the card is synchronized with the
DES key information in the host system.
15.4.4 Card Types

VisaNet supports three EMV card types and processing options for VSDC card transactions,
all of which are optional for members:

• The Visa Integrated Circuit Card Speci�cations (VIS) is the Visa-specific implementation
of the EMV specifications. VIS capabilities include the following:
- Acquirers can send VIS chip data in field 55 or in fields 130–149, using the expanded
- Issuers can send and receive VIS chip data in field 55 or in fields 130–149 using the
unexpanded third bitmap format.
- VIS chip data is eligible for both the Card Authentication and Issuer Authentication
features.
- VIS transactions are eligible for the enhanced VSDC routing and STIP capabilities
based on specific terminal or card verification results.
VIS cards that use cryptogram version 2 have the following characteristics:
- Issuer Application Data (IAD) is supported in expanded format of field 134.
- Issuer Application Data (IAD) is 32 bytes long.
- Issuers can send and receive VIS chip data in field 55.
• The Common Core De�nition (CCD) is a newer EMV card type that contains the same
data as the VIS card type but with expanded chip-to-issuer processor communication,
external data flow controls, and issuer application and authentication data controls.
- Acquirers can send CCD chip data in field 55 or in fields 130–149 using the expanded
- Issuers can send and receive CCD chip data in field 55 or in fields 130–149 using
the unexpanded third bitmap format. See “Third Bitmap Formats” in this chapter for
an explanation of these bitmaps.
- CCD chip data is eligible for both the Card Authentication and Issuer Authentication
features.
- CCD card type transactions are eligible for enhanced VSDC routing and STIP
capabilities based on specific terminal or card verification results.

NOTE
Issuers can issue VIS- and CCD-compliant cards from the same BINs.
• The Generic EMV Transport (Generic EMV) card type does not comply with VIS or CCD
specifications but does meet general EMV specifications such as data element length
parameters. Issuers define Generic EMV data elements such as issuer authentication
data and therefore, V.I.P. considers them to be non-standard for V.I.P. processing.
Thus, V.I.P. treats Generic EMV requests as “pass through” transactions, providing
PIN translation and basic routing services, but not field content editing or card or issuer
authentication.
- Generic EMV card types require issuers to use a separate, dedicated BIN that must
support field 55.
- Acquirers must submit Generic EMV chip data in field 55 or in fields 130–149 using the
expanded third bitmap format.
- Issuers must use field 55 to send and receive Generic EMV chip data.
- STIP is unavailable for Generic EMV transactions. Unless issuers specify otherwise,
V.I.P. declines issuer-unavailable requests with default field 39 response code 91
(issuer unavailable). Issuers that want to use the CCD and Generic EMV card types
must contact their Visa representatives.
NOTE
V.I.P. downgrades the transaction and drops the chip data from the message when an acquirer who has not
migrated to field 55 or the expanded third bitmap format submits CCD or Generic EMV chip data. V.I.P.
inserts a value of 3 in Field 60.6—Chip Transaction Indicator to notify issuers that V.I.P. dropped the chip
data because the acquirer used the unexpanded format of the third bitmap data.
15.4.5 Cryptogram Requirements

Issuers must use the following cryptogram versions for card authentication cryptograms.
Card Type Cryptogram Version Number

VIS 2, 10, 17, and 18
VIS 12 and 50 to 59 (proprietary)
CCD 5
CCD 4 to F (reserved), 1 to 3 (proprietary)
Generic EMV Issuer-defined
Cryptogram version 2, 10, 17, and 18 uses the card verification results (CVR) from the issuer
application data. Additionally, when generating a cryptogram for each VIS transaction,
cryptogram version 10 uses a derived key loaded on the card during personalization.
Cryptogram version 12, and versions 50 to 59 are issuer-proprietary cryptograms, and

therefore the Visa authentication services do not apply. For further information about
cryptogram versions, including the specific input sequence of the fields and tag-length-value
(TLV) tags for the cryptogram algorithms, refer to the most recent version of the VSDC
System Technical Manual.

15.4.6 Format Options for Chip Data

Acquirers and issuers can use either the third bitmap, fields 130–149, or field 55 to send
and to receive chip data. Additionally, third bitmap members can optionally use field 55 to
send and to receive supplemental data, which is data that the third bitmap does not support.
NOTE
All Full Data acquirers and issuers must successfully complete testing to use either the third bitmap or field 55
to exchange chip data.
Regardless of the format used to submit chip data, V.I.P. converts the chip data into the
format that is appropriate for the receiving member, such as a conversion from third bitmap
to field 55 or expanded third bitmap to unexpanded (standard) third bitmap.
15.4.6.1 Third Bitmap Formats

VSDC supports two third bitmap formats for processing Visa and issuer discretionary
data: unexpanded and expanded.
Acquirers can optionally use the expanded third bitmap format in requests to support all
three card types. In this format, field 134 contains both the Visa discretionary data and
the issuer discretionary data in a format called issuer application data (IAD). The IAD
information supports card verification, offline processing, and online updates between the
issuer and the card. Expanded format messages do not use field 135.
If the issuer performs the authentication, or if V.I.P. performs it on the issuer's behalf,
field 140 is used for the authentication data and response code. The issuer authentication
data format in field 140 matches the chip card's format; no EBCDIC-to-ASCII data
conversion is necessary.
Issuers can optionally use the standard third bitmap format in responses to support VIS and

CCD card types. In this format, the IAD spans two fields in which field 134 contains the
Visa discretionary data and field 135 contains the issuer discretionary data. However, for
VIS cards using cryptogram version 2, issuers do not use third bitmap formats. Issuers
send issuer authentication data in field 139 in responses.
15.4.6.2 Field 55 Format

Acquirers and issuers can optionally use the field 55 format in request and response
messages to support all three card types. This field is defined as Tag-Length-Value (TLV)
format and contains all the chip data, including supplemental data.
U.S. POS acquirers and acquirer processors must support contact and contactless chip
cards and must be able to carry full chip data in field 55.
NOTE
Issuers must use field 55 for generic EMV transactions.
Issuers use field 55 for VIS transactions with cryptogram version 2.
IMPORTANT
Endpoints that support this field must be able to receive any dataset IDs and tags defined for this field in any
order, including those that they do not recognize or expect. Endpoints may receive multiple datasets in this
field. Endpoints must ignore any dataset IDs or tags they do not recognize and continue to process the field.

15.4.6.3 Field 55 Supplemental Data

Acquirers and issuers can optionally use field 55 to send one another BER TLV-formatted
data (for instance, market-specific information), regardless of whether field 55 or
fields 130–149 is used for chip data. V.I.P. does not edit this supplemental data. Field 55
usage is available by default to acquirers and issuers that use field 55 to send and receive
chip data. Third bitmap acquirers and issuers must successfully complete testing to use
field 55 for supplemental data.
VCMS is available for testing. Additionally, there must be a bilateral agreement between
participating issuers and acquirers. Members can contact their Visa representatives for
further information.
15.4.7 Field 55 vs. Third Bitmap Fields 130–149

Depending on the card type, field 55 or the third bitmap fields may be used for chip data.
Full data members must successfully complete testing for their format preference, field 55
or the expanded third bitmap format. V.I.P. transfers the chip data between formats as
appropriate for the destination endpoint.
• Acquirers can use field 55 or the expanded third bitmap format.
• Issuers that issue VIS or CCD cards can use field 55 or the standard third bitmap format.
• Issuers that issue Generic EMV-compliant cards must use a separate, dedicated BIN,
and that BIN must use only field 55.
Acquirers must use the chip transaction indicator in field 60.6 to indicate whether the chip
data is in field 55 or is in the expanded third bitmap format (field 60.6 = 2). If chip data
is present but field 60.6 is not, V.I.P. removes the chip data and processes the request
as a magnetic stripe transaction.
If fully participating VSDC acquirers do not support field 55 or the expanded third bitmap
and submit CCD or Generic EMV chip data in the unexpanded third bitmap format, V.I.P.
drops the chip data from the message and inserts a value of 3 in field 60.6 to notify issuers
that V.I.P. dropped the chip data because the acquirer used the unexpanded format of the
third bitmap data. Additionally, V.I.P. downgrades the transaction.

Service monitoring is not available for the VSDC Service.

Members should consider the following important points when planning to implement
the VSDC Service.
15.4.9.1 Offline Authorization Controls

Acquirers and issuers determine offline authorization controls.
Controls—In addition to traditional processing restrictions

Acquirer Offline Authorization Controls—
(such as the service code and the expiration date), the acquirer can contribute to offline risk
management processing through features in the terminal software.

• Terminal Random Selection—This control protects against fraudulent cards designed to

operate exclusively offline by allowing the terminal to randomly select transactions for
online processing.
• Terminal Floor Limit—VSDC continues to use merchant floor limits. Even when the
card does not require a transaction to be processed online, V.I.P. always sends an
above-floor-limit transaction online for issuer processing.
Controls—Issuers can set card limits that help determine the
Issuer Offline Authorization Controls—
circumstances in which transactions need to go online for authorization or may be approved
offline. These limits include:
• Controls that limit the total number of consecutive offline authorizations permitted for a
card before the issuer requires an online authorization. For instance, the issuer can allow
the card to be used offline for three consecutive transactions, but when the cardholder
presents the card for a fourth time, the chip requests an online authorization. Issuers can
define a separate counter for international transactions.
• Controls for domestic transactions that establish a threshold amount on the card allowing
the cardholder to make consecutive purchases offline up to a specified amount before
triggering an online transaction. For instance, the issuer can place an offline cumulative
amount of USD$30.00 on a particular card. The cardholder makes two transactions for
USD$14.00 each, followed by a transaction for USD$10.00. The first two transactions are
authorized offline, but the third requires online authorization.
Issuer responsibilities in support of the Offline Authorization Controls feature include
determining the appropriate offline authorization controls for individual cardholders or
for cardholder segments, and placing authorization control data on the card during
personalization.
For complete information about available card limits and about related issuer
responsibilities, refer to Section 11.4.2, “VIS Card Volume,” of the Visa Integrated Circuit

Card Specifications (VIS) manual.
15.4.9.2 Enhanced Cardholder Verification

Issuers can tailor cardholder verification requirements to the transaction environment
through the use of a prioritized list of preferred cardholder verification methods. The list
may include offline PIN, online PIN, and signature verification. Based on the individual
transaction characteristics (such as the merchant environment, terminal capabilities, and
the transaction amount), the chip device determines the appropriate cardholder verification
method for each transaction.
VSDC enables issuers to support two forms of offline PIN verification:

• Offline Plaintext PIN
• Offline Enciphered PIN
These methods enable the terminal to validate the PIN offline at the point of transaction,
eliminating the costs and the complications associated with online PIN support across the
network.
Issuer responsibilities in support of the enhanced cardholder verification features include:

• Prioritizing the list of cardholder verification methods and defining the conditions under
which each method is to be used.
• Placing the prioritized list information on the card during personalization.

• Including the data required for offline PIN verification, if supported.

• Determining the action the card should take (approve, decline, or send the transaction
online) if offline PIN verification fails, if the issuer supports offline PIN verification.
EXAMPLE
The issuer can instruct the card to use offline PIN verification when the terminal supports offline PIN, and to
use signature verification when the terminal does not.
or
The issuer can require offline PIN verification on high-value transactions and signature verification on
small-ticket transactions.
For more information, refer to the Visa Integrated Circuit Card Specifications (VIS) manual,
to the Visa Smart Debit and Credit Member Implementation Guide for Issuers, and to the
most recent version of the VSDC System Technical Manual.
15.4.9.3 Offline Data Authentication

Three offline data authentication options are available to protect against counterfeit at
the point of transaction:
(SDA)—SDA provides similar counterfeit protection as does the

Static Data Authentication (SDA)—
Card Verification Value (CVV) Service by providing assurance that the static data from the
chip has not been altered.
(DDA)—DDA adds a second level of protection by assuring

Dynamic Data Authentication (DDA)—
that the chip is valid and that the data was not skimmed.
(CDA+)—CDA+ adds a third level

Combined DDA/Application Cryptogram Generation Plus (CDA+)—
of protection by assuring that the data exchanged between the card and the chip device has
not been altered. CDA+ is similar to DDA except that the DES application cryptogram is
part of the dynamic signature, which proves that the cryptogram came from the valid card.
Issuer responsibilities in support of the Offline Data Authentication feature include:

• Supporting new public key management procedures.
• Including the key-related information necessary for offline data authentication in card
personalization.
• Determining the action the card is to take if offline data authentication fails (approve,
decline, or send the transaction online).
For a complete list of issuer support responsibilities, refer to Visa Smart Debit and Credit
Member Implementation Guide for Issuers.
15.4.9.4 Online Card and Issuer Authentication

Through the use of DES key technology, the issuer has the ability to validate the card,
and the card has the ability to validate the issuer. Issuers of EMV-compliant contact and
VCPS-compliant (version 2.0.2 or later) contactless cards are required to validate EMV
cryptograms in all online authorization messages. Issuers can have third parties, including
VisaNet, perform these validations.
Authentication—Using transaction data and a secret DES key stored in the

Online Card Authentication—
chip, the chip calculates a cryptogram that is sent with the online authorization message to
the issuer along with the data needed to validate the cryptogram. This cryptogram and the

card data are unique for each transaction. The issuer validates the card by checking the
cryptogram. The issuer can use the results of the validation in the authorization decision.
Authentication—Issuers have the option of sending a cryptogram to the

Online Issuer Authentication—
card in the response message. The card validates the cryptogram to ensure that it is
communicating with the correct issuer.
Issuer responsibilities in support of the Online Card and Issuer Authentication features
include:
• Developing additional key management procedures.
• Including the key required for online card and issuer authentication in card personalization.
• Upgrading host security modules to support online card and issuer authentication.
• Including results of authentication in authorization decisions.
Visa Smart Debit and Credit Member Implementation Guide for Issuers contains a complete
list of issuer support responsibilities.
Issuers can choose to have V.I.P. perform the authentication services on their behalf.
Transactions—V.I.P. supports Visa payWave ATM transactions in

Visa payWave ATM Transactions—
network 0002 and network 0004. Acquirers that choose to implement Visa payWave ATM
transactions must support full chip data.
Acquirers that implement these transactions for the first time must use full chip data in
Field 55, Usage 1—VSDC Chip Data. However, acquirers that currently use the expanded
third bitmap format may continue to use their existing format for processing Visa payWave
ATM transactions.
Acquirers and issuers must support the following key fields and data requirements to

process Visa payWave ATM transactions:
• Field 18—Merchant Type, with a value of 6011 (ATM)
• Field 22—Point-of-Service Entry Mode Code, with one of the following values:
- 07 (Contactless device-read-originated using VSDC chip data rules; Online CAM, iCVV,
or CVV check is possible)
- 91 (Contactless device-read originated using magnetic stripe data rules; Online CAM,
dCVV, iCVV, or CVV check is possible)
• Field 60.2—Terminal Entry Capability, with one of the following values:
- 5 (Contact chip, magnetic-stripe, and may include proximity capable terminal) to indicate
that the terminal can read the chip and the magnetic stripe on the card
- 8 (Proximity-read-capable) to indicate that the terminal can read a proximity chip (using
a Visa contactless specification) but cannot read a contact chip on a card.
15.4.9.5 Post-Issuance Updates

When the transaction is sent online to the issuer, the issuer can use authorization or
financial responses to update data on the card. Among other capabilities, issuers can block
or unblock the application or the card, can update the card's authorization parameters,
and can change or block the cardholder's offline PIN. Issuer responsibilities in support of
the Post-Issuance Update feature include:

• Developing additional key management procedures.

• Including keys in card personalization procedures.
• Upgrading host systems to generate post-issuance updates.
• Supporting new response data in host systems and over networks.
• Upgrading card management systems to track updates to the card.
Visa Smart Debit and Credit Member Implementation Guide for Issuers contains a complete
list of issuer support responsibilities.
15.4.9.6 Visa iCVV Convert

The Visa iCVV Convert Service validates and converts a chip-based transaction to appear
as a magnetic stripe-based transaction. VisaNet validates the cryptogram, removes
unnecessary chip data, and submits the authorization request to participating issuers.
Issuers can participate in this service optionally. Visa iCVV Convert is available both for
BASE I and SMS users, and also supports contactless chip transactions.
For participating issuers, VisaNet makes changes to the following fields before forwarding
the authorization request:
• Field 55—Integrated Circuit Card (ICC)-Related Data is removed.
• Field 23—Card Sequence Number is removed.
• Field 44.8—Card Authentication Results Code is removed.
• Field 60.3 (Chip Condition Code), Field 60.6 (Chip Transaction Indicator), and Field 60.7
(Chip Card Authentication Reliability Indicator) are zero-filled, or dropped if no subsequent
field 60 subfields are present.
• Field 39—VisaNet does not send Online CAM authentication results (response code 82 82),
Y1,
and offline approval (Y1 Y3) or decline (Z1
Y1 Y3 Z1, Z3) response codes to participating
Z1 Z3
issuers—VisaNet converts Y1 and Y3 to 00 (Approved) and Z1 and Z3 to 05 (Do not
honor) before sending them to participating issuers. However, the response codes Y1 Y1,
Y2, Z1 and Z3 are sent in 0120/0220 advices to participating issuers. CVV results are
Y2
sent in field 44.5.
If the issuer participates in Visa iCVV Convert and the transaction passes Online Card
Authentication Method (Online CAM), VisaNet replaces the iCVV present in the track data
(field 35 or field 45) with a VisaNet-generated CVV. In such instances, iCVV checking is not
performed. However, If the issuer participates in Visa iCVV Convert, but the transaction
fails Online CAM, VisaNet declines the transaction with a response code value of 05 (Do
Not Honor) in field 39.
If chip data for Online CAM validation is not present in the request message, VisaNet
performs iCVV validation. If the transaction passes iCVV validation, VisaNet replaces
the iCVV present in the track data (field 35 or field 45) with a VisaNet-generated CVV.
However, if the transaction fails iCVV validation, VisaNet declines the transaction with
response code 05 (do not honor).
VisaNet declines the transaction with response code 05 (do not honor) if the issuer
participates in Visa iCVV Convert, but the issuer's MDK (Online CAM) and CVK (CVV)
are not present.

15.4.9.7 VSDC PIN Management Service

The VSDC PIN Management Service allows Visa card cardholders to change or unblock
PINs in VSDC cards. The service supports all three card types—VIS, CCD, and Generic
EMV Transport.
After the cardholder enters the new PIN twice, the acquirer forwards the new PIN in a “zero
amount” 0100 authorization request to the issuer for approval. Acquirers do not include
Field 54—Additional Amounts in the request. Processing code 70 in Field 3—Processing
Code indicates a PIN change; processing code 72 indicates a PIN unblock.
IMPORTANT
V.I.P. does not check to see if either the issuer or the acquirer is a VSDC participant when it receives a PIN
change or unblock 0110 response. V.I.P. considers an 0110 response without field 54 and with a value of 70 in
field 3 to be a PIN change transaction, and with a value of 72 in field 3 to be a PIN unblock transaction. (V.I.P.
considers an 0110 response with field 54 and a value of 72 in field 3 to be a prepaid activation message.)
The current PIN information is in fields 52 and 53; the new PIN is in field 152. Approvals
receive response code 85 (no reason to decline) in field 39. PIN change or unblock
requests bypass activity checking and are not eligible for Positive Authorization Capacity
Management (PACM) processing or for STIP. If the issuer is unavailable or the request has
timed out, STIP responds with response code 91 (issuer unavailable) in field 39. Table 15-1
lists the field 39 response codes specific to the PIN Management Service.
Table 15-1 PIN Management-Specific Response Code Definitions
Code Definition
12 PIN Change/Unblock: PIN Change/Unblock Service participants must also
participate in the VSDC service, and the transaction must include required VSDC
data.

57 PIN Change/Unblock: Issuer is not a service participant.
58 PIN Change/Unblock: Acquirer is not a service participant.
85 PIN Change/Unblock: Approved (no reason to decline). This approval is valid only if
the response contains field 55, tag 71 or 72 (issuer script). If the issuer script is not
present, V.I.P. rejects the response back to the issuer.
91 PIN Change/Unblock: Issuer is not available.
P5 PIN Change/Unblock: Denied PIN Unblock—This code indicates that the issuer
declined either the PIN change or PIN unblock request.
P6 PIN Change/Unblock: Denied PIN Change—This code indicates that the requested
new PIN is unsafe.
VisaNet does not include CVV or PIN verification with PIN management processing, only
PIN translation. However, Visa PIN Management Service participants may also participate
in the PIN Verification Service (PVS) and in the Card Verification Value (CVV) Service.
15.4.9.8 Integrated Circuit Card CVV (iCVV)

VSDC cards contain an image of the magnetic stripe data in the chip as well as a physical
magnetic stripe. The magnetic stripe image (MSI), or Track 2-equivalent data, on the chip
contains identical data to that on the physical magnetic stripe, except that the 3-digit CVV
on the chip's magnetic stripe image can optionally be different from the CVV encoded on

the physical magnetic stripe. When the chip's CVV is different from that on the physical
magnetic stripe, it is referred to as an Integrated Circuit Card CVV (iCVV).
NOTE
The iCVV is sometimes referred to as the alternate CVV.
The acquirer transmits the chip's MSI in the same fields used for the magnetic stripe
(fields 35 and 45). The presence of code 05 or 95 in Field 22—Point-of-Service Entry Mode
Code (positions 1–2) indicates that the track data originated from a VSDC chip; this process
also assumes that the issuer participates in the VSDC Service and that expiration date
ranges are set in the system files. For chip-read transactions, code 95 in field 22 indicates
that CVV or iCVV checking may not be possible in the same way that code 02 in field 22
indicates that CVV or iCVV checking may not be possible for magnetic stripe transactions.
For all practical purposes, CVV or iCVV verification processing and CVV and iCVV service
options are the same. The same CVV options, parameters, and keys used to process
CVVs are used to process iCVVs. The only difference is that when V.I.P. validates the
iCVV, it uses a value of 999 for the service restriction code in the calculation process.
Refer to the Card Verification Value (CVV) Service chapter in Volume 2 for further
iCVV information. Refer to the Payment Technology Standards Manual for technical
specifications for CVV placement, calculation, and verification.
Members can contact their Visa representatives to make all service activation arrangements
and changes to their existing service specifications.
15.4.9.9 Dynamic Card Verification Value (dCVV)

The dCVV is the card verification value scheme for Visa Contactless Payment Service
transactions. Valid for BASE I and SMS, the Visa Contactless Payment Service uses POS
terminals with RF or infrared wireless protocols to obtain cardholder data from the card
without physical card-and-terminal contact other than initially tapping the terminal with
the card to initiate the process. The dCVV data uses a dynamically calculated 3-digit
verification value and an application transaction counter (ATC), which records the number
of transactions to date. A dCVV is generated for each transaction; the value is inserted in
the magnetic stripe data forwarded to the acquirer, replacing any CVV data that may be
on the actual track.
V.I.P. identifies a contactless authorization or financial request by the values in the

following fields:
• Field 22—POS Entry Mode Code must contain code 07 (proximity payment using VSDC
chip rules). dCVVs are generated only for contactless Track 1- or Track 2-equivalent
transactions. While a card can contain both a dCVV and a CVV/iCVV, they are mutually
exclusive. V.I.P. does not verify a dCVV and a CVV in the same transaction. Additionally,
the presence of a dCVV overrides the presence of any CVV2.
• Field 60.2—Terminal Entry Capability: Acquirers in the Visa U.S.A. (U.S.) region must
insert code 8 (contactless-read capability) in this field. Acquirers in all other regions do
not have to use code 8.

NOTE
To obtain additional chargeback protection for Custom Payment Service (CPS)-qualified RFID transactions,
in addition to the field 22 and field 60.2 requirements above, the amount in Field 4—Amount, Transaction
must not exceed $24.99.
The participating issuer, or V.I.P. acting on the issuer's behalf, generates a dCVV from
the request message information for comparison with the dCVV in the request. If V.I.P.
validates the dCVV in the request, it uses field 44.5 to convey the results to the issuer
(fail = 1, pass = 2), depending on the issuer's service participation settings. Field 44.5
is also used to send dCVV result codes in responses to participating acquirers. If a
dCVV fails verification, V.I.P. does not check the CVV on the physical magnetic stripe;
it either declines the transaction, forwards it to available issuers, or sends it to STIP for
issuer-specified processing.
dCVVs are generated only for contactless Track 2-equivalent transactions. While a card
can contain both a dCVV and a CVV/iCVV, they are mutually exclusive. V.I.P. does
not validate or verify a dCVV and a CVV in the same transaction. Additionally, a dCVV
overrides the presence of any CVV2.
The dCVV Service is optional for issuers. The dCVV Service is an add-on to the CVV
Service; thus, participation in the CVV Service is required before participation in the dCVV
Service. dCVV validation processing and CVV/iCVV service options are similar to those
for CVV/iCVV; for instance, with the All Respond option V.I.P. always performs dCVV
validation on behalf of the issuer, and if the validation fails, STIP responds to the acquirer
with an issuer-specified response code. The dCVV Service does not require new keys but
does use a different algorithm to dynamically generate the verification value.
This section only summarizes contactless transaction processing as it pertains to Visa chip

cards. Visa publications describing contactless technology and contactless transaction
processing, include the Visa Contactless Payment Program Technical Implementation
Guide, the Visa U.S.A. Contactless Payment Program—Member Implementation Guide,
and the Visa Contactless Payment Specification—Based on ISO 14443 Type A and
Type B, Version 1.4.2. Also see the Visa Contactless Payment Service (VCPS) chapter
in this manual.
15.4.9.10 Alternative Primary Account Numbers

V.I.P. supports chip cards having an alternative primary account number (PAN) stored
on the chip. This PAN is different from the PAN embossed on the card, and serves
as a security measure to prevent counterfeit chip cards from being used for non-chip
transactions. Alternative PAN processing applies to VIS, CCD, and Generic EMV Transport
cards, and to all cryptogram version numbers (CVNs) supported. V.I.P. account ranges can
be set up to indicate alternative PAN support. V.I.P. declines a transaction with response
code 59 (suspected fraud) if all of the following apply:
• The account range of the card indicates that it supports an alternative PAN.
• Field 22 does not contain 0505, 07
07, 91
91, or 95
95.
• Chip data is not present in field 55 or the third bitmap fields.


Table 15-2 lists the BASE I and the SMS message types valid for VSDC processing.
Table 15-2 Valid BASE I and SMS Message Types for VSDC Processing
Message Type BASE I SMS

0100 and 0110—POS Authorization ✓ ✓
0100 and 0110—POS Account Verification ✓ ✓
0100 and 0110—ATM Cash Disbursement ✓ ✓
0100 and 0110—ATM Balance Inquiry ✓ ✓
0100 and 0110—POS Balance Inquiry ✓ ✓
0120 and 0130—STIP or Informational Advice ✓ ✓
0200 and 0210—Financial Transaction ✓
0200 and 0210—ATM Balance Inquiry ✓
0200 and 0210—POS Balance Inquiry ✓
0220 and 0230—Adjustment ✓
0220 and 0230—Representment ✓
0400 and 0410—Reversal ✓ ✓
0422 and 0432—Chargeback ✓
0422 and 0432—Chargeback Reversal ✓
0620 and 0630—Informational Message ✓
15.6 HOW VISA SMART DEBIT/SMART CREDIT (VSDC) SERVICE WORKS

During the processing of a VSDC transaction, the chip card remains in the terminal's chip
reader. When the transaction is complete, the merchant, clerk, or cardholder removes the
chip card. VSDC processing comprises the following steps. Depending on the options
selected by the issuer, the terminal may not perform all of these functions.
Selection—When the chip card is inserted in the terminal's chip reader,
1. Application Selection—
the terminal identifies which applications are supported both by the card and by the
terminal. If there are no common applications, the terminal terminates the transaction. If
the card and the terminal have only one application in common, the terminal uses that
application. If the card and the terminal have more than one common application,
the cardholder makes a selection from the list displayed on the terminal, if cardholder
application selection is supported, or the terminal selects the application with the highest
priority, or the terminal selects the application with the highest priority that does not
require cardholder confirmation.
NOTE
Only Visa card transactions with chip and proximity payment service codes of 2 or 6 in the first digit, and
acquirer transactions with chip and payWave values in the POS Entry Mode Code (field 22 = 05 05, 07
07, 91 or
95) are permitted for cashback. V.I.P. rejects cashback transactions that do not meet these criteria.
95
2. Offline Transaction Processing—

Processing—The card and the terminal perform the following
functions based on an issuer-defined list of supported features that the card sends to
the terminal and on the capabilities of the terminal:

Chapter 15 How Visa Smart Debit/Smart Credit (VSDC) Service Works
- Offline Authorization Controls—The terminal checks the controls on the card, including
the offline transaction limit and the offline cumulative amount.
- Offline Data Authentication—The terminal validates card data using public key
technology to ensure that the card has not been altered since it was issued.
Depending on the terminal type, the terminal uses Static Data Authentication (SDA),
Dynamic Data Authentication (DDA), or the Combined DDA/Application Cryptogram
Generation (CDA) method. VSDC-compliant terminals are EMVCo Type Approval
Levels 1 and 2. SDA and DDA do not require online-only terminals.
- Cardholder Verification—How the cardholder verifies his or her identity is governed
by Visa International Operating Regulations and by the card's personalized
issuer-specified parameters. Verification methods include cardholder signature, offline
PIN, or online PIN. The chip card's hierarchically-organized Cardholder Verification
Method (CVM) list stores the verification parameters. For offline PIN, the terminal
asks the cardholder to enter his or her PIN, which the terminal sends to the card
for comparison to the PIN in the card.
When the terminal completes offline risk management functions, the card and the
terminal use the results of the offline authorization control checking, offline data
authentication, and offline PIN verification to determine how to process the transaction.
When a risk management parameter is triggered (such as offline data authentication
failure or offline PIN failure), issuer-encoded instructions on the card and Visa-encoded
instructions in the terminal determine whether the terminal sends the transaction online
to the issuer for approval, or whether the terminal declines the transaction offline.
For transactions approved offline, proceed to step 7.
For transactions sent online, proceed to step 3.
Transactions—When the card and the terminal decide to send a transaction
3. Online Transactions—
online, the chip generates a cryptogram, which is called the authorization request

cryptogram (ARQC). A cryptogram is the result of card, terminal, and transaction data
encrypted by a secret key. The cryptogram is unique for each transaction. The chip
card sends the cryptogram and the data to the terminal which forwards the cryptogram,
along with the data elements used by the chip to create the cryptogram, and other
card-defining data such as the card type (for instance, CCD), to the acquirer. The
acquirer formats this data into the 0100 authorization or 0200 financial message and
forwards it to the issuer through VisaNet.
Processing—V.I.P. processes a VSDC transaction and authenticates the
4. V.I.P. Processing—
cryptogram depending on the issuer's STIP and routing parameters as well as on card
and terminal data.
See “V.I.P. Processing” in this chapter for more information.
Processing—The issuer validates the cryptogram and uses the results of online
5. Issuer Processing—
card authentication method (Online CAM) in its authorization decision. The issuer may
also use the offline risk management results, such as offline PIN verification and offline
data authentication, to determine the authorization response.
Response—To protect the issuer's authorization response and to ensure that
6. Issuer Response—
the response came from the valid issuer, the issuer can send a cryptogram for online
issuer authentication in the response. This cryptogram is called the authorization
response cryptogram (ARPC). The issuer can optionally send post-issuance updates
to the card in the response. These updates occur only after the card ensures that it is

communicating with the correct issuer. The terminal uses the authorization response
code to determine whether the transaction is approved or is declined.
Settlement—The card generates a final cryptogram called the transaction
7. Clearing and Settlement—
certificate (TC) for approved offline and online transactions. This cryptogram and its
supporting data elements represent the audit trail, which provides evidence of the
activities performed by the card and by the terminal at the point of service, and is
included with the clearing message for any dispute processing. After the card generates
the final cryptogram, the terminal captures and stores the transaction information. This
information is submitted during the regular clearing and settlement process.
15.6.1 V.I.P. Processing

VSDC transactions adhere to the same V.I.P. processing requirements as those for
non-chip transactions. They must also meet chip-specific requirements. See “Key Fields
Glossary” in this chapter for key field requirement details for VSDC transactions.
15.6.2 SMS Routing and STIP

V.I.P. routes all SMS VSDC transactions to available issuers. V.I.P. forwards a transaction
to STIP only if the issuer is unavailable or if directed by the Positive Authorization Capacity
Management (PACM) Service. STIP processes the transaction according to issuer-defined
parameters.
Issuers can set the following preferences separately for domestic and international chip
transactions (in which the chip magnetic-stripe is read, or in which no PIN is entered when
it is required and a PIN pad is present):
• Route to issuer (yes or no).
• STIP response (approve or decline).
15.6.3 BASE I Routing and STIP

Certain VSDC-specific field conditions in the request influence the V.I.P. decision to route
VSDC transactions to the issuer or to STIP. If card authentication is successful but the
issuer is unavailable, V.I.P. forwards the transaction to STIP for an approval or decline
decision based on issuer-specified parameters.
• VSDC routing takes precedence over Positive Cardholder Authorization Service (PCAS)
routing parameters. See the Positive Cardholder Authorization Service (PCAS) chapter
in Volume 2 for information about PCAS routing.
• Positive Authorization Capacity Management (PACM) Service routing takes precedence
over VSDC routing. See the Positive Authorization Capacity Management (PACM)
Service chapter in Volume 2 for information about PACM routing.
Routing parameters based on card authentication and on card and terminal conditions,
as well as STIP availability for issuer-unavailable conditions, apply to VIS and CCD card
types only.
VSDC requests for VIS and CCD card types are eligible for Positive Authorization Capacity
Management (PACM) Service processing, Positive Cardholder Authorization Service
(PCAS) processing, and STIP. The following are issuer-optional V.I.P. actions for a VSDC
transaction when the issuer has specified “route to issuer” in the system tables:

• If PACM parameters indicate “perform STIP,” V.I.P. sends the transaction to STIP.
• If PCAS parameters indicate “perform STIP”, V.I.P. sends the transaction to available
issuers.
• If Field 22—POS Entry Mode Code contains code 05
05, 07
07, or 95
95, and the issuer application
data (IAD) in field 55 (tag 9F10) or in fields 134 and 135 exceeds 7 bytes for VIS chip
card types (the total IAD length exceeds 7 bytes), or IAD bytes 19–32 does not equal
binary zero for CCD chip card types, V.I.P. sends the transaction to available issuers.
If issuers are unavailable, V.I.P. reroutes the chip transactions to STIP, which applies
issuer-specified processing parameters.
VisaNet always sends Generic EMV Transport transactions to available issuers or declines
them in STIP with response code 91 if the issuer is unavailable.
If Field 60.7—Chip Card Authentication Reliability Indicator is present in a VIS or CCD card
zero, V.I.P. force-routes the transaction to the
type transaction with a value other than zero
issuer. If the issuer is unavailable, V.I.P. forwards it to STIP, during which issuer-defined
rules specific to authenticating chip transactions are applied in addition to regular STIP
parameters. These rules relate to 24 card and terminal conditions with respect to the three
card authentication conditions. Table 15-3 lists these conditions.
Table 15-3 Card Authentication in STIP
Chip Card Card and Terminal Card Authentication

Authentication Conditions Conditions
Card Authentication Reliability Indicator Considered Considered
Successful Not critical to decision Yes Not critical to decision
Failed 0 or not present Yes Yes

1, 2, or 3 No Yes
Not Performed 0 or not present Yes Not critical to decision
1, 2, or 3 No Yes
For VIS and CCD card types, V.I.P. uses VSDC routing and authorization response defaults
to determine the action it should take on behalf of the issuer.
Table 15-4 VSDC Routing and STIP Default Responses
Source: Card Force-Route

Verification to Available STIP
Result (CVR) Issuers Response
or Terminal
Verification
Condition Result (TVR) Default Default
VIS- and CCD-Compliant Card Types
1 Transaction exceeds floor limit TVR No 00
2 Transaction selected randomly for TVR No 00
online processing
3 Cardholder verification failed TVR Yes 05

Table 15-4 VSDC Routing and STIP Default Responses (continued)

or Terminal
Verification
4 Unrecognized cardholder TVR Yes 00
verification method (CVM)
5 Offline PIN verification failed CVR Yes 05
6 PIN entry required and PIN pad TVR Yes 05
not present or not working
7 PIN entry required, PIN pad TVR Yes 05
present, but PIN not entered
8 Offline PIN entry attempt limit CVR or TVR Yes 75/05
75 05
exceeded
V.I.P. converts
code 75 to 05
before it sends
the response to
the acquirer
9 Lower consecutive offline limit TVR Yes 00
exceeded
10 Upper consecutive offline limit TVR Yes 00
exceeded
11 Expired application TVR Yes 05
12 Application not yet effective TVR Yes 05

13 Issuer authentication failed on last CVR Yes 00
transaction
Members
cannot modify
14 Static Data Authentication (SDA) TVR Yes 05
failed
Members
cannot modify
15 Offline data authentication not TVR Yes 05
performed
Members
NOTE: cannot modify
Does not apply to ATM
transactions
16 Script update failed on last CVR Yes 00

transaction
Members
cannot modify
17 Merchant forced transaction TVR Yes 05
online


or Terminal
Verification
18 Magnetic stripe read of chip card Considered Yes 00
at chip terminal for Early and
Full Data Members
participants, cannot modify
activated on
magnetic
stripe fallback
transactions1
19 Last online transaction not CVR Yes 00
completed
20 Card authentication failed and Considered Yes 05
card authentication reliable for card
authentication Members
feature cannot modify
participants
(issuers)
21 Card authentication failed and Considered Yes 052
card authentication unreliable for card
participants

(issuers)
22 Card authentication not performed Considered Yes 05
and card authentication unreliable for card
participants
(issuers)
23 Offline DDA failure TVR Yes 05
Members
cannot modify
VIS Card Type Only
1 Exceeded total, domestic, or CVR Yes 00
international counters
2 SDA failed on last transaction and CVR Yes 00
was declined offline
Members
cannot modify
3 Script update succeeded on last CVR Yes 00
transaction
Members Members
cannot modify cannot modify


or Terminal
Verification
4 New card (first use) CVR Yes 00
5 DDA failed on last transaction and CVR Yes 00
was declined offline
Members
cannot modify
CCD-Compliant Card Type Only
1 Lower offline transaction count CVR Yes 00
limit exceeded
2 Upper offline transaction count CVR Yes 00
limit exceeded
3 Lower cumulative offline amount CVR Yes 00
limit exceeded
4 Upper cumulative offline amount CVR Yes 00
limit exceeded
5 Issuer discretionary bit 1 CVR Yes 00

9 Offline data authentication failed CVR Yes 00
on previous transaction
1. A fallback transaction is one in which a chip-capable terminal uses the Track 2 data from the card's physical magnetic
stripe and not from the chip's image of the magnetic stripe.
2. Issuers can change to approve for online card authentication method (Online CAM) problems; for instance, because of an
incorrectly personalized card. Refer to the VSDC System Technical Manual for further information about this condition.
15.6.4 Online Card and Issuer Authentication

VisaNet supports VSDC processing with two online authentication features: the Card
Authentication feature and the Issuer Authentication feature. In both cases, VisaNet can
perform the service if the issuer chooses the option.
To perform online card authentication method (Online CAM), the card uses a Unique
Derivation Key to generate the cryptogram. The issuer uses a Master Derivation Key and a
Derivation Key Index, the primary account number (PAN), and the PAN sequence number,
to derive the Unique Derivation Key and validate the cryptogram.
The cryptogram version for VIS card types is 10. For CCD-compliant card types, the
A4.
common core indicator (CCI) format code is A4

To perform online issuer authentication, the issuer uses the Unique Derivation Key to
generate a different cryptogram and provides it in the response. The card validates this
cryptogram.
Online card and issuer authentication comprise the following steps:

1. The card generates the authorization request cryptogram (ARQC) using transaction
data and the Unique Derivation Key. The card sends the cryptogram to the terminal.
2. The terminal sends the data, including the cryptogram and related data, to the acquirer.
3. If the acquirer supports the Full Data option, the acquirer formats the transaction for
V.I.P. The acquirer takes the data from the terminal and formats a V.I.P. message,
which it sends to VisaNet.
4. VisaNet receives the request. V.I.P. performs routing and STIP processing according
to issuer-selected parameters.
5. The issuer or V.I.P performs the card authentication process. The issuer or V.I.P. sends
the data to its Host Security Module (HSM), which executes the algorithm to validate the
ARQC. The HSM uses the card's Derivation Key Index to locate the Master Derivation
Key, used to derive the Unique Derivation Key used by the card to generate the
cryptogram. The HSM takes the Master Derivation Key along with the primary account
number and the card sequence number and derives the Unique Derivation Key.
The issuer or V.I.P. uses the Unique Derivation Key to generate a comparison
cryptogram. The cryptogram generated by the HSM is compared to the cryptogram in
the request and a pass or a fail response is returned. A pass means that the card
authentication is successful.
If V.I.P. authenticates the card in the request, it forwards the result in Field 44.8—Card
Authentication Results Code if the issuer has chosen to receive it.
6. The issuer sends the response to VisaNet.

If the issuer uses the Issuer Authentication feature, the issuer generates a cryptogram
called the authorization response cryptogram (ARPC) and includes the cryptogram in
the response to the acquirer. The ARPC is generated using the ARQC, the response
code, and the Unique Derivation Key. The acquirer receives the response message and
sends it to the terminal. The terminal forwards the response with the ARPC to the card.
If V.I.P. performs this service, the issuer returns the response with only the card
authentication result. V.I.P. generates the ARPC and includes it in the response to
the acquirer.
7. The card validates the issuer by generating an ARPC and comparing it to the one
provided by the issuer in the response. A match means the authentication is successful
and the card knows it is communicating with the correct issuer. Issuers can have
V.I.P. perform issuer authentication for every transaction, for only those transactions
processed by STIP, or for no transactions.
15.6.4.1 Offline PIN Entry Attempt Limit Exceeded

In a request, Field 131—Terminal Verification Results and Field 134.3—Card Verification
Results indicate when a PIN is verified offline but the cardholder’s attempts to enter the
PIN exceed the issuer’s specified limit for online PIN-entry attempts. V.I.P. routes the
cardholder’s request to the issuer or to STIP depending on the issuer’s STIP parameters
for online PIN processing. Only Full Data issuers receive fields 131 and 134.3.

15.6.5 dCVV Verification

Verifying a Dynamic Card Verification Value (dCVV) is similar to the other Visa CVV
verification processes. The participating issuer, or V.I.P. on the issuer's behalf, generates a
dCVV from the request message information for comparison with the dCVV in the request.
If V.I.P. validates the dCVV, it uses Field 44.5—CVV/iCVV Results Code to convey the
results to the issuer (fail = 1, pass = 2). Issuers also use field 44.5 to send dCVV result
codes in responses to participating acquirers. If a dCVV fails verification, V.I.P. does not
check the CVV from the physical magnetic stripe; it forwards the transaction to available
issuers or sends it to STIP for issuer-specified processing.
15.6.6 “Fallback” Transactions

A fallback transaction is one in which a chip-capable terminal uses the Track 2 data from
the card's physical magnetic stripe and not from the chip's image of the magnetic stripe.
VSDC-compatible terminals always try to obtain track data from the chip image before
relying on the card's physical magnetic stripe. If for some reason the terminal cannot
read the chip's Track 2-equivalent data, the merchant is allowed to swipe the card for a
physical magnetic stripe-based transaction. Fallback transactions are identified by the
following fields:
• Field 60.2—Terminal Entry Capability contains 5 (chip terminal)
• Field 60.3—Chip Condition Code: This field contains a 1-digit code that provides
information about fallback transactions, which are initiated from the magnetic stripe of
VSDC cards at VSDC terminals. Although a value of 0 in the field indicates that the
transaction is not a fallback transaction, it may be excluded from VSDC transactions
for which the chip is read. This field contains 0 (the transaction contains chip data
from a VSDC card or the transaction was initiated from a magnetic-stripe-only card),
1 (the service code begins with 2 or with 6, the terminal's last chip card read was
successful), or 2 (the service code starts with 2 or with 6, the terminal's last chip card
read was unsuccessful).

• Field 35—Track 2–Equivalent Data or Field 45—Track 1 Data contains the service code
beginning with 2 or with 6.
There may be situations in which both the chip's magnetic stripe data and the card's
physical magnetic stripe data cannot be obtained through the terminal. In this case, a
key-entered fallback transaction is initiated.
15.7 PROCESS FLOWS

This section summarizes VSDC transaction flows for Full Data option participants.
Option—The following steps comprise the processing

Acquirer Full and Issuer Full Data Option—
when both the acquirer and the issuer fully participate in the VSDC Service.
1. The card and terminal perform VSDC processing and, if the terminal sends the
transaction online, the terminal sends the new VSDC data.
2. The acquirer formats the authorization request using the new chip data, including the
ARQC and cryptogram data.
3. V.I.P. validates the message content and structure, either performs requested
processing in STIP or drops the chip data, and routes the transaction to the issuer.
V.I.P. validates the ARQC according to the issuer's selected option and sends the
results to the issuer at the issuer's request.
4. The issuer validates the cryptogram. It approves or declines the transaction and returns
the results in the response message. The response may include the ARPC.

5. V.I.P. forwards the issuer's response to the acquirer. If there is no ARPC in the
response, V.I.P. may generate the ARPC and send it in the response to the acquirer.
6. The acquirer forwards the issuer's response to the merchant.
15.8 MESSAGE FLOWS

Refer to the Visa Smart Debit/Visa Smart Credit System Technical Manual for a complete
set of message flows. Members can contact their Visa representatives to obtain a copy
of the manual.

This section summarizes the key fields that distinguish a VSDC authorization or financial
request. Refer to the Visa Smart Debit/Visa Smart Credit System Technical Manual for a
complete list and for detailed field descriptions.
15.9.1 0100 Authorization and 0200 Financial Requests

In general, the non-VSDC transaction field requirements apply to VSDC transactions.
For instance, if a non-VSDC ATM transaction requires fields 41, 42, and 43, so does a
VSDC ATM transaction.
The following fields or their values are specific to VSDC messages.
Field 22—Point-of-Service Entry Mode Code (BASE I and SMS)

A VSDC authorization or financial request is identified by the value in
Field 22—Point-of-Service Entry Mode Code. Applicable to Full Data participants,
positions 1–2 must contain one of the following codes in authorization and financial
requests, balance inquiries, reversals, and STIP advices.
• 05
05—Integrated circuit card read; CVV or iCVV checking is possible. Code 05
indicates that the account information was obtained from the chip on the card, and

that CVV or iCVV checking is possible.
• 07
07—Proximity payment/contactless-originated using magnetic stripe data rules.
Code 07 indicates that the card data was obtained from a proximity chip on the card
and that the transaction was processed in accordance with magnetic stripe data rules.
• 08
08—Proximity-read-capable; to indicate that the terminal can read a proximity chip
(using a Visa contactless specification) but cannot read a contact chip on a card.
• 91
91—Contactless device-read-originated using magnetic stripe data rules; Online
CAM, dCVV, iCVV, or CVV check is possible.
• 95
95—Integrated circuit card read; CVV or iCVV checking may not be possible. Visa
uses code 95 to indicate that the magnetic stripe data may be unreliable and that
accurate CVV processing may not be possible. V.I.P. may change the field value
to 95 when either the acquirer or the issuer is inactive for CVV or iCVV processing
from the chip.
This field applies to all three card types and both the unexpanded and expanded third
bitmap formats.

Field 23—Card Sequence Number

Field 23 is conditionally present in a request and is used only when two or more cards
have the same cardholder account number. Issuers place a sequence number in each
card's chip during personalization. If the number is present on the card it is required
in requests and is used as a data element for calculating the Unique Derivation Key
(UDK). If it is not present, the acquirer either excludes this field or fills it with zeros.
This field applies to all three card types and both the unexpanded and expanded third
bitmap formats.
Field 35—Track 2 Data or Field 45—Track 1 Data

The Track 2-equivalent data in the chip's magnetic stripe image (MSI) is required for
contactless transactions using the VIS and CCD card types. The Track 2 data includes
issuer discretionary data (IDD); the IDD contains a unique 3-digit dCVV, a 4-digit
application transaction counter (ATC), and, in the U.S. region only, a unique one-digit
contactless indicator. The ATC records the number of transactions to date, and the
unique contactless Indicator value signals the end of the IDD and indicates whether the
zero) or is contactless (value is not zero
transaction is contact (value is zero zero).
Chip card service codes must begin with 2 or with 6.
For contactless VSDC transactions, the value in Field 22—POS Entry Mode Code
07.
must be 05 or 07
For contact or contactless transactions, either Track 1 (field 45) or Track 2 (field 35)
may be used.
Field 44.5—CVV/iCVV Results Code

If V.I.P. validates the CVV, the iCVV, or the dCVV on the issuer's behalf, issuers that
have successfully completed CVV/iCVV testing can choose to receive the results in this
field rather than in field 39 in authorization or full financial requests if they have selected
the Full Data option. Valid values are:
• 1—The CVV, iCVV, or dCVV failed verification.
• 2—The CVV, iCVV, or dCVV passed verification.
• 3—The CVV passed verification. (This value is used for emergency replacement
cards issued through Global Customer Care Services.)
• (blank
blank)
blank or not present—V.I.P. did not verify the CVV, iCVV, or dCVV.

Field 44.8—Card Authentication Results Code

If V.I.P. performs card authentication on the issuer's behalf, issuers can choose to
receive the results in this field in authorization and full financial requests if they have
successfully completed CVV/iCVV testing and have selected the Full Data option. Valid
codes are:
• 1—V.I.P. checked the ARQC but it failed verification.
• 2—V.I.P. checked the ARQC and it passed verification.
• (blank
blank)
blank or not present—V.I.P. did not perform card authentication or some other
situation prevented verification; for instance, the issuer is not a service participant or
a system or cryptographic error occurred.
Issuers use this subfield in 0110 and 0210 authorization responses to indicate to V.I.P.
the card authentication results when the issuer performs its own card authentication.
V.I.P. passes this subfield to acquirers that have successfully completed testing to
receive it.

Field 39 is present in 0110 and 0210 responses and in 0120 and 0220 advices, in 0220
acquirer- and BASE II-deferred clearing advices, and in 0620 chip-based informational
advices.
BASE I—I—For issuers that have V.I.P. perform card authentication, BASE I uses
response code Q1 to convey card authentication failures to issuers, unless STIP
overrides it with a higher priority code.
SMS—Listed below are the field 39 response codes used for offline approvals and
SMS—
declines.
• Y1
Y1—Offline approved

• Z1
Z1—Offline declined
• Y3
Y3—Unable to go online, offline approved
• Z3
Z3—Unable to go online, offline declined

Field 55, Usage 1—VSDC Chip Data

Field 55, usage 1, is used for transmitting VIS, CCD, or Generic EMV chip data
in tag-length-value (TLV) format instead of using the third bitmap fields 130–149.
The field 60.6 chip transaction indicator indicates which location is being used.
V.I.P. transfers the chip data between the two locations as necessary to accommodate
recipients. The field can be used in Visa POS transactions and in Visa and Plus ATM
transactions. It is only available to members that have successfully completed testing
for Full Data participation.
The table below shows the TLV layout. “Third Bitmap” in this chapter lists the individual
TLV data elements.
Length Dataset ID Dataset Length TLV Data Elements

A one-byte A one-byte A two-byte binary The actual data elements. Each one
binary binary identi�er sub�eld that comprises:
sub�eld that given to each contains the total
contains the dataset. The length of the Tag identifier
number of identi�er is 01 subsequent chip
bytes in this (hexadecimal). datasets. Data element length
�eld after
Data element value or content
this length
sub�eld.
Byte 1 Byte 2 Bytes 3–4 Bytes 5–256
Generic EMV Transport issuers must use a dedicated BIN exclusively for this card
type and the BIN must support field 55.
Supplemental data: in addition to carrying chip data, field 55 is also available for
transmitting TLV-formatted supplemental data such as market-specific data, whether or
not chip data is also contained in field 55 or if it is in fields 130–149. Host testing for
this field 55 supplemental data capability is required even if the member is using the
third bitmap for chip data. Refer to “Field 55 Supplemental Data” in this chapter for
more information.
Field 60.2—Teminal Entry Capability

This field is required and the value must be 5 to indicate that the transaction occurred
at a chip-capable terminal. The field requirement applies to Full Data participants.
For contactless transactions, acquirers must use the terminal entry capability code 8
(contactless-read capability). Acquirers in all other regions do not have to use code 8.
NOTE
If field 22 contains 05 or 95 in the request, V.I.P. neither adds field 60.2 (if not present), nor converts
any value in field 60.2 to 5.

Field 60.3—Chip Condition Code

This field contains a 1-digit code that provides information about fallback transactions,
which are initiated from the magnetic stripe of VSDC cards at VSDC terminals. Although
a value of 0 in the field indicates that the transaction is not a fallback transaction, it may
be excluded from VSDC transactions for which the chip is read.
The field is conditional and is used only for fallback transactions from Full Data
acquirers; otherwise, the field is not present or if present, contains a zero if further
subfields are present. A fallback transaction is one in which a chip-capable terminal
uses the Track 2 data from the card's physical magnetic stripe and not from the chip's
image of the magnetic stripe. The valid values are:
• 0—The transaction contains chip data from a VSDC card or the transaction was
initiated from a magnetic-stripe-only card.
• 1—The transaction was initiated at a chip-capable terminal from a magnetic stripe
with a service code beginning with 2 or with 6, and the terminal's last attempt to read
a chip card was successful (or was not a chip transaction).
• 2—The transaction was initiated at a chip-capable terminal from a magnetic stripe
with a service code beginning with 2 or with 6 and the terminal's last attempt to read
a chip card was unsuccessful.
Field 60.6—Chip Transaction Indicator

This field is required and indicates whether the transaction's chip data is in field 55
or in the third bitmap fields (fields 130–149), or if the expanded third bitmap format
is being used.
• 0—The chip data is not present.
• 1—The chip data is present in field 55 or in the unexpanded third bitmap
fields 130–149.

• 2—The chip data is present in the expanded third bitmap format.
• 3—The Full data acquirer submitted CCD or Generic EMV Transport data in the
standard third bitmap format.
If acquirers do not include this field in chip requests, V.I.P. removes the chip data and
processes the request as a magnetic stripe transaction, which precludes chip-associated
risk protections.
NOTE
The transaction indicator is used by V.I.P., not by issuers. V.I.P. always changes the value 2 to 1 before
forwarding the message to the issuer.

60.7—Chip
Field 60.7— Chip Card Authentication Reliability Indicator
This field is conditional and is used only to indicate unreliable card authentication;
otherwise, the field is not present or contains a zero if further subfields are present.
• 0—No detected card authentication reliability issues; value used as filler.
• 1—Acquirers set this value to indicate that card authentication may be unreliable.
• 2—V.I.P. determined the acquirer is inactive for card authentication; for instance,
when it is experiencing frequent authentication failures.
• 3—V.I.P. determined the issuer is inactive for card authentication; for instance, when
it is experiencing frequent authentication failures.
NOTE
Acquirers should populate this field with the value 1 only if they are having cryptogram data element
problems.
15.9.2 Third Bitmap Fields

Table 15-5 summarizes the third bitmap fields used in VSDC processing. The third bitmap
is used by Full Data participants only. Refer to the V.I.P. System BASE I and SMS
technical specifications manuals for complete field and message requirement information.
Unless otherwise indicated, the field information below applies both to BASE I and SMS.
Refer also to Appendix B of the Visa Smart Debit/Visa Smart Credit System Technical
Manual for complete specifications.
Table 15-5 Third Bitmap Fields
Field and Tag Length Description Source

Field 130, Terminal 3 bytes This field indicates the card data input, the cardholder Terminal
Capability Profile—BASE I verification method (CVM), and the security capabilities
and SMS supported by the terminal.
Tag 9F33
Field 131, Terminal 5 bytes This field contains terminal-recorded offline processing Terminal
Verification Results—BASE I indicators.
and SMS
Tag 95
Field 132, Unpredictable 4 bytes This field contains the variable number used in the Terminal
Number—BASE I and SMS generation of the VSDC cryptogram.
Tag 9F37

Table 15-5 Third Bitmap Fields (continued)

Field 134—Visa 33 bytes Usage 1: expanded third bitmap format Chip card
Discretionary Data maximum
In the expanded format, field 134 contains both the Visa
Tag 9F10 discretionary data and the issuer discretionary data,
which together are referred to as the issuer application
data. Length varies by card type. In addition to the data
length value, discretionary data comprises the following:
• One-byte Derivation Key Index, which is an index of the
issuer's list of keys for use in online card authentication
method (Online CAM), issuer authentication, and
validation of the clearing cryptogram.
• One-byte cryptogram version number, which indicates
which version of the cryptogram algorithm was used
to generate the ARQC, the transaction certificate
(TC), the ARPC, or the application authentication
cryptogram (AAC).
• Four–byte card verification results (CVR), which
contains a series of card-recorded offline processing
indicators.
Usage 2: unexpanded third bitmap format
This field contains the Visa discretionary part of the

issuer application data. It contains these subfields:
• Field 134.1—Derivation Key Index.
• Field 134.2—Cryptogram Version Number.
• Field 134.3—Card Verification Results (CVR).
Field 135—Issuer 33 bytes This field contains optional issuer-defined data in the Chip card

Discretionary Data maximum unexpanded third bitmap format. If present on the card,
it is part of Tag 9F10, issuer application data.
Tag 9F10
Field 136—Cryptogram 8 bytes This field contains an authorization request cryptogram Chip card
(ARQC), a transaction certificate (TC), or an application
Tag 9F26 authentication cryptogram (AAC).
This field is required in 0422 chargebacks and

chargeback reversals, 0220 representments, and 0620
chip-based information advices, if present in the 0200
original message.
Field 137—Application 2 bytes This field contains a count of the transactions performed Chip card
Transaction Counter with the card application. It is incremented by one each
time a transaction is initiated.
Tag 9F36
This field is required in 0422 chargebacks and
chargeback reversals, 0220 representments, and 0620
chip-based information advices, if present in the 0200
original message.
Field 138—Application 2 bytes This field reflects the specific functions that the chip card Chip card
Interchange Profile application supports.
Tag 82


Field 139—Authorization 10 bytes total This field applies to the unexpanded third bitmap format Issuer or
Response Cryptogram and only. V.I.P.
ARPC Response Code
V.I.P. or the issuer sets the value in this field when
Tag 91 issuer authentication is performed. It has two subfields:
• Field 139.1—Authorization Response Cryptogram
(ARPC), used to authenticate the issuer host system.
• Field 139.2—ARPC Response Code, which contains
the response value used by the issuer to calculate
the ARPC.
Field 140—Issuer 17 bytes This field applies only to the expanded third bitmap Issuer or
Authentication Data maximum format. V.I.P.
Tag 91 V.I.P. or the issuer creates this field when it performs

issuer authentication. Content varies by card type. The
field contains the ARPC and the ARPC response code.
For CCD card types, it also includes 4-byte card status
updates.
Field 142—Issuer Script Variable This field contains proprietary information that the issuer Issuer
wants to communicate to the card. It allows issuers
Tag 71 or Tag 72 to make dynamic changes to the content of the card
without reissuing the card.
The issuer sends Tag 71 or Tag 72 but not both.
Tag 71 is used when issuer script commands are to

be applied to the card before the final GENERATE AC
command.
Tag 72 is used when issuer script commands are to

be applied to the card after the final GENERATE AC
command. Visa recommends the use of Tag 72.
Field 143—Issuer Script 21 bytes The card records the success or the failure of the script Terminal
Results updates sent in an earlier leg of the transaction.
Tag 9F5B
Field 144—Cryptogram 1 byte This field indicates the type of financial transaction Terminal
Transaction Type specified by the first two digits of Field 3—Processing
Code.
Tag 9C
Field 145—Terminal Country 2 bytes This field identifies the country in which the merchant Terminal
Code terminal is located.
Tag 9F1A
Field 146—Terminal 3 bytes This field contains the local date (in YYMMDD format) Terminal
Transaction Date on which the transaction was authorized.
Tag 9A


Field 147—Cryptogram 6 bytes This field contains the transaction amount. Terminal
Amount
Tag 9F02
Field 148—Cryptogram 2 bytes This field contains the currency code associated with the Terminal
Currency Code transaction amount.
Tag 5F2A
Field 149—Cryptogram 6 bytes This field contains the cashback amount. Terminal
Cashback Amount
This field, and Tag 9F03 are valid only for POS
Tag 9F03 transactions.
Field 55—Integrated Circuit 4 bytes This field contains all the chip data, including Terminal
Card (ICC)-Related Data supplemental data.
Tag 9F6E

For more information about the VSDC Service, refer to the following documents:
• JCB, MasterCard, Visa (EMV) Specifications, EMV '96 Version 3.1.1 and EMV 2000
Version 4.0—These documents contain industry standards for chip card and terminal
interaction. They are available at www.emvco.com.
• Visa Integrated Circuit Specifications (VIS)—This manual contains chip card and terminal
specifications for VSDC. It is available at www.visasmartpartners.com.
• Visa Smart Debit and Visa Smart Credit Planning Guide—This guide outlines the
marketing, planning, and implementation activities necessary to launch a VSDC program.

• Visa Smart Debit and Visa Smart Credit Service Description—This manual provides a
high-level description of the features and the benefits of a VSDC program.
• Visa Smart Debit and Credit Member Implementation Guide for Issuers—This manual
provides guidelines for issuers involved in the implementation of new VSDC programs.
• Visa Smart Debit and Credit Member Implementation Guide for Acquirers—This manual
provides guidelines for acquirers involved in the implementation of new VSDC programs.
• Visa Smart Debit/Visa Smart Credit System Technical Manual—This manual provides
information for members and for Visa staff responsible for the implementation and the
operation of a VSDC program.


X Index
A process flow (acquirer) 11-6

advice recovery 2-22 process flow (issuer) 11-7
Alternate Routing option regions 11-6
process flow 4-8 related messages 11-4
ATM Account-Type Split Routing Option service monitoring 11-4
process flow 4-6 testing 11-4
Index
ATM/POS Split Routing Option transaction codes used, BASE II 11-5
process flow 4-5 Card Verification Value (CVV)
ATM/POS Split Routing Service in STIP 2-23
Alternate Routing option 4-4 Cardholder Database
ATM/POS Account-Type Split Routing Advice File
option 4-4 description 11-3
ATM/POS Split Routing option 4-4 Exception File
eligibility 4-3 description 11-3
fields 4-11 update deadlines 11-6
message flow 4-9 Check Acceptance Service
participation requirements 4-5 eligibility 5-3
authentication technology 13-3 fields 5-7, 5-9
authorization messages
services message flow 5-6
Positive Authorization Capacity participation requirements 5-4
Management (PACM) Service 2-21 process flow 5-5
Positive Cardholder Authorization Service related messages 5-4
(PCAS) 2-21 vendors 5-4
chip card services
Visa Smart Debit/Smart Credit (VSDC)
B
Service 15-3, 15-37
BASE I System
clearing
description of 2-6
definition of 2-8
message types 2-13
CMI, See Common Member Interface (CMI)
overview 2-6
Common Member Interface (CMI)
stand-in processing (STIP) 2-22 to 2-23
overview 2-10
BASE II System 2-7
processes 2-10
fraud reporting 12-3
CRB Service, See Card Recovery Bulletin (CRB)
transaction codes used for Card Recovery
Service
Bulletins (CRBs) 11-5
CVV, See Card Verification Value (CVV)
C D
diversion threshold 2-21
eligibility 11-3
fields 11-9
messages
E
message flow 11-8 EBT, See Electronic Benefits Transfer (EBT)
participation requirements 11-4
1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 IX-1

X Index
Electronic Benefits Transfer (EBT) process flow 6-8

participation requirements 7-19 service monitoring 6-5
processing rules 7-20 testing 6-5
related messages 7-19 gateways
enrolling in a service 1-5 Gateway Services 6-6
Exception File
description 11-3 I
update deadlines 11-6
implementation of a service 1-5
F K
Index
fields
key fields
ATM/POS Split Routing Service 4-11
PIN Debit Gateway Service (PDGS) 7-18
Card Recovery Bulletin (CRB) Service 11-9
, See fields
Check Acceptance Service 5-7, 5-9
Fraud Reporting System (FRS) 12-11, 12-15
PIN/No-PIN Split Routing Service 8-7
M
Priority Routing Service 9-9 message
Visa Smart Debit/Smart Credit (VSDC) formats 2-12
Service 15-29, 15-31 types 1-4, 2-13
files message flow
Advice File ATM/POS Split Routing Service 4-9
description 11-3 Card Recovery Bulletin (CRB) Service 11-8
Exception File Check Acceptance Service 5-6
description 11-3 example 2-18
update deadlines 11-6 Fraud Reporting System (FRS) 12-11
Visa Fraud Master File 12-7, 12-13 PIN Debit Gateway Service (PDGS) 7-13
Fraud Reporting System (FRS) Priority Routing Service 9-8
BASE II reports 12-3
decision tree 12-9 P
eligibility 12-3 parameters
fields 12-11, 12-15 stand-in processing (STIP) 2-22
messages V.I.P. 2-11
message flow 12-11 participation requirements
modifying reported transactions 12-8 ATM/POS Split Routing Service 4-5
participation requirements 12-4 Card Recovery Bulletin (CRB) Service 11-4
process flow 12-7, 12-9 Check Acceptance Service 5-4
rejected transactions 12-6 Electronic Benefits Transfer (EBT) 7-19
related messages 12-5 Fraud Reporting System (FRS) 12-4
reporting timeframes 12-6 Gateway Services 6-5
Visa Fraud Master File 12-7, 12-13 PIN Debit Gateway Service (PDGS) 7-4
FRS, See Fraud Reporting System (FRS) PIN/No-PIN Split Routing Service 8-4
Priority Routing Service 9-5
G Visa Shortest Online Path (VSOP)
Gateway Services Service 10-4
available gateways 6-6 Visa Smart Debit/Smart Credit (VSDC)
eligibility 6-3 Service 15-5
participation requirements 6-5 payment authentication 13-3
IX-2 Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X Index
PCAS, See Positive Cardholder Authorization parameters

Service (PCAS) stand-in processing (STIP) 2-22
PIN Debit Gateway Service (PDGS) V.I.P. 2-11
Electronic Benefits Transfer (EBT) services 1-3
description 3-4, 7-19 Single Message System (SMS) 2-6
eligibility 7-3 VisaNet Settlement Service (VSS) 2-8
key fields 7-18
messages R
message flow 7-13
regions
Index
process flow 7-7
rejected transactions
processing rules 7-9
Fraud Reporting System (FRS) 12-6
related messages 7-4
related messages
routing options 7-4
reports, fraud, See Fraud Reporting System
eligibility 8-3
(FRS)
fields 8-7
risk management services
Card Recovery Bulletin (CRB) Service 11-3,
PIN Routing option 8-4
11-11
PIN/No-PIN Split Routing option 8-3
process flow 8-5
routing
alternatives 2-21
eligibility 9-3
definition of 2-19
fields 9-9
enhanced routing 3-3
messages
information
message flow 9-8
stand-in processing (STIP) 2-22
related messages 9-5
system tables 2-19
internal services 2-21
process flow 9-5
tables 2-20
process flow
routing services
Alternate Routing option 4-8
ATM/POS Split Routing Service 3-4, 4-12
ATM Account-Type Split Routing Option 4-6
Check Acceptance Service 3-4, 5-3, 5-9
ATM/POS Split Routing Option 4-5
Gateway Services 3-4, 6-9
overview 3-3
acquirer 11-6
PIN Debit Gateway Service (PDGS) 3-4, 7-3,
issuer 11-7
7-22
Check Acceptance Service 5-5
PIN/No-PIN Split Routing Service 3-4, 8-3,
8-7
Gateway Services 6-8
Priority Routing Service 3-5, 9-3, 9-9
PIN Debit Gateway Service (PDGS) 7-7
Visa Shortest Online Path (VSOP)
PIN/No-PIN Split Routing Service 8-5
Service 3-5, 10-3, 10-6
Priority Routing Service 9-5
VisaNet 2-5
processing
S
BASE I 2-6 service monitoring
BASE II 2-7 ATM/POS Split Routing Service 4-5
Common Member Interface (CMI) 2-10 Card Recovery Bulletin (CRB) Service 11-4
networks 2-3 Check Acceptance Service 5-4

X Index
description of 1-6 Visa Secure Electronic Commerce (VSEC) With

Fraud Reporting System (FRS) 12-4 Verified by Visa (3-D Secure) 13-5
Gateway Services 6-5 Visa Secure Electronic Commerce (VSEC) With
PIN Debit Gateway Service (PDGS) 7-4 Verified by Visa (3-D Secure)
PIN/No-PIN Split Routing Service 8-4 eligibility 13-3
Priority Routing Service 9-5 Visa Shortest Online Path (VSOP) Service
Visa Shortest Online Path (VSOP) eligibility 10-3
Service 10-4 messages
Visa Smart Debit/Smart Credit (VSDC) related messages 10-5
Service 15-12 participation requirements 10-4
Index
services Visa Smart Debit/Smart Credit (VSDC) Service

implementation (general) 1-5 eligibility 15-4
signing up (and enrolling) 1-5 fields 15-29, 15-31
testing participation requirements 15-5
definition of 1-6 related messages 15-20
testing (definition) 1-5 VisaNet
settlement Access Point (VAP) 2-3
definition of 2-8 BASE II System 2-7
Single Message System (SMS) definition of 2-3
description of 2-6 process flow 2-5
message types 2-13 systems 2-5
overview 2-6 V.I.P. processing parameters 2-11
stand-in processing (STIP) 2-23 VisaNet Access Point (VAP) 2-3
SMS, See Single Message System (SMS) VisaNet Integrated Payment (V.I.P.) System
stand-in processing (STIP) Common Member Interface (CMI)
through V.I.P. illustration of 2-10
BASE I 2-22 to 2-23 components
parameters 2-22 BASE I System 2-6
Single Message System (SMS) 2-23 Common Member Interface (CMI) 2-10
STIP, See stand-in processing (STIP) Single Message System (SMS) 2-6
system parameters, See processing, parameters implementation (general) 1-5
system tables message types 2-13
routing 2-19 monitoring
definition of 1-6
T processing
parameters 2-11
testing 1-5
testing
definition of 1-6
definition of 1-6
testing (definition) 1-5
Gateway Services 6-5
VisaNet Settlement Service (VSS) 2-8
VisaNet Settlement Service (VSS)
V definition 2-8
V.I.P., See VisaNet Integrated Payment (V.I.P.) illustration of 2-9
System VSDC, See Visa Smart Debit/Smart Credit
VAP, See VisaNet Access Point (VAP) (VSDC) Service
Verified by Visa 13-3 VSEC, See Visa Secure Electronic Commerce
Visa Fraud Master File 12-7, 12-13 (VSEC)
Visa Message Gateway 2-4
IX-4 Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

X Index
VSOP, See Visa Shortest Online Path (VSOP)

Service
VSOP Service, See Visa Shortest Online Path
(VSOP) Service
VSS, See VisaNet Settlement Service (VSS)
Index

02 v.I.P. System Services Volume 1 0853A

Uploaded by

Copyright:

Available Formats

You might also like

02 v.I.P. System Services Volume 1 0853A

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02 v.I.P. System Services Volume 1 0853A

Uploaded by

Copyright:

Available Formats

V.I.P.

System Services, Volume 1

© 1999 - 2013 Visa. All Rights Reserved. 0853A–22

Visa and other trademarks are trademarks or registered trademarks of Visa.

THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR

Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

PART 1 V.I.P. BASICS

CHAPTER 1 INTRODUCTION TO SYSTEM SERVICES

CHAPTER 2 SYSTEM FUNDAMENTALS

1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 i

2.8 Basics.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-

2.11 Account-Level Programs and Cardholder Rewards

PART 2 ROUTING SERVICES

CHAPTER 3 INTRODUCTION TO ROUTING SERVICES

CHAPTER 4 ATM/POS SPLIT ROUTING SERVICE

ii Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

4.8 Glossary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-

CHAPTER 5 CHECK ACCEPTANCE SERVICE

CHAPTER 6 GATEWAY SERVICES

CHAPTER 7 PIN DEBIT GATEWAY SERVICE (PDGS)

1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 iii

7.4.1 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4

7.7 Process Flows

CHAPTER 8 PIN/NO-PIN SPLIT ROUTING SERVICE

CHAPTER 9 PRIORITY ROUTING SERVICE

iv Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

9.4.3 Planning and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5

PART 3 RISK MANAGEMENT SERVICES

CHAPTER 11 CARD RECOVERY BULLETIN (CRB) SERVICE

1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 v

CHAPTER 12 FRAUD REPORTING SYSTEM (FRS)

12.6 How Fraud Reporting System (FRS) Works

PART 4 VISA SECURE ELECTRONIC COMMERCE (VSEC) SERVICES

CHAPTER 13 VISA SECURE ELECTRONIC COMMERCE (VSEC) WITH VERIFIED BY VISA

PART 5 CHIP CARD SERVICES

CHAPTER 14 VISA CONTACTLESS PAYMENT SERVICE

CHAPTER 15 VISA SMART DEBIT/SMART CREDIT (VSDC) SERVICE

vi Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

15.4.3.1 Visa Test System (VTS /3). . . . . . . . . . . . . . . . . . . . . . .15-7

1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 vii

viii Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

1 Sample Message Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 ix

x Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 xi

xii Visa Confidential V.I.P. System Services, Volume 1 1 June 2013

V.I.P. System Services, Volume 1 and Volume 2, provides updated, comprehensive

About This Manual

STRUCTURE OF THIS MANUAL

2)—Part 1 provides an overview of V.I.P. services

10)—Part 2 describes routing messages

12)—Part 3 contains descriptions

15)—Part 5 contains descriptions of the

1 June 2013 Visa Confidential V.I.P. System Services, Volume 1 1

Part 6: Authorization Database Files and Services (Chapters 16 through 18)—

39)—Part 7 contains descriptions

Table 1 identifies the document conventions used in this manual.

Table 1 Document Conventions