Our Products » Software » Credit Cards etc.

Client Log-In
User-Name: »Clear
Forgot your Password?
Site Search
Upcoming Events

Cool Things available from Abacus 21
New Things from Abacus 21

Frequently Asked Questions



Adobe Reader Download

to Abacus 21's
Product Announcements 
Credit Card & eCommerce Transactional Processing

The following is collection of definitions and explanations that may be pertinent for those Clients interested in Credit Card, Debit Card, Lock Box, ACH, A/R Factoring, Gift Cards, Loyalty Cards, Direct Marketing & American Express settlement methods.

Click here for further information on EFT terminology:

Lock Box
A/R Factoring
Gift Cards
Loyalty Cards
Direct Marketing Merchant Settlement
American Express Direct Settlement
Debit Cards
Cardholder Information Security Program (CISP)
Transaction Processors
Card Encoding Specifications
Card Glossary
Credit Card Tokenization

Security Breach Stories (that make a case for PCI-compliance)

Lock Box

Lock Box processing is a means for Members to send in their Statement payments to a Bank Lock Box – which in turn provides a datafile of the received payments to the Club.


Abacus 21’s Lock Box system currently has two standard formats – which Banks are generally happy to accommodate.


Aside from Abacus 21’s Lock Box software application and the Bank’s compliance with one of Abacus 21’s Lock Box import file formats, no other 3rd-party software is necessary.  No setups within Membership are necessary.


The datafiles are exchanged electronically via email or via diskette or some other Bank file transfer process.  It is the Client's responsibility to create, schedule, transmit, receive, and post these files.


The Lock Box system prompts for the input file name (and path) and creates a Cash Receipts Batch – which the operator can edit and post.


A/R Factoring

This subsystem provides a means of Members to give the Club permission to submit their Statement Balances for Credit Card approval (typically once a month).  This is a two-way submission-approval process.


This application module requires the use of 3rd-Party Credit Card Processing software such as Shift4 or Protobase – and requires a separate Merchant ID (but probably uses the same singleTransaction Processor as the rest of the property’s operations).  An IP connection (faster) or Dial-Up modem (slower) are required – and, if implemented on a system that is also accommodating other credit card processing applications, a dedicated Credit Card Authorization Server (PC).


Depending on the Property’s policies and preferences, the A/R Factoring process is typically run before Statement are printed.  This batch process goes through the Membership files looking for Members who have A/R Factoring activated (this is triggered by have appropriate Member Credit Card information on file, and the Abacus 21 system has the capability of segregating certain types of charges to be included/excluded as well as being routed to different Credit Cards) and who have an outstanding account balance.  This creates a Credit Card Batch authorization request submission to the Transaction Processor.


The authorization approval results are electronically (immediately) received back and posted directly to a Cash Receipts Entry Batch -- for subsequent viewing, editing and posting to the Members’ respective A/R Accounts.  Approvals have the Authorization Reference imbedded into the A/R payment record.  Denials have the Reference noted in the A/R ($0.00) payment record.


Statements are then available to send out -- reflecting the results of the A/R Factoring Credit Card payment-rejection applications.

ACH (Automatic Clearing House)


This subsystem provides a means of Members to give the Club permission to submit their Statement Balances for Checking Account approval (typically once a month).

The setups for Abacus 21's ACH System will provide for the definition of each Member-Client's Routing Number, Account Number, and declaration regarding Check or Savings Account.

Abacus 21's ACH System will allow for submission on a specific day/date (in the month following the live transactions into A/R) -- creating a batch file of outstanding balances of all Members-Clients who have agreed to this method of payment (providing for the ABA Company ID, Band and State, and Transaction Description to appear on the Member Statement.

