IDTECH Vivopay Neo 2 User manual

Apple iOS SDK Guide
for NEO2
#80152802-001
Rev. A

ii
Revision History
Revision Description and Reason for Change Date
A Initial Release - Manual;User;NEO2;SDK;iOS 1/29/2018
#80152504-001 IDTech iOS SDK Guide for NEO2

CONTENTS iii
Contents
1 IDTech iOS SDK Reference Guide for NEO2 1
2 Connecting to NEO2 BLE Version 2
3 Important Security Notice 3
3.1 Applicability .............................................. 3
3.2 What Does PA-DSS Mean to You? .................................. 3
3.3 Third Party Applications ........................................ 4
3.4 PA-DSS Guidelines .......................................... 4
3.5 More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 NEO2 Main Transaction Commands 11
4.1 EMV Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 MSR/CTLS MSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Sending Direct Commands 14
6 Core Implementation NEO2: Objective-C 15
6.1 Integrating with IDTech framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2 Import the necessary framework/libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3 Add Import statements to utilize frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4 Amend the view controller interface to include the framework delegate classes: . . . . . . . . . . . 21
6.5 Implement any/all of the optional delegate protocols used to receive data from IDT_NEO2_ -
Delegate: ............................................... 21
6.6 Call the Singleton instance of the IDT_NEO2 framework object: . . . . . . . . . . . . . . . . . . . 22
6.7 Sample Project Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.7.1 Step 1: Create New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.7.2 Step 2: Import Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.7.3 Step 3: Design Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.7.4 Step 4: Configure Header File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.7.5 Step 5: Configure Method File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7 Core Implementation NEO2: Swift 33
7.1 Integrating with IDTech framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
IDTech iOS SDK Guide for NEO2 #80152802-001

iv CONTENTS
7.2 Import the Necessary Framework/Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.3 Create a Bridging Header File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.4 Add Import Statement to the Bridging Header File . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.5 Amend the View Controller Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.6 Implement Optional Delegate Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.7 Allocate/Initialize IDT_NEO2 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.8 Sample Project Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.8.1 Step 1: Create New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.8.2 Step 2: Import Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.8.3 Step 3: Design Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.8.4 Step 4: Configure the Bridging Header and View Controller Files . . . . . . . . . . . . . . 48
7.8.5 Step 5: Finalize the View Controller File . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8 NEO2 Error Code Reference 57
9 Enumeration Reference 59
10 EMV Tag Reference 63
11 Hierarchical Index 76
11.1 Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
12 Class Index 77
12.1 Class List ............................................... 77
13 Class Documentation 78
13.1 AIDEntry Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
13.1.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
13.2 APDUResponse Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
13.2.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.2.2 Method Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.2.2.1 clear() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.2.2.2 sharedController() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.3 ApplicationID Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.3.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.4 CAKey Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.4.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.5 CRLEntry Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.5.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
13.6 ICCReaderStatus Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
13.6.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
13.7 IDT_NEO2 Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
#80152504-001 IDTech iOS SDK Guide for NEO2

