CCVS Protocol Guide Version 3.3 Revised August 18, 2025 Red Hat, Inc. 2600 Meridian Pkwy Durham, NC 27713 919-547-0012 Back to main Documentation page   Table of Contents ETC PLUS (FDR7/ETC7/FDR "Omaha") -- First Data Corporation South Platform (FDR "Nabanco") -- First Data Corporation MAPP -- Global Payment Systems "St. Louis" NDC -- Global Payment Systems "Atlanta" / NDC VITAL (Visa 2nd generation, K format) -- Visa / Total System Services UTF -- Paymentech NOVA -- NOVA Information Systems   For information on the protocols in the CCVS Check Verification Module, see the Check Verification Module Guide. ETC PLUS (FDR7/ETC7/FDR Omaha) -- First Data Corporation ETC PLUS supports auth, sale, and return of transactions. If you use the same ETC+ merchant ID with more than one CCVS configuration, they must have different device IDs. If they share the same device ID, there will be a conflict at batch settlement time that might cause the batch to take as many as ten tries to settle successfully. All CCVS transactions will take advantage of "amount", "cardnum", "expdate", "track1", "track2", "address", and "zipcode" information if it's available. A credit card transaction must have an "amount", and must have either "track1", "track2", or "cardnum" and "expdate". If "address" or "zipcode" are provided, an AVS check will be performed. Since we do not yet directly support the use of magnetic track data with ETC+, any such data will be interpreted as if the card number and expiration date had been entered manually. ETC+ transactions will take advantage of "type" information if it is available. ETC+ transactions will pass the CCVS "invoice" through to the clearing house as the "invoice number". They will also pass "comment" data through to the clearing house as "company defined data". These might be useful when communicating with your merchant services organization. An ETC+ authorization transaction will have a "result_text" field once it has been processed. This will contain the human-readable text that the processor returns in the transaction response. In the case of a successful authorization, it will often include the authorization code. If the transaction attempted an AVS check, it will have an "avs" field, and will usually have "avs_zip" and "avs_addr" fields, indicating the success or failure of the AVS check. ETC+ sale and return transactions are processed as part of a batch. The individual results of the transactions will not contain much information beyond the simple success or failure of the operation. Furthermore, a single bad transaction in a settlement batch can cause the entire batch to fail. Since an ETC+ batch consists of up to 500 transactions, this means a bad settlement transaction can cause up to 499 otherwise-good transactions to be rejected by First Data. South Platform (FDR "Nabanco") -- First Data Corporation South Platform supports auth, sale, and return of transactions. All CCVS transactions will take advantage of "amount", "cardnum", "expdate", "track1", "track2", "address", and "zipcode" information if it's available. A credit card transaction must have an "amount", and must have either "track1", "track2", or "cardnum" and "expdate". If "address" or "zipcode" are provided, an AVS check will be performed. However, AVS is not available for JCB, Carte Blanche, and Diners Club charges. South Platform transactions will take advantage of "tax" and "purchaseorder" data if it is available. If you use these data types, you might obtain better rates. However, they are used only for Visa and Mastercard charges; other card types ignore them. South Platform transactions will take advantage of "type ecommerce", "encryption", "setmerchant", and "setcardholder" data if it is available. You can use CVV2 with South Platform for additional verification. This is done by adding "cvv2" data in the authorization transaction. If you obtain an authorization code from another source (for example by voice authorization), you can enter the authorization code into a new transaction and then perform a sale without first performing an auth. Magnetic stripe data is supported with South Platform. Any South Platform transaction will have a "result_text" field once it has been processed. This will contain the human-readable text that the processor returns in the transaction response. If the transaction attempted an AVS check, it will have an "avs" field, and will usually have "avs_zip" and "avs_addr" fields, indicating the success or failure of the AVS check. Similarly, if the transaction attempted a CVV2 check, it will have a "cvv2" field indicating the result. In addition, successful authorization transactions will have an "acode" field, containing the approval code (or authorization code) for the transaction. South Platform sale and return transactions are processed as part of a batch. The individual results of the transactions will not contain much information beyond the simple success or failure of the operation. Furthermore, a single bad transaction in a settlement batch can cause the entire batch to be rejected by the processor. MAPP -- Global Payment Systems "St. Louis" MAPP supports auth, sale, reverse, and return of transactions. MAPP transactions will pass the CCVS "invoice" through to the clearing house as the "reference number". They will also pass "comment" data through to the clearing house as the "order number". These might be useful when communicating with your merchant services organization. All CCVS transactions will take advantage of "amount", "cardnum", "expdate", "track1", "track2", "address", and "zipcode" information if it's available. A credit card transaction must have an "amount", and must have either "cardnum" and "expdate", "track1", or "track2". If "address" or "zipcode" are provided, an AVS check will be performed. MAPP service providers can treat duplicate transactions in a special way. You can configure the system so that transactions with the same account data and the exact same amount within the same period of time (usually a day) are considered duplicates, and only processed once. If you set things up this way, no error should cause a cardholder to be double-billed. If you don't set things up this way, a very rare error condition (we've never encountered it) could cause an individual transaction to be processed twice. If you obtain an authorization code from another source (for example by voice authorization), you can enter the authorization code into a new transaction and then perform a sale without first performing an auth. Magnetic stripe data is supported with MAPP. Any MAPP transaction will have a "result_text" field once it has been processed. This will contain the human-readable text that the processor returns in the transaction response. In the case of a successful authorization, it will often include the authorization code. If the transaction attempted an AVS check, it will have an "avs" field, and will usually have "avs_zip" and "avs_addr" fields, indicating the success or failure of the AVS check. In addition, successful authorization transactions will have an "acode" field, containing the approval code (or authorization code) for the transaction. MAPP settlement transactions are processed individually. A failure on one transaction should have no effect on any unrelated transaction. NDC -- Global Payment Systems "Atlanta" / NDC NDC supports auth, sale, and return of transactions. NDC transactions will pass the CCVS "invoice" through to the clearing house as "routing data", and sometimes as the "ticket number" or "purchase ID". This might be useful when communicating with your merchant services organization. NDC transactions will take advantage of "type", "entrysource", and "tax" data if it is available. If you use these data types, you might obtain better rates. It is particularly important to use a "type" of "retail" if you're operating in a face-to-face retail environment, or a "type" of "ecommerce" if you're conducting e-commerce transactions. If you are doing e-commerce, it's important to set "encryption" to "yes" if you're encrypting data between the cardholder and yourself. The "setmerchant" and "setcardholder" fields will also be used if they are available. All CCVS transactions will take advantage of "amount", "cardnum", "expdate", "track1", "track2", "address", and "zipcode" information if it's available. A credit card transaction must have an "amount", and must have either "cardnum" and "expdate", "track1", or "track2". If "address" or "zipcode" are provided, an AVS check will be performed. You can use CVV2 for additional verification. This is done by adding "cvv2" data in the authorization transaction. NDC has a special "AVS-only" transaction. To use this, perform an authorization with AVS data, but do not set the amount, or set the amount to zero. The result will tell you if the card data you entered is valid, and if the AVS check succeeds. This special transaction cannot be settled. NDC service providers can treat duplicate transactions in a special way. You can configure the system so that transactions with the same account data and the exact same amount within the same period of time (usually a day) are considered duplicates, and only processed once. If you set things up this way, no error should cause a cardholder to be double-billed. If you don't set things up this way, a very rare error condition (we've never encountered it) could cause an individual transaction to be processed twice. If you obtain an authorization code from another source (for example by voice authorization), you can enter the authorization code into a new transaction and then perform a sale without first performing an auth. Magnetic stripe data is supported with NDC. Any NDC transaction will have a "result_text" field once it has been processed. This will contain the human-readable text that the processor returns in the transaction response. If the transaction attempted an AVS check, it will have an "avs" field, and will usually have "avs_zip" and "avs_addr" fields, indicating the success or failure of the AVS check. In addition, successful authorization transactions will have an "acode" field, containing the approval code (or authorization code) for the transaction. NDC settlement transactions are processed individually. A failure on one transaction should have no effect on any unrelated transaction. VITAL (Visa 2nd generation, K format) -- Visa / Total System Services VITAL has an unusually long list of configuration values; these must be entered when you are installing and configuring CCVS. This information is determined by the bank that issued your merchant account. If you cannot find the answers to any of these questions, be aware that the bank can do a Print Screen in their Merchant Management System. VITAL supports auth, sale, reverse, and return of transactions. All CCVS transactions will take advantage of "amount", "cardnum", "expdate", "track1", "track2", "address", "zipcode", and "comment" information if it's available. (The "comment" is a 25-character purchase identifier.) A credit card transaction must have an "amount", and must have either "track1", "track2", or "cardnum" and "expdate". If "address" or "zipcode" are provided, an AVS check will be performed. VITAL transactions will take advantage of "tax" and "purchaseorder" data if it is available. If you use these data types, you might obtain better rates. VITAL transactions will take advantage of "type ecommerce", "encryption yes", "setmerchant", and "setcardholder" data if it is available. Any of these will be taken to indicate an e-commerce transaction. If you use "encryption yes", "setmerchant", or "setcardholder", the transaction will be reported as channel-encrypted e-commerce. (SET is not yet specifically supported, but it is reported as a form of encryption.) You can use CVV2 with VITAL for additional verification. This is done by adding "cvv2" data in the authorization transaction. If you obtain an authorization code from another source (for example by voice authorization), you can enter the authorization code into a new transaction and then perform a sale without first performing an auth. Magnetic stripe data is supported with VITAL. Any VITAL transaction will have a "result_text" field once it has been processed. This will contain the human-readable text that the processor returns in the transaction response. If the transaction attempted an AVS check, it will have an "avs" field, and will usually have "avs_zip" and "avs_addr" fields, indicating the success or failure of the AVS check. Similarly, if the transaction attempted a CVV2 check, it will have a "cvv2" field indicating the result. In addition, successful authorization transactions will have an "acode" field, containing the approval code (or authorization code) for the transaction. VITAL sale and return transactions are processed as part of a batch. The individual results of the transactions will not contain much information beyond the simple success or failure of the operation. Furthermore, a single bad transaction in a settlement batch can cause the entire batch to be rejected by the processor. However, as of CCVS 3.3, VITAL batch processing is somewhat improved. If CCVS can determine that a specific transaction is causing problems, it will move that transaction to the bad state and re-run the rest of the batch. Note that VITAL can only signal one bad transaction per upload attempt. If you have several bad transactions, CCVS will keep retrying the batch, dropping one transaction each time. This can take some time. However, given long enough, the process will eventually terminate, with every ready transaction changed to done or bad. If you have any problems with your merchant account, there is a VITAL help desk available by telephone, at 1-800-552-8227. You will have to have your "V-number" ready when you call -- this is an eight-digit number, which is not the same as either your merchant number or terminal ID. The V-number should be findable in your merchant account information. UTF -- Paymentech When your merchant account is set up, be sure it is configured for TCS (Terminal Capture System) and not HCS (Host Capture). See our certification letter. You should also know whether your account is configured as "retail" or "direct marketing"; you will have to enter this information when you configure CCVS. All CCVS transactions will take advantage of "amount", "cardnum", "expdate", "track1", "track2", "address", and "zipcode" information if it's available. A credit card transaction must have an "amount", and must have either "track1", "track2", or "cardnum" and "expdate". (You should not enter both "track1" and "track2" in Paymentech.) If "address" or "zipcode" are provided, an AVS check will be performed. When you create a transaction for Paymentech, you might specify the type of the transaction. This is done by giving (or leaving blank) the "type" argument type. In particular, if you are set up for direct marketing, you might get better rates if you mark recurring and installment transactions as "type recurring" and "type installment". However, we do not yet have purchase card support for Paymentech, so setting the "tax" field will not help your rates. Paymentech supports auth, sale, reverse, and return of transactions. However, reverse may only be used with Visa credit card numbers, and then only with mail or phone transactions. If your merchant account is configured as "direct marketing", Paymentech transactions will pass the CCVS "invoice" through to the clearing house as the "order number". This might be useful when communicating with your merchant services organization. If you obtain an authorization code from another source (for example by voice authorization), you can enter the authorization code into a new transaction and then perform a sale without first performing an auth. Magnetic stripe data is supported with Paymentech. Any Paymentech transaction will have a "result_text" field once it has been processed. This will contain the human-readable text that the processor returns in the transaction response. If the transaction attempted an AVS check, it will have an "avs" field, and will usually have "avs_zip" and "avs_addr" fields, indicating the success or failure of the AVS check. In addition, successful authorization transactions will have an "acode" field, containing the approval code (or authorization code) for the transaction. Batch Failures Paymentech sale and return transactions are processed as part of a batch. The individual results of the transactions will not contain much Information beyond the simple success or failure of the operation. Furthermore, a single bad transaction in a settlement batch can cause the entire batch to be rejected by the processor. When closing a batch, you might sometimes see the batch fail with a message like "CALL 8007821266 05". All the transactions will be in the bad state. If this occurs, the batch might have succeeded, or it might have been lost by Paymentech's server. (This is an exceptional case. Other bad-batch errors indicate that the batch was definitely rejected.) If you see the exceptional "CALL" error, you must call Paymentech and ask about the status of the batch. If Paymentech tells you that the batch was received properly, you should delete all the transactions. If Paymentech tells you that the batch must be sent again, you must use the CCVS command resend function with the given batch number. Using the cvcli tool, for example, you would enter command resend 5 to resend batch 5. In the C API, you would call cv_command(session, CV_CMD_RESEND, "5"); The command resend puts all the bad transactions from that batch back into the ready state. You must then run cvupload to actually upload them. Paymentech should then confirm that the batch has sent successfully. Troubleshooting If you have any problems with your merchant account, there is a Paymentech help desk available by telephone, at 1-800-254-9556. NOVA Information Systems You should know whether your account is configured as "general retail", "Internet order", or "direct marketing"; you will have to enter this information when you configure CCVS. NOVA supports auth, sale, and return of transactions. All CCVS transactions will take advantage of "amount", "cardnum", "expdate", "track1", "track2", "address", and "zipcode" information if it's available. A credit card transaction must have an "amount", and must have either "track1", "track2", or "cardnum" and "expdate". If "address" or "zipcode" are provided, an AVS check will be performed. NOVA transactions will take advantage of "tax" and "purchaseorder" data if it is available. If you use these data types, you might obtain better rates. NOVA transactions will pass the CCVS "invoice" through to the clearing house as the "ticket number" (custom data field). This might be useful when communicating with your merchant services organization. Magnetic stripe data is supported with NOVA. Any NOVA transaction will have a "result_text" field once it has been processed. This will contain the human-readable text that the processor returns in the transaction response. If the transaction attempted an AVS check, it will have an "avs" field, and will usually have "avs_zip" and "avs_addr" fields, indicating the success or failure of the AVS check. In addition, successful authorization transactions will have an "acode" field, containing the approval code (or authorization code) for the transaction. NOVA sale and return transactions are processed as part of a batch. The individual results of the transactions will not contain much information beyond the simple success or failure of the operation. Furthermore, a single bad transaction in a settlement batch can cause the entire batch to fail. Since a NOVA batch consists of up to 950 transactions, this means a bad settlement transaction can cause up to 949 otherwise-good transactions to be rejected by the processor. Revised August 18, 2025 Red Hat, Inc. 2600 Meridian Pkwy Durham, NC 27713 919-547-0012 Back to main Documentation page <.php3>