JetPayi5 Programmers Guide

Transcription

1 JetPayi5 Programmers Guide This guide provides detailed information on the JETTRAN command, the JETPTRN API, and the database files. Contents Introduction The JETTRAN command The JETPTRN API Database files Appendices A,B,C,D Introduction Processing credit cards (and checking accounts) requires communicating with the JetPay servers. The JetPayi5 software provides two methods of doing this. One is via a command JETTRAN and the other is via a callable Application Program Interface (API) JETPTRN. The API is useful when calling from programs because it returns its response as variables (fields) rather than as messages. The command is useful for calling from a command line such as when testing. The command can also be put into CL programs. The other method of processing credit cards is to use the Manual Card-Entry program JETCARD. This is described in the manual User Applications Guide. JETCARD takes the information from the screens and then calls the API program to do the transaction.

2 The JETTRAN command There are 34 parameters for this command as follows: Transaction type TYPE Char(9) The type of transaction that will be processed. Possible values are: SALE CREDIT VOID AUTHONLY CAPTURE FORCE CHECK CHECKCRED CHECKVOID ENQ PING Explanation of each value: SALE Authorizes and captures a credit card charge in a single transaction. CREDIT Submits a credit card transaction reversal for settlement and deposit funds into a credit card. It is normally used to reverse a SALE, although it need not be related to a SALE transaction. VOID Removes a credit card transaction from the host before the transaction settles. If a transaction has already settled, it cannot be VOIDed (when a transaction is not VOIDed before settlement, a CREDIT transaction is required to reverse the charge). See also CREDIT. AUTHONLY The credit card limit is checked to verify that a certain amount is available (and to reserve that amount), but the card is not charged. Either a FORCE or CAPTURE is used to complete the transaction. CAPTURE A credit card charge using an amount equal to or less than the amount of a previous AUTHONLY transaction. The AUTHONLY transaction is required to be present in the database. FORCE A credit card charge using an amount equal to or less than the amount of a previous AUTHONLY transaction. The AUTHONLY transaction is not required to be in the database. CHECK Submits a request for the withdrawal of funds from an ACH checking account. This is also used for German ELV bank accounts. CHECKCRED Used to credit funds into an ACH checking account. Also used for ELV bank accounts.

3 CHECKVOID Used to cancel a CHECK transaction. This will only work if the CHECK transaction has not been processed. Otherwise a CHECKCRED can be used. ENQ (Enquire) Used to query a transaction in the JetPay database. This database is not the one residing locally on the iseries, but the remote database which is held by JetPay LLC. These two databases should correspond but if a situation arises leading to questions about the accuracy of the local database, this ENQ can be used to confirm whether or not there are discrepancies between transactions. The ENQ transaction is not recorded in the transaction history file JHIST. PING Verify that there is an active communication with the JetPay server. This is similar to the DOS/UNIX ping command. The server can be either the test or production server. A confirmation or rejection message is returned. The PING transaction is not recorded in the transaction history file JHIST. Mode MODE Char(5) The mode in which the transaction will be processed. Possible values are: *TEST *PROD Run transaction in test mode Run transaction in production mode The default value is *TEST. Transactions run in production mode will cause the transaction to be processed for real, providing that there are no errors and a Merchant ID has been issued. This ID will be issued when a merchant account has been set up by an acquiring bank. See the Merchant Application document for details. Transactions run in test mode will not cause a real card (or checking account) to be processed. Instead the software contacts a different server which simulates the transaction. This server returns a response which shows that the communication was successful. The Test Server is disconnected from the financial institutions. Instead of communicating with financial institutions, the JetPay Test System accesses a suite of back-end simulators that sends proxy bogus responses back to JetPay, thereby simulating the connections with Visa, MasterCard, American Express, and numerous other financial organizations. The Test Server is provided for the purpose of testing, evaluation and education. It is not a high-capacity server so do not use it for stress testing (e.g. by running a high-volume of transactions in a program loop). Doing so may be considered a Denial-of-Service operation and may lead to the operator being barred from using JetPay s servers without notice. Credit Card number CARDNUM Char(20) The Credit Card number embossed on the front of a card. It must be from 9 to 19 digits long or left blank. It must also be a number which matches the Mod 10 check-sum algorithm. The field is 20 characters long but only 19 are currently allowed to be entered.

