Integrated Credit Card System

IS4C has been certified for integrated credit card processing with First Data/Concord. In the integrated process IS4C acts as a conduit whereby credit card information is forwarded directly from the IS4C terminal to Concord, and no credit data is stored in the system. The version certified is the one used at the Wedge Co-op, which runs on Windows still. We hope to reconcile the Wedge version with the Linux version and apply for re-certification so that the Linux version can also handle integrated credit card transactions in the very near future. Certification, however, does involve certain security standards being adhered to at the sites involved, and that will have to be assessed on a site by site basis. For co-ops who are interested, we'll have to work with you individually.

The IS4C code that handles direct credit card transactions is in large part written by Alex Frase at the Wedge. Below is his front end demo.

Integrated Credit Cards Demo

Alex Frase

Tendering a credit card with the integrated system starts just like using cash: we have a transaction with some amount due, and we need to tell IS4C how the customer is paying for it. We can input the credit card information in one of two ways.

Ideally, we have a magnetic card reader attached to the lane, and we can simply swipe the credit card through it. This will read all the data from the card's magnetic stripe as if it were typed at the keyboard, so it will appear in our input box; most card readers will also append a carriage return, so it will be submitted immediately, but this is what it looks like just before that happens:

IS4C will know this is data from a credit card's magnetic stripe because of the "?" at the end, which is required for all standard credit cards. However, if the lane doesn't have a reader or if the stripe can't be read properly (which is not uncommon for older, worn out cards), you can enter the information manually: card number first, then the two digit expiration month, then the two digit expiration year, and then the tag "CC".

IS4C will do some simple checking of credit card data before it tries to submit it, which will catch most data entry errors without spending time waiting for the credit card processor to catch them.