Depending on the Club’s policies and preferences, the ACH process is typically run before Statement are printed; in some Client deployments it is run a certain number of days before/after Statements are sent out.  This batch process goes through the Membership files looking for Members who have ACH activated (this is triggered by have appropriate Member Checking Account information on file, and the Abacus 21 system has the capability of segregating certain types of charges to be included/excluded as well as being routed to different Credit Cards and who have an outstanding account balance.  This creates a ACH Batch authorization request submission export file – one that complies with the NACHA standards.  Simultaneously, this process creates a Cash Receipts Entry Batch – (typically) assuming all submissions will be viewed, approved, and posted.

Statements are then available to send out -- reflecting the results of the A/R Factoring Credit Card payment-rejection applications.  Corrections or adjustments have to be made with A/R Debit Memos or (negative) Cash Receipts.

Depending on the Bank's ability to electronically respond with approval-denial information this is either a one-way or two-way interaction.

  • In a one-way scenario, the submission of Checking Account Approval posting batch assumes the ‘approval’ of all requests – there is no electronic return acknowledgement... and any discrepancies must be adjusted manually via A/R Debit Memos or Cash Receipts.
  • In a two-way scenario, upon the return from the Bank (oftentime of just the 'denials'), a negative-entry is made to Cash Receipts (or to the Batch if it has not yet been internally posted to Accounts Receivable).

Gift Cards


This is the 'electronic version' of Gift Certificates -- which are issued (for a particular dollar amount -- perhaps noting who purchased it and perhaps noting who it was purchased for and perhaps with an expiration date) and can be redeemed (or replenished) depending upon the 'rules' associated with the type of Gift Card.

In addition to Abacus 21's own Gift Card solution, we also offer interface to Shift4's "It's-Your-Card" and Shift4's Intefaces with Nova, Paymentech, Datamark, and Givex Gift Card solutions.  Our customers can now utilize their $$$-on-the-Net solution to process gift cards from any of these solutions simply by purchasing an It's-Your-Card interface license.

Please note that these interfaces are limited by the functionality provided by Nova, Paymentech, Datamark or Givex. That is, these interfaces will allow customers to continue to utilize all the features offered by these gift card solutions, but will not include the full feature suite available with Shift4's own It's-Your-Card solution.

Loyalty Cards


This is a method of accumulating 'points' or 'value' for a Customer's repeat patronage at your establishment(s).  These can be separate Loyalty Cards -- or the 'loyalty' accumulation can be 'attached' to other Cards (such as a Membership Card)... or merely associated with some unique Customer identifier.  Subject to the 'rules of the Loyalty Program', the point-value of the Card can be redeemed at an establishment for qualifying Merchandise.

Direct Marketing Merchant Settlement


Credit Card Processing Companies (and Banks) are beginning to impose new "crackdowns" on "card not present transactions".  Merchants using 'settlement formats' other than Direct Marketing or formats that do not include AVS (Address Verification Service) data, which is not currently used in Retail, could risk facing financial penalties (higher per transaction charges) -- and if the case were extreme enough, their Account could even be suspended with the Processor, due to risks of fraud, etc.
Also, if a Sales Outlet will be taking phone or Internet orders, then they would want to use the Direct Marketing Merchant for those transactions and a Retail Merchant for the rest.  However, if they will occasionally get transactions without swipe data due to cards not being able to be read, they would want to use the Retail Merchant.  Most of the issue is that Direct Marketing requires the Billing Address, Cardholder Name, and other data to be entered that may not be feasible to ask Customers for each time that a Credit Card is used.

Abacus 21 has add-on extensions to its Credit Card Settlement offerings to accommodate these types of situations.  Contact us for further information.

American Express Direct Settlement

Abacus 21 supports this method of tenderment -- mixed with other Transaction Processors or used as the sole Processor.

Debit Cards

Abacus 21 (via its Shift4 partner) has certification on the Fifth Third Bank Processing Solutions platform.  Firth Third Bank is the leading web-based e-payment gateway solution with real-time electronic payment authorization, settlement, reporting, and fraud control capabilities.

This certification allows support of both on-line debit (PINned) and off-line debit ('check card' transactions, where the debit card is treated like a credit card and requires a signature but no PIN).  The debit PIN pad machines are connected via Shift4's Universal Transaction Gateway (UTG), which is also used to support Signature Capture and Check Verification.  Soon we will have an interface to Fifth Third's Gift Card system.

In addition to Fifth Third, Abacus 21's tool Shift4 has certified Debit Processing interfaces with First Data Merchant Services (FDC), Global Payment Services (formerly NDC) and Vital Processing Services.  Additionally, credit card processing interfaces are in place with over 99% of today's leading financial institutions, including American Express, Paymentech, Nova Information Systems, Chase Merchant Services, First Horizon Merchant Services and Planet Payment, with new interfaces being added regularly.

Cardholder Information Security Program (CISP)

In June 2001, VISA USA implemented its Cardholder Information Security Program (CISP). This program is designed to ensure that merchants and service providers alike protect cardholder information from unauthorized access. The VISA CISP Program applies to both electronic and non-electronic means of storing, maintaining and transmitting such data. VISA has outlined several different security policies for merchants and service providers. Failure to comply may result in fines assessed.

Abacus 21 utilizes Shift4 Corporation's $$$-on-the-Net as its principal eCommerce authorization mechanism -- and in that regard, we are pleased to announce that Shift4 is among the select few solution providers to have been recognized by Visa U.S.A. as fully compliant with their Cardholder Information Security Program (CISP) requirements.  This is the latest step in our continuing efforts to provide our Customers with the highest level of financial transaction and data security.

Shift4's $$$-On-The-Net® solution is the leading web-based enterprise payment processing solution available today.

With Shift4, Abacus 21 offers a complete enterprise solution, from US and Canadian debit, foreign currency transactions, signature capture, and check verification.  These solutions are Bank and Processor neutral.  $$$-on-the-Net maintains a centralized database of all transactions from across the enterprise.  Users can audit and edit these tranactions before settlement, as well as access them for up to 24 months for detailed reporting or to combat charge back requests.

  • A Merchant who goes directly to a Processor loses the flexibility that a gateway solution, such as $$$-on-the-Net, provides. The Merchant becomes tied to a specific processor -- which means they must use this processor regardless of rate changes, service issues, etc.  Once a Merchant is locked into a Processor, they lose a lot of leverage and Processors can and will take advantage of that.

  • Without middleware like Shift4's $$$-on-the-Net, there is also no ability to audit transactions prior to settlement in order to minimize credits and shorten month end reconciliation times.  There is no searchable transaction database to help guard against charge backs.  Instead, the Merchant has to rely on the Processor to find and retrieve charge back transaction data, a process for which the Processor frequently charges a fee.  It becomes the Merchant's responsibility alone to work with the Processor to ensure that the proper data in the proper format is collected and to generally be his or her own credit card advocate.

  • An important addition to this is the potential issues that exist using a gateway that is owned by a Processor.  A gateway's job is to help minimize downgrades and optimize payment processing.  A processor, however, makes more money the more omissions or errors that occur.  For instance, if a customer's gateway is down, they have to call the Processor for a voice referral.  For each voice referral, the Processor charges over $1.00.  If that gateway is owned by a Processor  do they have the same incentive to fix the issue quickly?  If the gateway is owned by a Processor are they truly the customer's advocate? It's hard to say for sure, but they certainly are far from unbiased.

  • Shift4 helps combat both external and internal fraud.  To protect against customer fraud, Shift4 offers Address Verification Services (AVS) and full support of CVV2, CVC2 and CID codes (the three or four digit numbers located on the physical credit card).  Historically, AVS and CVV2 were used only for ‘card not present' transactions, such as those on e-commerce sites or through mail order.  Visa's VIP program, however, has extended the advantages of these tools to Merchants of all types.  Running these verifications can help guard against the use of stolen cards and can be particularly beneficial for establishments with larger ticket averages -- and for any company running a tab or open authorization (hotels, bars, auto rental, etc.)

  • To combat internal fraud, $$$-on-the-Net includes the powerful ‘trusted' employee fraud detection and prevention tool, Fraud Sentry®. There are many types of internal credit card fraud, the most common of which involves the practice of corrupt employees issuing false or over-stated credits to their own card(s) or to those of their cohort.

  • Prior to settlement, Fraud Sentry scans through a company's transaction archive, searching for a matching debit charge or series of debit charges that correspond to each credit transaction.  If a valid match is not found or if the credit exceeds the charge(s), the suspect credit transaction is flagged and reported to the auditor.  But Fraud Sentry goes even beyond this, offering you a variety of ways to analyze trends that may signal there are fraudulent activities.

  • Within the Fraud Sentry settings screen on $$$-on-the-Net, customers have the ability to control the ‘velocity' settings.  Basically, a controller is able to request that Fraud Sentry track and report a variety of different trends by setting their own threshold tolerances.  For example, a controller may want to know if a card was used over a certain number of times in a day, week, or month... or whether the total purchases for a card exceeded a certain amount in any given timeframe, or even whether the total number or price of credits for a single card exceed the threshold.  This type of trend analysis capabilities allow Merchants to uncover even the most advanced fraud.

$$$-On-The-Net is up and running all day, every day, in every time zone in the world.  And, for over a year and a half, $$$-On-The-Net has performed at or above 99.99% availability. The only system downtime during this period: a scheduled 3-hour window during which Shift4 brought live its new state-of-the-art -- a data center that was designed to improve our already industry-leading system reliability and processing times.

Plus, Shift4 has a second data center, with an even larger load capacity, going on-line later this year. Over the last three years, Shift4's $$$-on-the-Net solution has enjoyed 99.9986% uptime; that's less than three hours of downtime in the last three years.  (Incidentally, Shift4 proceeded over $1 Billion worth of transactions in March 2005.)

Because of Shift4's highest level of compliance with Card Association regulations for transactions, 'downgrades' are minimized.

Note on Utilization of Dial-Up Phone Line with Shift4:

  • Adding an internet connection these days can be very easy and cost-effective, often less than another telephone line or a terminal rental.  However, while Shift4 does recommend that merchants utilize high-speed Internet access because of the improved performance, $$$-on-the-Net can be used and is being used quite successfully by merchants with a dial-up Internet or even satellite connections. Merchants with a large volume of transactions, however, should utilize a high speed connection.

  • Such use is only advisable for lower-volume or emergency backup purposes.  Security features in $$$-on-the-Net require the system to remain on the same trusted TCP/IP address. If this address changes (and since almost all dial up Internet service providers use DHCP, the chances of that are quite good) it will trigger a security feature that must be cleared by our development staff before credit card processing can resume. Ideally, a $$$-on-the-Net system should be on a corporate network connection or other broadband connection such as cable modem or DSL with a static TCP/IP address.

  • For broadband connections greater than T1/DS1 it is usually possible to obtain an ISDN backup device included with the ISP supplied router system. This will normally allow the same IP address ranges to be used, but will protect from broadband failures. The bottom line is that if you are uncomfortable with the Service Level Agreement (SLA) of your particular ISP, please get another ISP. You wouldn't choose a phone company that did not supply you with dial tone whenever you needed to make a call. Your Internet Service Provider should be no different.

  • In addition, it is very difficult to create an "it works in all environments" dial backup solution. The reason for this is because of the many different ways hardware and software solutions connect to the Internet and the myriad of ways they can interact with a customer's LAN/WAN environment.
  • Under no circumstances should Shift4 software be used on a PC with America Online installed. AOL has been known to interfere with Shift4 software to the point re-installation may become necessary.

Transaction Processors -

Click for a list of Shift4 approved Transaction Processors.

For those Clients using our Southern DataComm (SDC Protobase, a Service Provider and VISA Vendor) solution, SDC has provided software products and services to the card acceptance industry since 1985.  Their commitment to cardholder and merchant security has always been our highest priority since the inception of our offerings. Their software products and services are designed to meet and exceed that of industry data security standards. We are currently working closely with VISA to ensure that our Company, Products and Services are CISP compliant.

SDC has already taken many steps to ensure that transactions processed through the ProtoBase® and PbAdmin® software applications are secure*. Some enhanced security features include:

  • Database Encryption
  • Credit Card Masking
  • User Security
  • Audit Logs
SDC's high-speed Internet gateway, ProtoBase eXpressTM Service, has been designed and implemented with the highest network security offerings on the market today. All transactions that are processed over the Internet through our network are encrypted using 3DES (Data Encryption Standard) technology.

Overall Southern DataComm is preparing in many different ways for becoming CISP compliant.  We advocate and endorse VISA's efforts in promoting security policies that will provide a high confidence level felt by merchants and consumers alike.

For more information on the VISA Cardholder Information Security Program please visit www.visa.com/cisp.

* ProtoBase versions 4.82 and higher; PbAdmin versions 5.01 and higher

Card Encoding Specifications

Proceed to this page to get a description of Magnetic Strip Encoding Standards.

Credit Card Tokenization

To abide by the Card Association's current requirement of not storing credit card data, Abacus 21 has adopted Shift4's new Tokenization technology -- which enables its Clubs, Resorts, and Other Merchant Clients to enjoy the highest level of payment processing security possible without requiring a lot of time, money or resources.

During the recent Transaction Security Summit held September 28-29, 2005 in Las Vegas, one thing became abundantly clear:  In order for Merchants, POS, and Property Management systems to be secure and pass their certification or validation process, they cannot hold any credit card data after the initial authorization.  In fact, in the Card Association's new universal security standard it states:

"Keep cardholder information storage to a minimum. Develop a data retention and disposal policy. Limit your storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy. Do not store sensitive authentication data subsequent to authorization (not even if encrypted)." - Payment Card Industry Data Security Standards (PCI DSS), as seen on www.visa.com/cisp

The problem is that this information has been historically stored and utilized to enable merchants to perform incremental authorizations on a credit card.  For example, this information is used to process tips and tabs in a restaurant environment, enable recurring billing for retail and ecommerce merchants, and is essential to lodging and auto rental merchants who charge multiple items, nights, etc. to a single invoice.  Abacus 21 (with its Shift4 integration) has provided a system so that the Client merchant can leverage the same features without the security risk -- utilizing technology that is called Tokenization.

The following is a description of how Tokenization works.  The purchase starts off the same.  The merchant swipes the card data and Abacus 21's POS or PMS or A/R Factoring systems sent it over to Shift4 fully encrypted. Shift4 sends the card data on to the processor and receives back from the processor an approval.  All this is the same as it is today; it is after this point where the process differs.  Instead of sending back the card data to the Merchant and the POS system, Shift4 turns the data into a Token.  A Token is a globally unique, randomized representation of credit card data that is 16 characters long.  For Abacus 21 systems that utilize Shift4, only the Token is stored in the system.

The Token spans the lifetime of the transaction, even into history, so it provides all the same support for Tips, Tabs, and incremental authorizations.  Basically, the Token is stored in Abacus 21's POS, PMS, or Membership system -- and, when an incremental authorization is required on the card, the Token is sent to Shift4.  The Token represents a specific Credit Card transaction and card data that is stored in Shift4's data center.  When the Token is sent through, Shift4 translates that Token into the card data and sends it to the processor.  The processor sends back the authorization code; Shift4 turns it back into a Token and sends that along with the approval code to the Abacus 21 System(s).  The authorization goes through and again no Credit Card data is stored on the system.  That means that the merchant doesn't need the card number or data past the initial request, so there is absolutely no reason to store this potentially dangerous information.

In summary, this is how it works:

  • For Point-of-Sale Transactions:
    • The Token represents a specific Credit Card transaction and card data that is stored in Shift4's data center.
  •  For A/R Factoring:
    • The first time that a card is entered into the System for A/R Factoring, Abacus sends the Card Number, Expiration Date, CCV data, amount, etc. 
    • After the card is processed, Shift4 would return a "token" to the Abacus system
    • The Token is a 16-character field that is stored in the Abacus system in place of the Credit Card Number.
    • The token contains the following format:  Last 4 digits of the Card Number -plus Token Information.
    • When printing the token for reference, the Abacus system masks the token information and displays the first 4-digits of the Token (ie, the last 4 digeits of the Credit Card number).
    • A Token is stored in Shiftt's database for 24 months; however, anytime a Token is sent to be processed (as would be th case with A/R Factoring, Shift4 would return an updated Token to stored in the Abacus system.

The entire liability to protect the card data is now on the gateway, where it should be.  The Shift4 gateway which Abacus 21 incorporates, $$$-on-the-Net®, has been successfully and securely managing, transporting and storing data for years.  It is something that is core to Abacus 21's & Shift4's success, but very much out of the realm of the core competencies of merchants and payment applications.  The redundant Shift4 data centers are fully compliant with all Card Association regulations, including the Payment Card Industry Data Security Standards.  To maintain this compliance, Shift4 undergoes a rigorous annual onsite audit, as well as ongoing network scans, all of which help to assure our customers and our partners that our systems, solutions and data centers are the most secure possible.  In fact, the security that Shift4 implements meets or surpasses that used by the US ATM networks and that outlined in the National Security Administration's (NSA) C2 Orange Book security standards requirement.


All material ©2020 Abacus 21, Inc. All Rights Reserved.