4 The card number is required for transaction types: Sale, Credit, Force, Void, and Auth-Only. It is not permitted for types: Check, Check-credit, Check-void, or Ping. It is optional for types: Capture and Enquire. CVV2/CVC2/CID CVV2 Char(4) The Card Verification Value printed on the back of a credit card. The CVV2 number is a threeor four-digit value. These CVV2 digits provide additional security for a transaction, assuring the physical presence of a credit card. This value is optional, however, providing it will decrease the risk of a fraudulent transaction and thus lower the processing fees (in most cases). Please note the terminology differences between credit card companies, in that Visa uses the CVV2 term (meaning Card Verification Value 2 ), MasterCard uses CVC2 term (meaning Card Validation Code 2 ), and American Express uses the CID term (meaning Card IDentifier code ). The CVV2 value is not stored on the JHIST (transaction history) or any other file. It is forbidden by VISA to store this number anywhere, even in an encrypted format. The number should only be present when entering the transaction. This measure is taken to reduce the likelihood of fraudulent transactions. Expiry Month/Year (MMYY) EXPIRY Char(4) The expiry month and year embossed on the front of a card. It is 4 digits long; the first two are the month from 01 to 12 and last two are the year from 00 to 99. It is required for transaction types: Sale, Credit, Void, Force, and Auth-Only. Total amount in cents TOTAMT Packed decimal(9,0) The value of the transaction expressed in cents. For example $12.47 would be entered as This is the purchase price to be transacted, including taxes and fees. Only positive values are allowed. The currency type assumed for the amount is dependent on how the merchant account is set up. For currencies which don t have hundredths of their base unit (equivalent of cents), it will be the actual value. E.g. 315 yen will be entered as 315. It is required for transaction types: Sale, Credit, Force, Auth-Only, Check, Check-credit, and Check-void. Fee amount in cents FEEAMT Packed decimal(9,0) The surcharge value of the transaction expressed in cents. The surcharge value within this element is assumed to be already included in total amount. This parameter is optional. Tax amount in cents TAXAMT Packed decimal(9,0)

5 The tax value of the transaction expressed in cents. The tax value within this element is assumed to be already included in total amount. This parameter is optional. Transaction number TRANUM Packed decimal(11,0) The transaction number of a previous transaction. This is used with transaction types Void, Capture, Check-Void and Enquire; and identifies the original transaction that is being acted on. It is required for all these types. Approval code APPROV Char(6) A code returned by JetPay which is used to identify a previous transaction. The approval code is used with transaction types Void, Capture, Force and Enquire; and identifies the original transaction that is being acted on. It is required for types Void and Force, but optional for types Capture and Enquire. Transaction origin ORIGIN Char(11) A code which tells how the card number was acquired. This value may be used by JetPay to determine the degree of risk of card fraud, and hence the type of fees to be applied against each transaction. Possible values are: INTERNET POS RECURRING BILLPAYMENT PHONEORDER MAILORDER *NONE Explanation of each value: INTERNET the transaction originated on the internet such as via e-commerce. No card was present. POS the transaction is a Point Of Sale retail transaction. A card was present. RECURRING the transaction is a reoccurring such as a subscription payment. No card is present but it is the same card number each time. BILLPAYMENT the transaction is for a bill payment such as a utility or phone bill. No card is present but it is the same card number each time. PHONEORDER/MAILORDER the transaction originated via phone or mail respectively. No card was present. This is similar to INTERNET but considered to be lower risk.

6 *NONE no origin is specified. This is the default value. The transaction risk may be assumed by JetPay as being similar to INTERNET. User-defined ref 1 UDREF1 Char(8) A user defined code which can be used to identify transactions. There are three of these and any character string can be placed into them. It is intended that these fields will be used to interface with an existing ERP database. Examples of information that can be put into them are: customer number, order number and customer purchase order number. This information will be stored on the Transaction History file (JHIST) and will also be stored on JetPay s databases. User-defined ref 2 UDREF2 Char(10) A user defined code which can be used to identify transactions. See UDREF1 above. User-defined ref 3 UDREF3 Char(15) A user defined code which can be used to identify transactions. See UDREF1 above. Card name CARDNAME Char(30) The name embossed on the credit card. For ACH/ELV transactions, it will be the name on the bank account. Billing street 1 BILLSTR1 Char(30) The first line of the street address of the card holder. This information, including the following billing address parameters is optional; however providing it will reduce the likelihood of fraud. Billing street 2 BILLSTR2 Char(30) The second line of the street address of the card holder. Billing city BILLCITY Char(30) The city or town of the card holder. Billing state/province BILLSTAT Char(25) The state or province of the card holder. Billing zip/post-code BILLPSTC Char(10)