CONTENTS v
13.7.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.7.2 Method Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.7.2.1 close() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.7.2.2 config_getSerialNumber:(NSString ∗∗response) . . . . . . . . . . . . . . . . . 85
13.7.2.3 config_setBluetoothParameters:oldPW:newPW:(NSString ∗name,[oldPW] NS -
String ∗oldPW,[newPW] NSString ∗newPW) . . . . . . . . . . . . . . . . . . . 85
13.7.2.4 ctls_cancelTransaction() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.7.2.5 ctls_getConfigurationGroup:response:(int group,[response] NSDictionary
∗∗response) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.7.2.6 ctls_removeAllCAPK() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
13.7.2.7 ctls_removeApplicationData:(NSString ∗AID) . . . . . . . . . . . . . . . . . . . 86
13.7.2.8 ctls_removeCAPK:(NSData ∗capk) . . . . . . . . . . . . . . . . . . . . . . . . 86
13.7.2.9 ctls_removeConfigurationGroup:(int group) . . . . . . . . . . . . . . . . . . . . 87
13.7.2.10 ctls_retrieveAIDList:(NSArray ∗∗response) . . . . . . . . . . . . . . . . . . . . 87
13.7.2.11 ctls_retrieveApplicationData:response:(NSString ∗AID,[response] NSDictionary
∗∗response) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.7.2.12 ctls_retrieveCAPK:key:(NSData ∗capk,[key] NSData ∗∗key) . . . . . . . . . . . 87
13.7.2.13 ctls_retrieveCAPKList:(NSArray ∗∗keys) . . . . . . . . . . . . . . . . . . . . . 88
13.7.2.14 ctls_retrieveTerminalData:(NSData ∗∗tlv) . . . . . . . . . . . . . . . . . . . . . 88
13.7.2.15 ctls_setApplicationData:(NSData ∗tlv) . . . . . . . . . . . . . . . . . . . . . . . 89
13.7.2.16 ctls_setCAPK:(NSData ∗key) . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
13.7.2.17 ctls_setConfigurationGroup:(NSData ∗tlv) . . . . . . . . . . . . . . . . . . . . . 89
13.7.2.18 ctls_setTerminalData:(NSData ∗tlv) . . . . . . . . . . . . . . . . . . . . . . . . 90
13.7.2.19 ctls_startTransaction:type:timeout:tags:(double amount,[type] int type,[timeout] int
timeout,[tags] NSMutableDictionary ∗tags) . . . . . . . . . . . . . . . . . . . . 90
13.7.2.20 ctls_startTransaction:type:timeout:transTags:VAS:(double amount,[type] int
type,[timeout] int timeout,[transTags] NSData ∗transTags,[VAS] NSData ∗V-
AS) ......................................... 91
13.7.2.21 device_cancelTransaction() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
13.7.2.22 device_connectedBLEDevice() . . . . . . . . . . . . . . . . . . . . . . . . . . 93
13.7.2.23 device_disableBLEDeviceSearch() . . . . . . . . . . . . . . . . . . . . . . . . 93
13.7.2.24 device_disconnectBLE() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
13.7.2.25 device_enableBLEDeviceSearch:(NSUUID ∗identifier) . . . . . . . . . . . . . . 94
13.7.2.26 device_getAutoPollTransactionResults:(IDTEMVData ∗∗result) . . . . . . . . . . 94
13.7.2.27 device_getBLEFriendlyName() . . . . . . . . . . . . . . . . . . . . . . . . . . 94
13.7.2.28 device_getFirmwareVersion:(NSString ∗∗response) . . . . . . . . . . . . . . . 95
13.7.2.29 device_getMerchantRecord:record:(int index,[record] NSData ∗record) . . . . . 95
13.7.2.30 device_getResponseCodeString:(int errorCode) . . . . . . . . . . . . . . . . . 95
13.7.2.31 device_isConnected:(IDT_DEVICE_Types device) . . . . . . . . . . . . . . . . 96
13.7.2.32 device_sendIDGCommand:subCommand:data:response:(unsigned char command,[sub -
Command] unsigned char subCommand,[data] NSData ∗data,[response] NSData
∗∗response) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
IDTech iOS SDK Guide for NEO2 #80152802-001

