The Credit Card Verification System (CCVS) uses your computer and modem to simulate a credit card swipe box (also known as a Point of Sale [POS] terminal). A stand-alone product, CCVS includes several Application Programming Interfaces (APIs) that facilitate customization and integration with third party software applications or database products.
CCVS is safe, secure, and easy to use. Written in ANSI C and conforming to POSIX standards, CCVS is portable and designed to be easily integrated with modern operating systems, programming languages, and the Internet. Designed for easy scripting and programming, CCVS can be used to automate batch processing or enhance any application that requires credit card processing.
CCVS can be used in countries other than the US if your bank or merchant services representative can support one of the protocols supported by CCVS. If you're in Canada, CCVS supports the NDC protocol, which can be used by any bank in Canada to configure your merchant account. If you're in a country other than the US or Canada, you'll need to check with your merchant services representative. The protocol supported by CCVS that has the best chance of being supported by a financial institution outside the US is the the Visa 2nd Generation ``K Format'' protocol (VITAL).
A demonstration version of CCVS is included with Red Hat Linux. The demo version is fully functional and can be used for testing CCVS and your system; the demo version will do everything except contact your financial institution. If you choose to purchase CCVS to process credit cards, you'll need to contact Red Hat to purchase a license key. See http://www.redhat.com/products/ccvs/ for more information on how to activate CCVS.
Examples of how CCVS can be used (depending upon the protocol you're using — see www.redhat.com/products/ccvs/support/CCVS3.3docs/protocol-specific.html for more information on what different protocols will support):
CCVS can support a system for telephone operators taking catalog orders over the phone. CCVS' Tcl extensions can be used to create a Tcl/Tk Graphical User Interface (GUI) that presents a simple interface for telephone operators. The operators can then use simple X terminals; all the software will run on the central server. CCVS only needs to be installed on one computer, and the operators don't have to wait for an available phone line — all of their transactions will go out over the same phone call.
CCVS can be used to help automate billing. For example, an Internet Service Provider (ISP) might have a customer database on a database server. The ISP's database administrator could write a Perl script, combining the CCVS Perl module with a module for the ISP's database system. The script would then be run every month. The script will read the customer data, process monthly billing, and update the records in the database to indicate payment has taken place.
These are only two examples of CCVS capabilities. CCVS can be used to enhance any aspect of your operations that require credit card processing. CCVS' many features include the following:
A C library with a documented API empowers users to integrate CCVS seamlessly with existing applications.
A Tcl extension enables use of CCVS with server-side Tcl such as NeoWebScript.
A Perl 5.0 module allows CCVS to work with the most popular CGI programming language in use today.
The ability to quickly construct custom GUIs using Tcl/Tk — typical development time is less than a day.
Python, PHP3 and Java modules enable CCVS to work with other common programming languages.
Command Line Interface (CLI) programs for interactive use. Call programs from any UNIX shell and program in the UNIX language you like best.
AVS fraud protection, which allows merchants to check for stolen credit cards. Many clearinghouses offer a better rate to merchants who use AVS, even on orders taken over the phone.
Support for multiple merchant accounts, allowing users to open their very own virtual malls with unlimited store fronts. A "merchant account" is a special type of bank account which allows a business to accept credit card payments from customers; the merchant account holds the proceeds from credit card transactions.
The ability to conduct multiple transactions in a single session, approaching leased line performance (two seconds per transaction!) with no extra cost or complexity.
The reassurance of being able to test and do development programming on the product without charging real credit cards.
How does that little piece of plastic tell the nice people that you really can afford the big screen TV?
First, a consumer presents credit card information to the merchant. The merchant transmits this data, along with their merchant ID code, to a clearinghouse (also referred to as a processor or acquirer). The clearinghouse might be the bank that has issued the merchant their credit card account, but it is more likely a firm that has contracted with the merchant's bank to clear charges in exchange for a flat fee and a percentage of every charge processed.
The data is transmitted by reading the card and merchant numbers over the phone, by using a credit card POS terminal, or by using CCVS or some other piece of software to transmit the information from a computer.
The clearinghouse contacts the bank that issued the consumer's credit card and verifies that the charge is acceptable. If it is accepted, the clearinghouse then sends a confirmation message to the merchant. At the same time, the available credit from the customer's credit card is frozen by the amount of the transaction.
At the end of a business day, the merchant (actually, the merchant's computer or credit card terminal) calls the clearinghouse and verifies all transactions for that day to ensure that the merchant's system and the clearinghouse agree on the transactions that have occurred during that day. Once the merchant and the clearinghouse agree on the day's transactions, the clearinghouse starts the process of transferring the money from the credit card bank to the merchant's bank account.