7 The zip or postal code of the card holder. Billing country code BILLCTRY Char(2) The country code of the card holder. A list of valid countries is stored in the Country Codes file JCTRY. Billing phone number BILLPHON Char(20) The phone number of the card holder (optional). address Char(100) The card holders address (optional). Shipping method SHIPMETH Char(10) The manner of delivering a purchase to the recipient. It is optional. One of five shipping methods may be specified: Value SAMEDAY OVERNIGHT PRIORITY GROUND ELECTRONIC *NONE Explanation courier delivery next day delivery two to three days shipping time four or more days shipping time delivery of purchase by electronic means none specified (default) Ship-to name SHIPNAME Char(30) The name of the recipient that will be receiving delivered goods. This and the following shipping address parameters are optional. They will be stored in the database for future inquiry. Shipping street 1 SHIPSTR1 Char(30) The first line of the street address of the ship-to recipient. If this parameter contains the value *BILL, this will cause all elements of the Billing address to be copied into the corresponding elements of Shipping address, regardless of whether those Shipping address parameters contain information. It will also cause the Card name to be copied to the Ship-to name, providing the Ship-to name is blank; and the Billing phone to be copied to the Shipping phone, providing the Shipping phone is blank.

8 Shipping street 2 SHIPSTR2 Char(30) The second line of the street address of the ship-to recipient. Shipping city SHIPCITY Char(30) The city or town of the ship-to recipient. Shipping state/province SHIPSTAT Char(25) The state or province of the ship-to recipient. Shipping zip/post-code SHIPPSTC Char(10) The zip or postal code of the ship-to recipient. Shipping country code SHIPCTRY Char(2) The country code of the ship-to recipient. A list of valid countries is stored in the Country Codes file JCTRY. Shipping phone number SHIPPHON Char(20) The phone number of the ship-to recipient (optional). ACH information ACHINFO Multiple elements The ACH (Automated Clearing House) information used to withdrawing funds from a checking account. This information is used for transactions types Check, Check-void, and Check-credit. It is broken into 6 fields as follows: ACH account type ACHINFO.1 Char(8) The account type. Possible values are: Value SAMEDAY CHECKING SAVINGS BUSCHECK *NONE Explanation courier delivery checking account savings account business checking account none specified (required for credit card and ELV transactions)

9 ACH SEC code ACHINFO.2 Char(3) The Standard Entry Class code. It must be blank or one of the values listed in Appendix D. ACH bank account number ACHINFO.3 Char(17) The bank account number. ACH ABA (routing) number ACHINFO.4 Char(9) The ABA routing number. It is a character field but it must contain exactly 9 numeric digits. [The reason for using characters is that iseries command elements don t allow the decimal data type.] ACH check number ACHINFO.5 Char(8) The ACH check number. It is shown as a character field but must contain only numeric digits (from 1 to 8). ACH scrutiny ACHINFO.6 Char(4) ABA validation and Account Number pattern-matching is enabled and disabled through this flag. Possible values are: Value HIGH LOW NONE *NA Explanation Validate both the ABA number and the Account Number pattern Validate only the ABA number for the transaction Perform no validation of the ACH transaction and submit as is none specified (required for credit card and ELV transactions) If no value is specified, then HIGH is assumed. ELV information ELVINFO Multiple elements The information used for ELV transactions, which are a direct-debit banking transaction supported by German banks. This information is used for transactions types Check, and Check-credit. It is broken into 3 fields as follows: ELV type ACHINFO.1 Char(3) This parameter is not used at present and always contains the value ELV.

10 ELV bank account number ELVINFO.2 Char(17) The bank account number. ELV bank branch code ELVINFO.3 Char(8) The bank branch code. It is a character field but it must contain exactly 8 numeric digits.