First, IS4C checks that the card number is valid by verifying its check digit (which works very much like a barcode's check digit)
Next, it determines who issued the card (by looking at the beginning of the card number) to decide if the store can accept it (for example, the Wedge does not accept American Express)
Finally, it looks at the expiration date to make sure the month is valid (1-12) and that the card hasn't expired yet

Problems with any of this card data are reported like so:

If all is well, IS4C verifies the amount that should be charged to the card. By default, this will be the total amount due for the transaction, but if for some reason the customer only wants to charge a certain amount, it can be entered (in cents, just like cash tender) in the input box. In this example, the customer owes $6.49, but is only putting $5.00 on their card (entered as "500"):

Now comes the fun part. For the cashier, it's simply a matter of waiting a few seconds for the system to process the request and come back with a response:

Of course, behind the scenes a lot is going on. IS4C must first assemble a request to send to the credit card processor. This request must include data from the card itself (whether swiped or manually entered), information about the type of request (an authorize-and-settle with a certain amount), and information about who we are (a merchant number, to make sure the funds go into the right account). Then, IS4C has to open a connection to the web server that Concord uses to process these requests, send its packet of data, and wait for a response. When the response comes back, it must be decoded to extract the relevant information, so IS4C can tell the cashier what happened and make any changes to the transaction (such as crediting the amount tendered). Throughout all of this, logs are kept of what information was sent and received, so that we can go back later and spot any problems or identify the outcome of individual card transactions.

It is important to note that the full credit card number and its expiration date are NEVER stored in any permenant place by IS4C; after they are compiled into the request for the processor (which is encrypted during transmission using the HTTPS protocol), the "card identifying information" is discarded, in order to comply with industry regulations.

Despite all the activity, it usually takes less than 4 seconds to process a credit card. If everything goes well, the request is approved and IS4C automatically prints a receipt for the customer to sign and the cashier to put in the cash drawer.

The amount charged is then credited to the transaction, and we're back at the familiar screen, with only $1.49 left to be paid by some other means.

Of course, the real world is frought with perils, and so things don't always go so smoothly. If there is some problem with the request, IS4C will do its best to recover and report the problem.

Although unlikely, sometimes IS4C may detect an internal problem and not be able to prepare or send the request at all: In this case, the cashier can try again since nothing has been sent yet, but it is often a sign of a general system problem that IT will have to repair.

If the charge request is sent but times out (that is, we do not receive any reply from the processor within the period we're willing to wait), the first option provided by our credit card processor is to send a cancellation, just in case the original request actually did go through and was approved. IS4C will do this automatically, and if the cancellation is successful, we can safely run the card again:

If the problem is worse, however, the cancellation might not go through either. In this case we have no way of knowing whether the original charge was successful, so we cannot try again without risking double-charging the customer. IS4C then instructs the cashier to make a copy of the card so it can be charged later, only if the original request was not actually successful:

If there aren't any technical problems communicating with the card processor, the most common error is simply a decline, meaning the credit card was not approved for the amount requested, for any of a variety of reasons. According to credit card industry regulations, the reason for a decline cannot be indicated to the cardholder, so IS4C reports any decline as such:

There are a handful of other error conditions that IS4C knows about and will generate appropriate error messages for, but in practice they almost never happen. Suffice to say that IS4C will always instruct the cashier according to the best of its knowledge, in order to minimize the worst dangers: failing to get any payment at all for a transaction, or overcharging a customer.

If there is any problem processing the credit card, no amount will be credited to the transaction, but a $0.00 line item will be inserted anyway. This is partly to remind the cashier and customer that a card was run (even though it was unsuccessful), and partly to allow for unique numbering of all credit card processing requests.

Integrated Credit Cards IS4C has been certified for integrated credit card processing with First Data/Concord. In the integrated process IS4C acts as a conduit whereby credit card information is forwarded directly from the IS4C terminal to Concord, and no credit data is stored in the system. The version certified is the one used at the Wedge Co-op, which runs on Windows still. We hope to reconcile the Wedge version with the Linux version and apply for re-certification so that the Linux version can also handle integrated credit card transactions in the very near future. Certification, however, does involve certain security standards being adhered to at the sites involved, and that will have to be assessed on a site by site basis. For co-ops who are interested, we'll have to work with you individually. The IS4C code that handles direct credit card transactions is in large part written by Alex Frase at the Wedge. Below is his front end demo. Integrated Credit Cards Demo Alex Frase Tendering a credit card with the integrated system starts just like using cash: we have a transaction with some amount due, and we need to tell IS4C how the customer is paying for it. We can input the credit card information in one of two ways. Ideally, we have a magnetic card reader attached to the lane, and we can simply swipe the credit card through it. This will read all the data from the card's magnetic stripe as if it were typed at the keyboard, so it will appear in our input box; most card readers will also append a carriage return, so it will be submitted immediately, but this is what it looks like just before that happens: IS4C will know this is data from a credit card's magnetic stripe because of the "?" at the end, which is required for all standard credit cards. However, if the lane doesn't have a reader or if the stripe can't be read properly (which is not uncommon for older, worn out cards), you can enter the information manually: card number first, then the two digit expiration month, then the two digit expiration year, and then the tag "CC". IS4C will do some simple checking of credit card data before it tries to submit it, which will catch most data entry errors without spending time waiting for the credit card processor to catch them. First, IS4C checks that the card number is valid by verifying its check digit (which works very much like a barcode's check digit) Next, it determines who issued the card (by looking at the beginning of the card number) to decide if the store can accept it (for example, the Wedge does not accept American Express) Finally, it looks at the expiration date to make sure the month is valid (1-12) and that the card hasn't expired yet Problems with any of this card data are reported like so: If all is well, IS4C verifies the amount that should be charged to the card. By default, this will be the total amount due for the transaction, but if for some reason the customer only wants to charge a certain amount, it can be entered (in cents, just like cash tender) in the input box. In this example, the customer owes $6.49, but is only putting $5.00 on their card (entered as "500"): Now comes the fun part. For the cashier, it's simply a matter of waiting a few seconds for the system to process the request and come back with a response: Of course, behind the scenes a lot is going on. IS4C must first assemble a request to send to the credit card processor. This request must include data from the card itself (whether swiped or manually entered), information about the type of request (an authorize-and-settle with a certain amount), and information about who we are (a merchant number, to make sure the funds go into the right account). Then, IS4C has to open a connection to the web server that Concord uses to process these requests, send its packet of data, and wait for a response. When the response comes back, it must be decoded to extract the relevant information, so IS4C can tell the cashier what happened and make any changes to the transaction (such as crediting the amount tendered). Throughout all of this, logs are kept of what information was sent and received, so that we can go back later and spot any problems or identify the outcome of individual card transactions. It is important to note that the full credit card number and its expiration date are NEVER stored in any permenant place by IS4C; after they are compiled into the request for the processor (which is encrypted during transmission using the HTTPS protocol), the "card identifying information" is discarded, in order to comply with industry regulations. Despite all the activity, it usually takes less than 4 seconds to process a credit card. If everything goes well, the request is approved and IS4C automatically prints a receipt for the customer to sign and the cashier to put in the cash drawer. The amount charged is then credited to the transaction, and we're back at the familiar screen, with only $1.49 left to be paid by some other means. Of course, the real world is frought with perils, and so things don't always go so smoothly. If there is some problem with the request, IS4C will do its best to recover and report the problem. Although unlikely, sometimes IS4C may detect an internal problem and not be able to prepare or send the request at all: In this case, the cashier can try again since nothing has been sent yet, but it is often a sign of a general system problem that IT will have to repair. If the charge request is sent but times out (that is, we do not receive any reply from the processor within the period we're willing to wait), the first option provided by our credit card processor is to send a cancellation, just in case the original request actually did go through and was approved. IS4C will do this automatically, and if the cancellation is successful, we can safely run the card again: If the problem is worse, however, the cancellation might not go through either. In this case we have no way of knowing whether the original charge was successful, so we cannot try again without risking double-charging the customer. IS4C then instructs the cashier to make a copy of the card so it can be charged later, only if the original request was not actually successful: If there aren't any technical problems communicating with the card processor, the most common error is simply a decline, meaning the credit card was not approved for the amount requested, for any of a variety of reasons. According to credit card industry regulations, the reason for a decline cannot be indicated to the cardholder, so IS4C reports any decline as such: There are a handful of other error conditions that IS4C knows about and will generate appropriate error messages for, but in practice they almost never happen. Suffice to say that IS4C will always instruct the cashier according to the best of its knowledge, in order to minimize the worst dangers: failing to get any payment at all for a transaction, or overcharging a customer. If there is any problem processing the credit card, no amount will be credited to the transaction, but a $0.00 line item will be inserted anyway. This is partly to remind the cashier and customer that a card was run (even though it was unsuccessful), and partly to allow for unique numbering of all credit card processing requests.