vi CONTENTS
13.7.2.33 device_setBLEFriendlyName:(NSString ∗friendlyName) . . . . . . . . . . . . . 96
13.7.2.34 device_setBurstMode:(int mode) . . . . . . . . . . . . . . . . . . . . . . . . . 96
13.7.2.35 device_setMerchantRecord:enabled:merchantID:merchantURL:(int index,[enabled]
bool enabled,[merchantID] NSString ∗merchantID,[merchantURL] NSString
∗merchantURL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
13.7.2.36 device_setPassThrough:(BOOL enablePassThrough) . . . . . . . . . . . . . . 97
13.7.2.37 device_setPollMode:(int mode) . . . . . . . . . . . . . . . . . . . . . . . . . . 97
13.7.2.38 device_startTransaction:type:timeout:tags:(double amount,[type] int type,[timeout]
int timeout,[tags] NSMutableDictionary ∗tags) . . . . . . . . . . . . . . . . . . . 98
13.7.2.39 emv_authenticateTransaction:(NSData ∗tags) . . . . . . . . . . . . . . . . . . . 98
13.7.2.40 emv_callbackResponseLCD:selection:(int mode,[selection] unsigned char selec-
tion) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
13.7.2.41 emv_callbackResponsePIN:KSN:PIN:(EMV_PIN_MODE_Types mode,[KSN] N -
SData ∗KSN,[PIN] NSData ∗PIN) . . . . . . . . . . . . . . . . . . . . . . . . . 100
13.7.2.42 emv_cancelTransaction() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
13.7.2.43 emv_completeOnlineEMVTransaction:hostResponseTags:(BOOL isSuccess,[host -
ResponseTags] NSData ∗tags) . . . . . . . . . . . . . . . . . . . . . . . . . . 100
13.7.2.44 emv_disableAutoAuthenticateTransaction:(BOOL disable) . . . . . . . . . . . . 101
13.7.2.45 emv_getEMVL2Version:(NSString ∗∗response) . . . . . . . . . . . . . . . . . . 101
13.7.2.46 emv_getTerminalMajorConfiguration:(NSUInteger ∗∗configuration) . . . . . . . . 102
13.7.2.47 emv_removeApplicationData:(NSString ∗AID) . . . . . . . . . . . . . . . . . . 102
13.7.2.48 emv_removeCAPK:index:(NSString ∗rid,[index] NSString ∗index) . . . . . . . . 103
13.7.2.49 emv_removeCRLList() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
13.7.2.50 emv_removeTerminalData() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
13.7.2.51 emv_retrieveAIDList:(NSArray ∗∗response) . . . . . . . . . . . . . . . . . . . . 104
13.7.2.52 emv_retrieveApplicationData:response:(NSString ∗AID,[response] NSDictionary
∗∗responseAID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
13.7.2.53 emv_retrieveCAPKFile:index:response:(NSString ∗rid,[index] NSString ∗index,[response]
NSData ∗∗response) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
13.7.2.54 emv_retrieveCAPKList:(NSArray ∗∗response) . . . . . . . . . . . . . . . . . . 106
13.7.2.55 emv_retrieveCRLList:(NSMutableArray ∗∗response) . . . . . . . . . . . . . . . 106
13.7.2.56 emv_retrieveTerminalData:(NSDictionary ∗∗responseData) . . . . . . . . . . . 107
13.7.2.57 emv_retrieveTransactionResult:retrievedTags:(NSData ∗tags,[retrievedTags] N -
SDictionary ∗∗retrievedTags) . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
13.7.2.58 emv_setApplicationData:configData:(NSString ∗aidName,[configData] NS -
Dictionary ∗data) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
13.7.2.59 emv_setCAPKFile:(NSData ∗file) . . . . . . . . . . . . . . . . . . . . . . . . . 109
13.7.2.60 emv_setCRLEntries:(NSData ∗data) . . . . . . . . . . . . . . . . . . . . . . . 109
13.7.2.61 emv_setTerminalData:(NSDictionary ∗data) . . . . . . . . . . . . . . . . . . . . 110
13.7.2.62 emv_setTerminalMajorConfiguration:(int configuration) . . . . . . . . . . . . . . 111
13.7.2.63 emv_startTransaction:amtOther:type:timeout:tags:forceOnline:fallback:(double
amount,[amtOther] double amtOther,[type] int type,[timeout] int timeout,[tags]
NSData ∗tags,[forceOnline] BOOL forceOnline,[fallback] BOOL fallback) . . . . . 111
13.7.2.64 felica_authentication:(NSData ∗key) . . . . . . . . . . . . . . . . . . . . . . . . 112
#80152504-001 IDTech iOS SDK Guide for NEO2

CONTENTS vii
13.7.2.65 felica_nfcCommand:response:(NSData ∗request,[response] NSData ∗∗response) 112
13.7.2.66 felica_read:numBlocks:blockList:blocks:(NSData ∗serviceCode,[numBlocks] int
numBlocks,[blockList] NSData ∗blockList,[blocks] NSData ∗∗blocks) . . . . . . . 113
13.7.2.67 felica_readWithMac:blockList:blocks:(int numBlocks,[blockList] NSData ∗block -
List,[blocks] NSData ∗∗blocks) . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
13.7.2.68 felica_write:blockList:data:statusFlag:(NSData ∗serviceCode,[blockList] NSData
∗blockList,[data] NSData ∗data,[statusFlag] NSData ∗∗statusFlag) . . . . . . . . 113
13.7.2.69 felica_writeWithMac:data:(int blockNumber,[data] NSData ∗data) . . . . . . . . 114
13.7.2.70 icc_exchangeAPDU:response:(NSData ∗dataAPDU,[response] APDUResponse
∗∗response) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
13.7.2.71 icc_getICCReaderStatus:(ICCReaderStatus ∗∗readerStatus) . . . . . . . . . . 114
13.7.2.72 icc_powerOffICC:(NSString ∗∗error) . . . . . . . . . . . . . . . . . . . . . . . . 115
13.7.2.73 icc_powerOnICC:(NSData ∗∗response) . . . . . . . . . . . . . . . . . . . . . . 115
13.7.2.74 isConnected() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
13.7.2.75 msr_cancelMSRSwipe() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
13.7.2.76 msr_startMSRSwipe() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
13.7.2.77 pin_cancelPin() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
13.7.2.78 pin_captureAmountInput:maxPIN:message:signature:(int minPIN,[maxPIN] int
maxPIN,[message] NSString ∗message,[signature] NSData ∗signature) . . . . . 116
13.7.2.79 pin_captureFunctionKey() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
13.7.2.80 pin_captureNumericInput:minPIN:maxPIN:message:signature:(bool mask,[min -
PIN] int minPIN,[maxPIN] int maxPIN,[message] NSString ∗message,[signature]
NSData ∗signature) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
13.7.2.81 pin_capturePin:PAN:minPIN:maxPIN:message:(int type,[PAN] NSString ∗PA -
N,[minPIN] int minPIN,[maxPIN] int maxPIN,[message] NSString ∗message) . . 117
13.7.2.82 SDK_version() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
13.7.2.83 sharedController() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
13.7.3 Property Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
13.7.3.1 delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
13.8 <IDT_NEO2_Delegate>Protocol Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
13.8.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
13.8.2 Method Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
13.8.2.1 dataInOutMonitor:incoming:(NSData ∗data,[incoming] BOOL isIncoming) . . . . 119
13.8.2.2 deviceMessage:(NSString ∗message) . . . . . . . . . . . . . . . . . . . . . . . 119
13.8.2.3 emvTransactionData:errorCode:(IDTEMVData ∗emvData,[errorCode] int error) . 120
13.8.2.4 lcdDisplay:lines:(int mode,[lines] NSArray ∗lines) . . . . . . . . . . . . . . . . . 120
13.8.2.5 pinpadData:keySN:event:(NSData ∗value,[keySN] NSData ∗KSN,[event] EVEN -
T_PINPAD_Types event) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
13.8.2.6 swipeMSRData:(IDTMSRData ∗cardData) . . . . . . . . . . . . . . . . . . . . 121
13.9 IDTech_ApplicationID Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
13.9.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
13.10IDTech_TerminalData Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
13.10.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
IDTech iOS SDK Guide for NEO2 #80152802-001

viii CONTENTS
13.11IDTechEMV Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
13.11.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
13.11.2 Method Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
13.11.2.1 accelerateRead:(BOOL enabled) . . . . . . . . . . . . . . . . . . . . . . . . . 124
13.11.2.2 cancelTransaction() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
13.11.2.3 completeOnlineEMVTransaction:resultCode:issuerAuthenticationData:issuer -
Scripts:(EMV_COMPLETION_RESULT result,[resultCode] NSString ∗rc,[issuer -
AuthenticationData] NSString ∗iad,[issuerScripts] NSString ∗scripts) . . . . . . . 124
13.11.2.4 confirmApplication:(int index) . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
13.11.2.5 confirmApplicationCancel() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.11.2.6 getAllTags() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.11.2.7 getBuildVersion() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.11.2.8 getEMVConfigurationChecksum() . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.11.2.9 getEMVKernelChecksum() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.11.2.10getEMVKernelVersion() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
13.11.2.11getTag:(NSString ∗tagName) . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
13.11.2.12preloadEMVCardData() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
13.11.2.13removeApplicationData:(NSString ∗AID) . . . . . . . . . . . . . . . . . . . . . 127
13.11.2.14retrieveAIDList() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
13.11.2.15retrieveApplicationData:(NSString ∗AID) . . . . . . . . . . . . . . . . . . . . . 127
13.11.2.16retrieveTerminalData() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
13.11.2.17sendSystemError() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
13.11.2.18setApplicationData:(IDTech_ApplicationID data) . . . . . . . . . . . . . . . . . 128
13.11.2.19setTag:tagData:(NSString ∗tagName,[tagData] NSData ∗data) . . . . . . . . . . 128
13.11.2.20setTerminalData:(IDTech_TerminalData data) . . . . . . . . . . . . . . . . . . . 128
13.11.2.21sharedController() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
13.11.2.22startEMVTransaction:timeout:transactionType:additionalTags:(float amount,[timeout]
int timeout,[transactionType] int type,[additionalTags] NSMutableDictionary ∗tags) 129
13.11.3 Property Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
13.11.3.1 delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
13.12<IDTechEMV_Delegate>Protocol Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.12.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.12.2 Method Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.12.2.1 confirmApplicationSelection:retry:(NSArray ∗labelArray,[retry] BOOL tryAgain) . 130
13.12.2.2 emvTransactionData:errorCode:performReversal:(IDTEMVData ∗emvData,[error -
Code] int error,[performReversal] BOOL reversal) . . . . . . . . . . . . . . . . . 130
13.12.2.3 emvTransactionMessage:(MESSAGE_Types message) . . . . . . . . . . . . . 131
13.12.2.4 languagePreference:(NSData ∗lang) . . . . . . . . . . . . . . . . . . . . . . . 131
13.13IDTEMVData Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
13.13.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
13.13.2 Method Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
#80152504-001 IDTech iOS SDK Guide for NEO2

CONTENTS ix
13.13.2.1 clear() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
13.13.2.2 sharedController() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
13.13.3 Property Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.13.3.1 resultCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.13.3.2 resultCodeV2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.14IDTMSRData Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
13.14.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.14.2 Method Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.14.2.1 clear() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.14.2.2 sharedController() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.14.3 Property Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
13.14.3.1 captureEncodeType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
13.14.3.2 captureEncryptType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
13.14.3.3 event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
13.14.3.4 readStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
13.15MaskAndEncryption Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.15.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.15.2 Member Data Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.15.2.1 encryptionOption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.15.2.2 maskOption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.16PowerOnStructure Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.16.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
13.17TerminalData Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
13.17.1 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Index 140
IDTech iOS SDK Guide for NEO2 #80152802-001

1
Chapter 1
IDTech iOS SDK Reference Guide for NEO2
IDTech.framework is an Apple Framework that will be provided by IDTech as the main interface between iOS appli-
cations, the NEO2 and payment processing solutions.
The purpose of this document is to describe the requirements of the frameworks as well as the interface definitions
and requirements needed for any iOS applications wishing to deploy with the payment application.
•Connecting to NEO2 BLE version
•Core Implementation NEO2: Objective-C
•Core Implementation NEO2: Swift
•Important Security Notice
•NEO2 Main Transaction Commands
•Sending Direct Commands
•EMV Tag Reference
•Enumeration Reference
•NEO2 Error Code Reference
IDTech iOS SDK Guide for NEO2 #80152802-001

2 Connecting to NEO2 BLE Version
Chapter 2
Connecting to NEO2 BLE Version
A version of NEO2 uses Bluetooth 4.0, also known as Bluetooth BLE (Bluetooth Low Energy). Unlike previous
version of Bluetooth, with BLE you don't need to pair first through the Bluetooth setting on your iOS device. Once
BLE scanning is enabled (via a SDK call), the Apple iOS scans and locates all BLE devices in range and presents
a list for the SDK to choose from.
Unlike other operating systems where you can locate a BLE device by it's MAC address, due to security reasons
Apple does NOT allow you to specify a device by this address. Instead, once a device is selected (by its friendly
name), the Apple iOS will calculate a unique identifier (using parameters as the BLE device MAC address and the
iOS device UID) so any further connections can be made directly to that device.
The NEO2 has a default friendly name of "Enzytek SPS_S". This is the default name the SDK uses to connect to
the first NEO2 it encounters when no other friendly name is set in the SDK, or if the iOS generated device identifier
is not provided.
To see the current default BLE name the SDK will use: device_getBLEFriendlyName (IDT_NEO2)
If the NEO2 friendly name is different than "Enzytek SPS-S", then the SDK can be set to recognize this new name:
device_setBLEFriendlyName: (IDT_NEO2)
The API method to start BLE scanning : device_enableBLEDeviceSearch: (IDT_NEO2)
The very first time a NEO2 is used with a particular iOS device, it must be located by it's friendly name (as the
device identifier hasn't been calculated by the iOS). If there are multiple NEO2's in range, it will stop at the first one
located.
[[IDT_NEO2 sharedController] device_enableBLEDeviceSearch:nil];
Once the device is connected, its UUID can be retrieved with device_connectedBLEDevice (IDT_NEO2)
NSUUID*identifier = [[IDT_NEO2 sharedController] device_connectedBLEDevice];
That identifier can be stored in persistent memory and used for future connection to that device on the same iOS
device
[[IDT_NEO2 sharedController] device_enableBLEDeviceSearch:identifier];
Scanning for BLE devices has an impact on battery life. Once you start scanning with IDT_NEO2::device_enable -
BLEDeviceSearch:identifier:(), it will continue to scan until either a device is found (friendly name match, or identifier
match) OR a cancel BLE scanning is executed with device_disableBLEDeviceSearch (IDT_NEO2)
As an alternate indicator of scanning progress, and of any devices the iOS found, every BLE device located is
reported back to deviceMessage delegate. This information can be used to confirm if a device is in range, verify the
device friendly name, or display the iOS calculated UUID for that device. The message will start with "BLE DEVICE
FOUND:...."
BLE DEVICE FOUND: Enzytek SPS_S (B469AGF6-A9C0-4FF2-AF2A-2ECD18EDB506)
#80152504-001 IDTech iOS SDK Guide for NEO2

3
Chapter 3
Important Security Notice
The Payment Card Industry Payment Application Data Security Standard (PCI PA-DSS) is comprised of fourteen
requirements that support the Payment Card Industry Data Security Standard (PCI DSS). The PCI Security Stan-
dards Council (PCI SSC), which was founded by the major card brands in June 2005, set these requirements in
order to protect cardholder payment information. The standards set by the council are enforced by the payment
card companies who established the Council: American Express, Discover Financial Services, JCB International,
MasterCard Worldwide, and Visa, Inc.
PCI PA-DSS is an evolution of Visas Payment Application Best Practices (PABP), which was based on the Visa
Cardholder Information Security Program (CISP). In addition to Visa CISP, PCI DSS combines American Express
Data Security Operating Policy (DSOP), Discover Networks Information Security and Compliance (DISC), and
MasterCards Site Data Protection (SDP) into a single comprehensive set of security standards. The transition
to PCI PA-DSS was announced in April 2008. In early October 2008, PCI PA-DSS Version 1.2 was released to
align with the PCI DSS Version 1.2, which was released on October 1, 2008. On January 1, 2011, PCI PA-DSS
Version 2.0 was released. This extends the PCI DSS Version 1.2, which was released on October 1, 2008 and is
effective as of January 1, 2011.
3.1 Applicability
The PCI PA-DSS applies to any payment application that stores, processes, or transmits cardholder data as part of
authorization or settlement, unless the application would fall under the merchants PCI DSS validation. It is important
to note that PA-DSS validated payment applications alone do not guarantee PCI DSS compliance for the merchant.
The validated payment application must be implemented in a PCI DSS compliant environment. If your application
runs on Windows XP, you are required to turn off Windows XP System Restore Points.
3.2 What Does PA-DSS Mean to You?
The following table provides opening points to cover in any discussion with merchants on data storage.
IDTech iOS SDK Guide for NEO2 #80152802-001

4 Important Security Notice
3.3 Third Party Applications
The end-to-end transaction process, beginning with entry into the third party application until the response from the
payment engine is returned, must meet the same level of compliance. In order to claim the third party application is
end-to-end compliant, the application would need to be submitted to a QSA for a full PA-DSS audit.
The end user and/or P.O.S. developer can integrate and be compliant in the processing portion of a payment
transaction. A brief review (given below) of the PA-DSS environmental variables that impact the end user merchant
can help the end user merchant obtain and/or maintain PA-DSS compliance. Environmental variables that could
prevent passing an audit include without limitation issues involving a secure network connection(s), end user setup
location security, users, logging and assigned rights. Remove all testing configurations, samples, and data prior to
going into production on your application.
3.4 PA-DSS Guidelines
The following PA-DSS Guidelines are being provided by IDTech as a convenience to its customers. Customers
should not rely on these PA-DSS Guidelines, but should instead always refer to the most recent PCI DSS Program
Guide published by PCI SSC.
1. Sensitive Data Storage Guidelines
Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data.
1.1 Do not store sensitive authentication data after authorization (even if encrypted): Sensitive authentication
data includes the data as cited in the following Requirements 1.1.1 through 1.1.3. PCI Data Security Standard
Requirement 3.2
Note: By prohibiting storage of sensitive authentication data after authorization, the assumption is that the transac-
tion has completed the authorization process and the customer has received the final transaction approval. After
authorization has completed, this sensitive authentication data cannot be stored.
1.1.1 After authorization, do not store the full contents of any track from the magnetic stripe (located on the back
#80152504-001 IDTech iOS SDK Guide for NEO2

3.4 PA-DSS Guidelines 5
of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and
magnetic-stripe data.
In the normal course of business, the following data elements from the magnetic stripe may need to be retained:
• The accountholders name,
• Primary account number (PAN),
• Expiration date, and
• Service code
• To minimize risk, store only those data elements needed for business.
Note: See PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. PCI
Data Security Standard Requirement 3.2.1
1.1.2 After authorization, do not store the card-validation value or code (three-digit or four-digit number printed on
the front or back of a payment card) used to verify card-not-present transactions. Note: See PCI DSS and P -
A-DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. PCI Data Security Standard
Requirement 3.2.2
1.1.3 After authorization, do not store the personal identification number (PIN) or the encrypted PIN block.
Note: See PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. PCI
Data Security Standard Requirement 3.2.3
1.1.4 Securely delete any magnetic stripe data, card validation values or codes, and PINs or PIN block data stored
by previous versions of the payment application, in accordance with industry-accepted standards for secure deletion,
as defined, for example by the list of approved products maintained by the National Security Agency, or by other
State or National standards or regulations. PCI Data Security Standard Requirement 3.2
Note: This requirement only applies if previous versions of the payment application stored sensitive authentication
data.
1.1.5 Securely delete any sensitive authentication data (pre-authorization data) used for debugging or troubleshoot-
ing purposes from log files, debugging files, and other data sources received from customers, to ensure that mag-
netic stripe data, card validation codes or values, and PINs or PIN block data are not stored on software vendor
systems. These data sources must be collected in limited amounts and only when necessary to resolve a problem,
encrypted while stored, and deleted immediately after use. PCI Data Security Standard Requirement 3.2
2. Protect stored cardholder data
2.1 Software vendor must provide guidance to customers regarding purging of cardholder data after expiration of
customer-defined retention period. PCI Data Security Standard Requirement 3.1
2.2 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).
Notes:
• This requirement does not apply to those employees and other parties with a legitimate business need to see
full PAN;
• This requirement does not supersede stricter requirements in place for displays of cardholder datafor exam-
ple, for point-of-sale (POS) receipts. PCI Data Security Standard Requirement 3.3
2.3 Render PAN, at a minimum, unreadable anywhere it is stored, (including data on portable digital media, backup
media, and in logs) by using any of the following approaches:
• One-way hashes based on strong cryptography with associated key management processes and procedures
• Truncation
IDTech iOS SDK Guide for NEO2 #80152802-001

6 Important Security Notice
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key management processes and procedures. The MINIMUM account
information that must be rendered unreadable is the PAN. PCI Data Security Standard Requirement 3.4
The PAN must be rendered unreadable anywhere it is stored, even outside the payment application. Note: Strong
cryptography is defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.
2.4 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed
independently of native operating system access control mechanisms (for example, by not using local user account
databases). Decryption keys must not be tied to user accounts. PCI Data Security Standard Requirement 3.4.2
2.5 Payment application must protect cryptographic keys used for encryption of cardholder data against disclosure
and misuse. PCI Data Security Standard Requirement 3.5
2.6 Payment application must implement key management processes and procedures for cryptographic keys used
for encryption of cardholder data. PCI Data Security Standard Requirement 3.6
2.7 Securely delete any cryptographic key material or cryptogram stored by previous versions of the payment ap-
plication, in accordance with industry-accepted standards for secure deletion, as defined, for example the list of
approved products maintained by the National Security Agency, or by other State or National standards or reg-
ulations. These are cryptographic keys used to encrypt or verify cardholder data. PCI Data Security Standard
Requirement 3.6
Note: This requirement only applies if previous versions of the payment application used cryptographic key materials
or cryptograms to encrypt cardholder data.
3. Provide secure authentication features
3.1 The payment application must support and enforce unique user IDs and secure authentication for all administra-
tive access and for all access to cardholder data. Secure authentication must be enforced to all accounts, generated
or managed by the application by the completion of installation and for subsequent changes after the "out of the
box" installation (defined at PCI DSS Requirements 8.1, 8.2, and 8.5.88.5.15) for all administrative access and for
all access to cardholder data. PCI Data Security Standard Requirements 8.1, 8.2, and 8.5.88.5.15
Note: These password controls are not intended to apply to employees who only have access to one card number
at a time to facilitate a single transaction. These controls are applicable for access by employees with administrative
capabilities, for access to servers with cardholder data, and for access controlled by the payment application. This
requirement applies to the payment application and all associated tools used to view or access cardholder data.
3.1.10 If a payment application session has been idle for more than 15 minutes, the application requires the user to
re-authenticate. PCI Data Security Standard Requirement 8.5.15.
3.2 Software vendors must provide guidance to customers that all access to PCs, servers, and databases with
payment applications must require a unique user ID and secure authentication. PCI Data Security Standard Re-
quirements 8.1 and 8.2
3.3 Render payment application passwords unreadable during transmission and storage, using strong cryptography
based on approved standards
Note: Strong cryptography is defined in PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.
PCI Data Security Standard Requirement 8.4
4. Log payment application activity
4.1 At the completion of the installation process, the out of the box default installation of the payment application
must log all user access (especially users with administrative privileges), and be able to link all activities to
individual users. PCI Data Security Standard Requirement 10.1
4.2 Payment application must implement an automated audit trail to track and monitor access. PCI Data Security
Standard Requirements 10.2 and 10.3
5. Develop secure payment applications
#80152504-001 IDTech iOS SDK Guide for NEO2

3.4 PA-DSS Guidelines 7
5.1 Develop all payment applications in accordance with PCI DSS (for example, secure authentication and logging)
and based on industry best practices and incorporate information security throughout the software development life
cycle. These processes must include the following: PCI Data Security Standard Requirement 6.3
5.1.1 Live PANS are not used for testing or development. PCI Data Security Standard Requirement 6.4.4.
• Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.)
• Validation of proper error handling
• Validation of secure cryptographic storage
• Validation of secure communications
• Validation of proper role-based access control (RBAC)
5.1.2 Separate development/test, and production environments
5.1.3 Removal of test data and accounts before production systems become active development. PCI Data Security
Standard Requirement 6.4.4
5.1.4 Review of payment application code prior to release to customers after any significant change, to identify any
potential coding vulnerability. Removal of custom payment application accounts, user IDs, and passwords before
payment applications are released to customers
Note: This requirement for code reviews applies to all payment application components (both internal and public-
facing web applications), as part of the system development life cycle required by PA-DSS Requirement 5.1 and
PCI DSS Requirement 6.3. Code reviews can be conducted by knowledgeable internal personnel or third parties.
5.2 Develop all web payment applications (internal and external, and including web administrative access to product)
based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of
common coding vulnerabilities in software development processes, to include:
• Injection flaws, with particular emphasis on SQL injection, Cross-site scripting (XSS) OS Command Injection,
LDAP and Xpath injection flaws, as well as other injection flaws.
• Buffer Overflow.
• Insecure cryptographic storage.
• Insecure communications.
• Improper error handling.
• All HIGH vulnerabilities as identified in the vulnerability identification process at PA-DSS Requirement 7.1.
• Cross-site scripting (XSS)
• Improper access control such as insecure direct object references, failure to restrict URL access and directory
traversal.
• Cross-site request forgery (CSRF)
Note: The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9
were current in the OWASP guide when PCI DSS v1.2 / PCI DSS v2.0 (01/01/10) were published. However, if and
when the OWASP guide is updated, the current version must be used for these requirements.
5.3 Software vendor must follow change control procedures for all product software configuration changes. PCI
Data Security Standard Requirement 6.4. 5.The procedures must include the following:
• Documentation of impact
• Management sign-off by appropriate parties
• Testing functionality to verify the new change(s) does not adversely impact the security of the system. Remove
all testing configurations, samples, and data before finalizing the product for production.
IDTech iOS SDK Guide for NEO2 #80152802-001

8 Important Security Notice
• Back-out or product de-installation procedures
5.4 The payment application must not use or require use of unnecessary and insecure services and protocols (for
example, NetBIOS, file-sharing, Telnet, unencrypted FTP must be secured via SSH, S-FTP, SSL, IPSec and other
technology to implement end to end security). PCI Data Security Standard Requirement 2.2.2
6. Protect wireless transmissions
6.1 For payment applications using wireless technology, the wireless technology must be implemented securely.
Payment applications using wireless technology must facilitate use of industry best practices (for example, IE -
EE 802.11i) to implement strong encryption for authentication and transmission. Controls must be in place to
protect the implemented wireless network from unknown wireless access points and clients. This includes testing
the end users wireless deployment on a quarterly basis to detect unauthorized access points within the system.
Change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and S -
NMP community strings. Maintain a detailed updated hardware list. The end to end wireless implementation must
be end to end secure. The use of WEP as a security control was prohibited as of 30 June 2010. PCI Data Security
Standard Requirements 1.2.3, 2.1.1, 4.1.1, 6.2, 11.1a-e and 11.4a-c.
7. Test payment applications to address vulnerabilities
7.1 Software vendors must establish a process to identify newly discovered security vulnerabilities (for example,
subscribe to alert services freely available on the Internet) and to test their payment applications for vulnerabilities.
Any underlying software or systems that are provided with or required by the payment application (for example,
web servers, third-party libraries and programs) must be included in this process. Remove all test configurations,
samples, and data after testing and before promoting the changes to production. PCI Data Security Standard
Requirement 6.2
7.2 Software vendors must establish a process for timely development and deployment of security patches and
upgrades, which includes delivery of updates and patches in a secure manner with a known chain-of-trust, and
maintenance of the integrity of patch and update code during delivery and deployment.
8. Facilitate secure network implementation
8.1 The payment application must be able to be implemented into a secure network environment. Application must
not interfere with use of devices, applications, or configurations required for PCI DSS compliance (for example, pay-
ment application cannot interfere with anti-virus protection, firewall configurations, or any other device, application,
or configuration required for PCI DSS compliance). PCI Data Security Standard Requirements 1, 3, 4, 5, and 6.
9. Cardholder data must never be stored on a server connected to the Internet
9.1 The payment application must be developed such that the database server and web server are not required to
be on the same server, nor is the database server required to be in the DMZ with the web server. PCI Data Security
Standard Requirement 1.3.7
10. Facilitate secure remote software updates
10.1 If payment application updates are delivered securely via remote access into customers systems, software
vendors must tell customers to turn on remote-access technologies only when needed for downloads from vendor
#80152504-001 IDTech iOS SDK Guide for NEO2

3.5 More Information 9
and to turn off immediately after download completes. Alternatively, if delivered via VPN or other high-speed con-
nection, software vendors must advise customers to properly configure a firewall or a personal firewall product to
secure authentication using a two factor authentication mechanism. PCI Data Security Standard Requirement 8.3
10.2 If payment application may be accessed remotely, remote access to the payment application must be authen-
ticated using a two factor authentication mechanism. PCI Data Security Standard Requirement 8.3
10.3 Any remote access into the payment application must be done securely. If vendors, resellers/integrators, or
customers can access customers payment applications remotely, the remote access must be implemented securely.
PCI Data Security Standard Requirements 1, 8.3 and 12.3.9
11. Encrypt sensitive traffic over public networks
11.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment
application must support use of strong cryptography and security protocols such as SSL/TLS and Internet protocol
security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks. Examples
of open, public networks that are in scope of the PCI DSS are: The Internet Wireless technologies Global System for
Mobile Communications (GSM) General Packet Radio Service (GPRS) PCI Data Security Standard Requirement
4.1
11.2 The payment application must never send unencrypted PANs by end-user messaging technologies (for exam-
ple, e-mail, instant messaging, and chat). PCI Data Security Standard Requirement 4.2
12. Encrypt all non-console administrative access
12.1 Instruct customers to encrypt all non-console administrative access using technologies such as SSH, VPN, or
SSL/TLS for web-based management and other non-console administrative access. Telnet or remote login must
never be used for administrative access. PCI Data Security Standard Requirement 2.3
13. Maintain instructional documentation and training programs for customers, resellers, and integrators
13.1 Develop, maintain, and disseminate a PA-DSS Implementation Guide(s) for customers, resellers, and integra-
tors that accomplishes the following:
• Addresses all requirements in this document wherever the PA-DSS Implementation Guide is referenced.
• Includes a review at least annually and updates to keep the documentation current with all major and minor
software changes as well as with changes to the requirements in this document.
13.2 Develop and implement training and communication programs to ensure payment application resellers and
integrators know how to implement the payment application and related systems and networks according to the
PA-DSS Implementation Guide and in a PCI DSS-compliant manner.
• Update the training materials on an annual basis and whenever new payment application versions are re-
leased.
3.5 More Information
IDTech Systems, Inc. highly recommends that merchants contact the card association(s) or their processing com-
pany and find out exactly what they mandate and/or recommend. Doing so may help merchants protect themselves
from fines and fraud.
For more information related to security, visit:
IDTech iOS SDK Guide for NEO2 #80152802-001

10 Important Security Notice
•http://www.pcisecuritystandards.org
•http://www.visa.com/cisp
•http://www.sans.org/resources
•http://www.microsoft.com/security/default.asp
•https://sdp.mastercardintl.com/
•http://www.americanexpress.com/merchantspecs
CAPN questions: [email protected]
#80152504-001 IDTech iOS SDK Guide for NEO2