11 The JETPTRN program Program JETPTRN can be called to perform transactions. It has a list of parameters which are very similar to those of the JETTRAN command. In fact the JETTRAN command uses JETPTRN as its Command Processing Program (CPP). Because of this their parameters are listed in the same order and are mostly the same size. There are 44 parameters for this program as follows: Field Length Dec Transaction type 2 Processing mode 1 Credit Card number 20 CVV2/CVC2/CID 4 Expiry Month/Year 4 Total amount in cents 9 0 Fee amount in cents 9 0 Tax amount in cents 9 0 Transaction number 11 0 Approval code 6 Transaction origin 2 User-defined ref 1 8 User-defined ref 2 10 User-defined ref 3 15 Card name 30 Billing street 1 30 Billing street 2 30 Billing city 30 Billing state/province 25 Billing zip/post-code 10 Billing country code 2 Billing phone number 20 address 100 Shipping method 2 Ship-to name 30 Shipping street 1 30 Shipping street 2 30 Shipping city 30 Shipping state/province 25 Shipping zip/post-code 10 Shipping country code 2 Shipping phone number 20 ACH information DS ELV information DS Optional parameter group 1 Return Transaction number 11 0 Return Action code 3

12 Return Approval code 6 Return Response text 35 Return AVS 1 Return Address match 1 Return Zip match 1 Return CVV2 1 Return Additional info 20 Optional parameter group 2 Return Error message DS In the above list, all fields are assumed to be character, unless they have a value in the Dec column, in which case they are packed-decimal and Dec is the number of decimal places. Lengths marked with DS are data-structures. The program has 10 additional parameters than the command. These contain return variables which can be used by the program calling the API. They are optional and if not supplied (such as when calling via the command) the information they contain will be returned to the Job-Log as messages. Since most of the parameters are identical to those of the command, it is only necessary to describe the differences and additional parameters. The following parameters have a different length to what is on the command: Transaction type Char(2) This has been reduced from 9 to 2 characters. The conversions are: Command Program SALE SA CREDIT CR VOID VO AUTHONLY AU CAPTURE CA FORCE FO CHECK CH CHECKCRED CC CHECKVOID CV ENQ EN PING PI Mode Char(1) This has been reduced from 5 to 1 character. The conversions are:

13 Command *TEST *PROD Program T P Origin Char(2) This has been reduced from 11 to 2 characters. The conversions are: Command Program INTERNET IN POS PS RECURRING RE BILLPAYMENT BP PHONEORDER PH MAILORDER MO *NONE (blanks) Shipping method Char(2) This has been reduced from 10 to 2 characters. The conversions are: Command Program SAMEDAY SD OVERNIGHT ON PRIORITY PR GROUND GR ELECTRONIC EL *NONE (blanks) ACH account type Char(2) This has been reduced from 10 to 2 characters. The conversions are: Command CHECKING SAVINGS BUSCHECK *NONE Program CH SA BU (blanks) ACH scrutiny Char(1) This has been reduced from 4 to 1 character. The conversions are:

14 Command HIGH LOW NONE *NA Program H L N (blanks) The following parameters are additional to what is on the command: Return Transaction number Packed(11,0) The transaction number that is associated with the transaction just processed. For types: Sale, Credit, Authorize-only, Force, Check and Check-credit; this will be the number which has been generated for the transaction. For other types it will be the number which has been input. It will be zero for type Ping. Return Action code Char(3) This is a code which indicates whether the transaction was successful. A 000 (three zeros) tells that the transaction has been approved by the issuer bank. Any other value indicates an error. See Appendix A for a full list of these. Return Approval code Char(6) This code is generated by the issuer bank and indentifies the transaction. This code can then be used to identify the original transaction when doing actions like Capture, Void, Force and Enquire. Return Response text Char(35) This is text which describe the Action Code (above). Note that a 000 Action Code may have multiple Response Text values, including APPROVED, ACCEPTED, CAPTURED, and PING. Other Action Codes will contain a Response Text value of DECLINED or some similar phrase. Return AVS Char(1) A code indicating the AVS ( Address Verification Service ) results for a transaction. Refer to Appendix B in this reference for a explanation of the valid result codes, A, B, C, D, E, F, G, K, L, M, N, O, P, R S, U, W, X, Y, and Z. Return Address Match Char(1)

15 A code indicating the address match results for a credit card transaction. Returns Y, N, or X, where: Y The address matches. N The address does not match. X No result available (AVS requested but not performed). Return ZIP Match Char(1) A code indicating the ZIP or postal code match results for a credit card transaction. Returns Y, N, or X, where: Y The postal code matches. N The postal code does not match. X No result available (AVS requested but not performed). Return CVV2 Char(1) The response code to a Visa CVV2 or a MasterCard CVC2 or an American Express CID submission. Refer to Appendix C in this reference for an explanation of the valid result codes, M, N, P, S, and U. Return Additional info Char(20) For ACH transactions, this element can contain additional information that resulting from ACH validation. This information becomes particularly important when the ACH transaction s Scrutiny is submitted as LOW or NONE. Return Error message Data-Structure(*) This contains details of any error messages generate. It is optional and if not supplied error messages will instead be returned as escape messages to the calling program. The structure of this parameter is identical to OS/400 API error parameters. Pos Len Type Description 0 4 Bin Bytes provided 4 4 Bin Bytes available 8 7 Char Message ID 15 1 reserved 16 * Char Message data (variable length but no more than 203 bytes are returned) It must be at least 8 bytes long, i.e. it must contain the first 2 elements. There are two other data structures which also need to be defined. ACH information Data-Structure(40) Pos Len Type Description

16 0 2 Char Account type 2 3 Char SEC code 5 17 Char Bank Account number 22 9 Char ABA (routing) number 31 8 Char Check number 39 1 Char Scrutiny ELV information Data-Structure(28) Pos Len Type Description 0 3 Char Account type 3 17 Char Bank Account number 20 8 Char Bank Branch

17 The Database Files The JetPayi5 database consists of 3 physical files as follows: JHIST Transaction history JPARM Parameters JCTRY Country codes These are stored in the library JETPAYF and kept separate from the program objects. There are also 7 logical files built over these physical files. The library name JETPAYF is the default database library but its name is unimportant. It is only required that the files be in the library-list. This library can be duplicated to create, e.g., a test or education database. This approach is recommended to keep test data separate. JHIST Transaction History This is the most important file because it contains a copy of all the transactions. It has 49 fields, most of which are a copy of the parameters passed to the API or command. Since most of the fields are identical to the parameters passed and received by the API, it is not necessary to discuss them further. Instead only the differences, added fields and other non-obvious information will be shown here. Field: HTRANUM Transaction number This is the generated or passed transaction number. It is 11 digits longs, however only the first 10 digits form a sequential numbering system. The final (11 th ) digit is a check-sum digit which is calculated from the other digits. This is done to reduce keying errors. This digit is chosen to match the modulus-10 (Mod 10) Luhn algorithm. The transaction number is not always unique because it may be used in a reference transaction. For example an Authorize-Only and a Capture have the same transaction number. So do Sale and a corresponding Void. A separate range of transaction numbers is kept for production and test-mode transactions. This allows the test-transaction records to be later deleted without creating holes in the production sequences. Field: HCARDNUM Card number (encrypted) This is the credit card number in an encrypted format. The card number is encrypted using a method which can t be undone which means that the original card number can t be retrieved from the encryption. This is done for data protection reasons.

18 But even though the number can t be retrieved this information can still be queried by comparing it with an encrypted value of a known card. This is what the JETINQ program does when it looks up card numbers. The card is encrypted using the one-way SHA-1 algorithm as documented in FIPS Field: HCARD4 Card number last 4 digits This is the last 4 digits of the credit card number in a plain text (unencrypted) format. This is stored to help the user identify a transaction. It can also be used as a lookup method in the JETINQ program. These digits will be extracted from the end of a number so their extracted positions will vary. On a 16 digit card they will be represent positions 13-16, but on a 12 digit card they will represent Missing field: CVV2 There is no field to store the CVV2 value. This is done for data protection reasons. See the earlier notes on CVV2 storage restrictions. Field: HEXPMONTH and HEXPYEAR expiry month and year The expiry month and year are input into the API as a 4 character field and are then split into two Packed(2,0) decimal fields. Field: HCARDASOC Card association This 2 character field gives the credit card association. Currently only 3 values are recorded: Value Explanation VI VISA MC MasterCard OT other This value is determined from the leading digits of the credit card. It may be useful in queries. Field: HACHSEC ACH Standard Entry Class or ELV This is normally used to hold the SEC (Standard Entry Class) for an ACH transaction. But when it has the value ELV then this is an ELV transaction instead. Field: HTIMSTP Date/Time-stamp

19 This is the date and time that a record was written to JHIST. It holds: Century, Year, Month, Day, Hour, Minute, Second, and Millisecond. Field: HUSER User ID This is the user profile of the job which wrote the JHIST record. Field: HRTRSPTXT Return info - response text This is the Response Text. It comes from the API field of the same name but it has been truncated from 35 down to 15 characters. This is done to reduce the file size since much of this field is normally blank. Field: HRTADLINF Return info - additional info This is the Additional Info for ACH transactions. It comes from the API field of the same name but it has been truncated from 20 down to 11 characters. This is done to reduce the file size since much of this field is normally blank. JPARM Parameters This file holds small amounts of general data which did not warrant the creation of a separate file. It has an 80 character data field which can be formatted to hold any type of data and an 8 character key to identify the data. If the data extends beyond 80 characters, a sequence number is used to extend it up to 999 times. Currently this holds: the most-recent transaction sequence numbers, the Merchant ID and Industry type. See the Parameters Setup program JETPARM in the manual User Applications Guide for more detail. JCTRY Country codes This file holds a list of country codes and their descriptions. It is intended for use with billing and shipping addresses. The codes come in 2 and 3 characters, and 3 digits. This file comes preloaded with the software. There is no program to edit it since the contents would rarely need to be changed.

20 Appendix A Action Codes This gives a description of the action codes which are returned with each transaction. Code Description Code Description 000 Approved 065 Count limit exceeded 001 Refer to Issuer 075 PIN tries exceeded 002 Refer to issuer special 076 Unable to locate previous message 003 Invalid merchant 077 Edit Error 004 Pick up card 080 Invalid date 005 Do not honor 081 PIN crypto error 006 Error 082 Incorrect CVV 007 Pick up card special 083 Unable to verify PIN 008 Approve with ID 085 No reason to decline 011 VIP approval 091 Issuer inoperative 012 Invalid transaction 092 Routing failure 013 Invalid amount 093 Law violation 014 Invalid card number 096 System error 015 Invalid issuer 099 Timeout 019 Re-enter transaction 107 Call Issuer 021 No action taken 801 Invalid effective date 025 Unable to locate record 803 Invalid biller information 028 File unavailable 805 Force STP 030 Format error 806 CVV2 failure 039 No credit account 807 Miscellaneous error 041 Lost card 908 Manual card entry invalid 043 Stolen card 909 Invalid track information 051 Insufficient funds 912 Invalid card format 052 No checking account 917 Expired card 053 No savings account 920 Invalid amount 054 Expired card 926 Invalid Password 055 Invalid PIN 942 Refund Not Allowed 057 Transaction not permitted 987 Issuer unavailable 058 Transaction not permitted 989 Database Error 061 Amount limit exceeded 992 Transaction timeout 062 Restricted Card 998 Message not supported 063 Security violation 999 Communications failure

21 Appendix B AVS Result Codes JetPay offers cardholder address verification through AVS, a system available widely throughout North America and much of Europe. With address verification, the merchant submits a customer s address and postal code information in a transaction; the credit card issuer verifies and validates the address information against their internal billing address data. The result code sent by an issuer advises the merchant of a customer s billing integrity when completing the credit card transaction. Visa and MasterCard both call this feature AVS, which stands for Address Verification Service. American Express calls this feature AAV, which stands for Address Authentication and Verification. Almost all North American issuers support AVS using Visa and MasterCard association rules. According to these rules, an issuer compares the numeric digits within a cardholder s address and postal code information with their own stored billing information. All alphabetic information is ignored. The address and postal code match (or fail to match) and an AVS result code is generated by the issuer. This is returned to the merchant during an authorization. American Express adds cardholder name matching to their AAV. A merchant can submit their customer s name in addition to the billing address information and may receive a number of additional AVS result codes. Shipping address information may also be submitted in an Amex transaction, and additional result codes are anticipated from Amex in the future. For most issuers, the AVS works independent of the action code. In other words, a transaction may be approved even though billing address information doesn t match. Because transaction approval is independent of billing address integrity, it s up to the merchant to decide the importance of correct billing address information when completing a sale. A merchant may simply allow a transaction to proceed, or a merchant might independently discontinue the sale in spite of an approval. JetPay, based on the AVS result code, automatically fills the Address-Match and Zip-Match elements. The possible Address-Match and Zip-Match values are Y, N, or X, and the value is deterministic with the AVS result code. JetPay offers an Automatic AVS Rejection feature, where merchants may automatically decline any transactions showing degraded AVS results. Automatic AVS Rejection is an optional subscription service that requires a merchant to subscribe before JetPay will automatically reject transactions on behalf of the merchant. A result code indicating the AVS ( Address Verification Service ) results for a transaction may be A, B, C, D, E, F, G, K, L, M, N, O, P, R S, U, W, X, Y, or Z, where: A B C D Address matches, but postal code does not match. Visa only: Street address matches, postal code not verified because of incompatible format. Visa only: Street address and postal code not verified because of incompatible formats. Visa only: Street address and postal code match.

22 E F G K L M N O P R S U W X Y Z Amex only: Cardholder name incorrect, postal code matches. Amex only: Cardholder name incorrect, address and postal code matches. Amex only: Cardholder name incorrect, billing address matches. Visa only: Global non-avs participant outside the U.S.; address is not verified for international transaction. Amex only: Cardholder name matches. Amex only: Cardholder name and postal code match. Amex only: Cardholder name, address and postal code match. Visa only: Street address and postal code match. Neither the address nor the postal code matches. Amex only: Cardholder name and address match. Visa only: Postal code matches, street address not verified because of incompatible format. Retry, system unable to process. MasterCard only: AVS currently not supported. Unavailable. Address not verified. AVS attempted, but no AVS information was available (issuer is not an AVS participant or issuer did not return an AVS result). MasterCard only: Nine-digit postal code and address match. Amex only: Cardholder name, address, and postal code are all incorrect. MasterCard only: Five-digit postal code and address match. Both the address and the postal code match exactly. Postal code matches, but address does not match.

23 Appendix C CVV2 Result Codes JetPay enables credit card validation through the CVV2 feature, a system widely supported throughout the credit card industry. With this feature, every physical credit card has a three- or four-digit value imprinted on the credit card in addition to the card number. Submitting this three- or four-digit security code enhances fraud detection for a transaction, ensuring that a genuine physical credit card is present during that transaction. Visa cards have a three-digit CVV2 value, MasterCard cards have a three-digit CVC2 value, and American Express uses a four-digit CID value to enable card validation. This three- or fourdigit value is found imprinted on the back side of a credit card, usually inside the signature block (it may also be imprinted on the front side of the card). The response code to a Visa CVV2 or a MasterCard CVC2 or an American Express CID submission may be M, N, P, S, or U, where: M N P S U CVV2 matches. CVV2 does not match. Not processed. CVV2 should be on the card, but merchant indicates it is not. Issuer is not certified for CVV2 or has not provided encryption keys. Participation in CVV2/CVC2 is optional for issuers. The subscribing issuers submit their CVV2/CVC2 keys to Visa and MasterCard, and these keys are kept secret. The individual CVV2/CVC2 implementation policies of the tens of thousands of issuers are confidential, and issuers may change their internal CVV2/CVC2 policies without notification. Statistics are unavailable as to how many issuers subscribe (or don't subscribe) to CVV2/CVC2. Issuers may decide to return a "806" action code, indicating that a Visa issuer has declined a transaction due to the submission of an invalid CVV2 value. The 806 action code (a response allowed under Visa's association rules) enables issuers to independently decide a policy of rejecting transactions having invalid CVV2 values. An "806" action code may have a "N" or "U" or "P" response, but never an "M" response. Another factor that may affect CVV2 result codes is stand-in processing. When Visa or MasterCard performs stand-in processing for an issuer (because the issuer is otherwise unable to respond directly for a transaction), Visa/MC will perform the CVV2 calculation on behalf of any issuers who subscribe to CVV2.

24 Appendix D Valid SEC Codes (Consumer Applications) ARC - Accounts Receivable Entry CIE - Customer Initiated Entry MTE - Machine Transfer Entry PBR - Consumer Cross-Border Payment POP - Point-of-Purchase Entry POS - Point of Sale Entry SHR - Shared Network Transaction PPD - Prearranged Payment and Deposit Entry RCK - Re-presented Check Entry TEL - Telephone-Initiated Entry WEB - Internet-Initiated Entry (Corporate Applications) CBR - Corporate Cross-Border Payment CCD - Cash Concentration or Disbursement CTX - Corporate Trade Exchange (Other Applications) ACK - Acknowledgment Entries ATX - Acknowledgment Entries ADV - Automated Accounting Advice COR - Automated Notification of Change or Refused Notification of Change DNE - Death Notification Entry ENR - Automated Enrollment Entry RET - Return Entry TRC - Truncated Entries TRX - Truncated Entries XCK - Destroyed Check Entry For an explanation of these values see document at: End of Document - - -