;uA White Paper about security, and reducing the charges a merchant pays for credit card processing, as it affects users of the IBM Midrange System i, iSeries and AS/400.
Acceptance of debit and credit cards is a growing requirement for businesses of all sizes. Our focus here is on merchants accepting payment cards who base their operations on the IBM AS/400, iSeries, and now, System i.
Since 2005, the Payment Card Industry Security Standards Council (PCI) has imposed strict mandates, the Data Security Standards (DSS), to insure the security of the computer systems that PROCESS, TRANSMIT, and/or STORE sensitive credit card data.
Every business that accepts card data in any way is subject to the requirements of the PCI DSS, and the compliance ranges widely based on transaction volume, type of business, handling of the card data, and software applications. At the top end, a company could be required to have a third-party Qualified Security Auditor (QSA) who has been certified by the PCI, to perform an on-site, extensive analysis of your operation and systems. Another challenge is to find auditors who are familiar with the strengths of the IBM iSeries AS/400. The cost of these expensive and time consuming audits can be controlled by partnering with an experienced organization with appropriate expertise.
Meeting these ever-intensifying PCI DSS mandates poses unique challenges to companies whose main business system is the IBM Midrange AS/400, System i.
Some aspects of compliance are as simple as NEVER storing magnetic stripe data or the security code. Others are time consuming, like documenting every piece of infrastructure hardware, its firmware revision and last update, the fact that all default passwords have been changed, and documenting the use of SSL-secured communications between all of the workstations and central computers.
Other benefits of choosing the right partner to assist with your payment processing should include their ability to minimize downgrades that result in additional processing fees. Downgrades include field-related issues like missing data:
— Billing street address
— Billing ZIP
— Invoice number
— Destination ZIP code
— Tax flag
— Tax amount
— Customer PO number
Downgrades are also levied for Settlement issues like:
— Settlement more than 1 day after authorization
— Settlement more than 3 days after authorization
— Settlement more than 7-10 days after authorization
— Settlement for an amount different than what was authorized
With the proper guidance and procedures, a merchant, like you, can also be prepared to more effectively combat chargebacks that result in loss of payment, as well as the corresponding goods and/or services.
Here at Curbstone, we will, as the ideal partner:
— Allow you to maintain EXISTING banking relationships
— Not charge additional processing fees per transaction
— Provide technology that can completely remove your systems from PCI DSS scope
— Support ALL major networks so you can obtain competitive processing quotes
— Support changing transparently from one bank/network to another, if needed
— Have a decades-long track record of success on your chosen computing platform
— Provide UNLIMITED technical and operational support every day of the year
Table of Contents
According to Raymond Keating, Chief Economist for the Small Business and Entrepreneurship Council, most businesses reap tremendous benefits from the expansion and use of credit cards in our economy. Among the key beneficiaries of expanded credit usage are the many small/medium (SMB) businesses. These benefits range from payment cards being an important source of financing for SMB and to payment cards allowing for a vast expansion of the market for goods and services produced by SMB.
The most recent National Small Business Association, NSBA, survey revealed in 2012 that Credit Cards are a key financing resource for SMBs.
Indeed, payment cards have proven their value in many ways.
— Payment cards have increased traditional and e-commerce sales for SMBs
— Provide guaranteed payments for goods and services
— Eliminate major costs such as the costs for offering lines of in-house credit, billing and collection costs and additional customer service costs
— Enhance efficiency by streamlining the order lifecycle of 1) merchandising and conversion, 2) fulfillment and service and 3) collection and reconciliation
— Improve security by eliminating or reducing the handling of cash and checks
FIRST, current processes can waste money .
Many older products do not pass the required data to your acquirer, causing extra charges for those missing fields. Curbstone will work with you to pass all of the needed fields to ensure that you get the best processing rate from your acquirer/bank. Minimizing fraudulent transactions is another great way to save money, and Curbstone supports all of the industry standards.
SECOND, current processing is costing time.
You may involve a large number of manual tasks in authorizing and then settling transactions for payment. With Curbstone Card, these tasks are automatic in conjunction with orders in your ERP system or web-based cart. Customers have reduced order processing time by 35%! Successful auths can drive the picking or shipping process to insure you will be paid for that order. Cardholder information is stored in the secure Curbstone Card database for returning customers or recurring billing, speeding the order entry process.
THIRD , all companies that store, process or transmit cardholder data must comply with the PCI Data Security Standards and use a formally validated payment application. Curbstone Card is PCI-validated and was selected by IBM for their Developers' RoadAtlas for the Power System. Older payment applications that are not a validated payment application expose the merchant to significant risks - fines, lost revenues and liability. In fact, many merchants are already being charged a non-compliance fee by their acquirer/bank.
The term "Merchant" is typically describes the business selling a product or service and accepting cards as payment. If your company accepts cards in payment, you are the Merchant!
An acquirer (or acquiring bank) is a federally-chartered banking organization that may or may not have brick and mortar branches. Acquirers range from your local corner bank, to huge organizations that do nothing but acquire, like TSYS, First Data, or Paymentech. These banks MAY be aligned with a well-known retail bank, like Paymentech with Chase, or be independent like TSYS. Many of the small neighborhood banks resell the acquirer services from these Tier 1 acquirers, though that may not be clear to the merchant.
Short List of Major Acquirers in the US
— First Data Corporation (First Data Merchant Services: FDMS)
o FDC includes CardService International, Wells Fargo, PNC Merchant Services, SunTrust Merchant Services, and Citi Merchant Services
— Chase Paymentech (Chase Merchant Services)
— Bank of America Merchant Services (BAMS)
— American Express (through their Centurion Bank)
— Fifth Third Bank
— Heartland Payment Systems
— First national Merchant Solutions (FNMS)
— Global Payments
This short list accounts for about 90% of all the card transactions in the US. The rest of the acquirers are small, very specialized organizations.
Many companies, who are not officially banking organizations, specialize in vertical markets, like education or restaurants. They will re-sell a major acquirer's services to their verticals. These companies are called Independent Sales Organizations (ISOs). You may have a Merchant Agreement with a company who is not on this list. If that is the case, they are a reseller (ISO) for the services of the Tier 1 Acquirers in the list above.
The acquirer establishes and maintains merchant relationships by "boarding Merchants" and resulting in a formal "Merchant Agreement". The Merchant Agreement is the authoritative document as to any Merchant processing card payments, and also covers their responsibility to adhere to the PCI Security Standards to the satisfaction of the acquirer.
For their fees, the acquirer provides the communications services (either directly or through a subcontractor) required for the merchant to obtain real-time card authorizations and deliver end-of-day settlements. Some acquirers, such as Paymentech and Nova, also own "authorization networks," while some use a dedicated independent authorization network, like TSYS (a.k.a. Vital, a.k.a. VisaNet).
Generally, the daily communications, like real-time authorizations and batch settlements at the end of the day, are handled by a separate company sub-contracted by the acquirer to handle the authorizations and settlement communications. Many times, this "authorization network" is a division of or subsidiary of the acquirer, as with the acquirer First Data using their won "Nashville platform" (network) for the Merchants to communicate through. The services of the communication network (authorization network) are paid for by the acquirer as part of the fees that the Merchant pays for processing.
The acquirer is responsible for handling collecting the payments for all bankcard transactions the merchant processes. Most acquirers perform the transaction handling once the Merchant "settles" their daily batch through the authorization network, and insures that the collected money is deposited in the Merchant "deposit account".
The fee that the acquirer receives for their services is ALWAYS proportional to the amount of perceived risk they take in handling the transactions for a particular business.
The acquirer is the entity with whom you, the merchant, sign an agreement for processing card transactions. The acquirer quotes a " discount rate" which represents the percentage of a settlement that the acquirer will be paid. For instance, with a (totally theoretical) 3% discount rate, a $100 settlement should yield $97 to the merchant. BUT IT DOES NOT ALWAYS…
With regard to the 'applicable fees' referenced above, the acquirer quotes a discount rate which represents the percentage of the settlement that the acquirer charges the merchant for the settlement of the transactions. All acquirers are subject to the same set of processing rules and Interchange costs.
Interchange fees generally account for the largest portion of the fees for acceptance of Visa and MasterCard credit cards. The card networks set the fees, which vary based on several factors and generally range from 1 to 3 percent of the purchase price. Card networks have developed lower rates to encourage certain merchants to accept their cards. Acquiring banks and card network representatives also told us that certain merchants and transaction types are considered more risky than others and pay higher interchange fees for accepting card payments.
According to Visa and MasterCard, four main factors determine which interchange fee rates apply to a given transaction on their networks:
1. Type of card : Different rates apply to different types of cards. Visa and MasterCard have separate interchange fee rates for general purpose consumer cards, rewards credit cards, commercial credit cards (issued to businesses), and debit cards. Debit card interchange fees generally are lower than those for credit cards. Among credit cards, premium cards such as those offering rewards and commercial cards generally have higher rates than those for standard or traditional cards.
2. Merchant category : Card networks classify merchants according to their line of business. Network officials told us they develop lower interchange fee rates for industries that do not accept cards to encourage merchants in certain categories to accept cards. For example, grocery stores and utilities have lower interchange fees as a special incentive from the networks. Interchange fee rates are higher for merchants in industries such as travel and entertainment, in which network officials report customers spend more with their credit cards, providing the merchant with higher value.
3. Merchant size (transaction volume): Merchants with large volumes of card transactions generally have lower interchange fee rates. Visa categorizes some merchants into three tiers based on transactions and sales volume, with top-tier merchants receiving the lowest rate. Visa and MasterCard officials told us that the lower rates also were designed to promote the use of their cards over other credit cards and forms of payment.
4. Processing mode : Interchange fee rates also vary depending on how card transactions are processed. For example, transactions that occur without the card being physically present, such as on the Internet, have higher interchange fee rates because of the higher risk of fraud. Similarly, swiping a card through a card terminal, rather than manually entering the account number, would lower a merchant's interchange rate. The swiped transaction provides more information to the issuer authorizing the sale, and issuers and card networks consider such transactions to be less risky because the card was present.
Interchange fees for MC and Visa are listed here:
Merchants generally learn of changes to their rates for accepting Visa and MasterCard cards through their acquiring institution. Smaller merchants generally receive one or more flat fees (known as a blended rate) for payment acceptance that include both the interchange fee and the acquiring institution's fee. For merchants with blended rates, the costs of acceptance are uniform for each card type and interchange fee rates may not be disclosed on statements as a separate fee.
In contrast, larger merchants generally receive detailed statements from their acquiring institution and card processors, which include interchange fee categories, network fees, and fees from the acquiring institution. These statements reflect "cost-plus" rates, because the acquiring institution provides the merchant with the details of the costs passed on from the network along with the acquiring institution's own fees.
Visa and MasterCard develop and publish interchange rate tables (available on their Web sites) that disclose the default rates that apply to various types of transactions. Visa and MasterCard typically publish new interchange schedules twice a year.
Following is a diagram from the US GAO:
Great article here: http://en.wikipedia.org/wiki/Interchange_fee
The ever-increasing fees for processing cards are a good incentive to optimize your credit card processing system.
Great OP/ED article on the current Interchange litigation: http://www.forbes.com/sites/realspin/2013/09/03/set-vias-master-card-and-markets-free-approve-the-credit-card-interchange-fee-settlement/
All acquirers are subject to identical processing rules and Interchange costs. If they don't expose downgrades to the merchant, the costs are embedded invisibly in the discount rate. For instance, some acquirers provide the same rate for swiped and keyed cards. We know that the Interchange rate favors swiped transactions, so we would suspect that the merchant's rate is high enough to mask those charges. We suggest that you work with an acquirer who reveals all of the rate details, so you have the chance to optimize your transaction quality and achieve the lowest total cost of processing.
If the acquirer does not expose any downgrades to the merchant then the costs are embedded in the contracted discount rate. For instance, some acquirers provide the same rate for swiped and keyed cards. We know that the Interchange rate favors swiped transactions, which represent less risk for the acquirer, so we would suspect that the merchant's quoted rate is high enough to mask those charges. We suggest that you work with an acquirer (or potential acquirer) who reveals all of the rate details so that you have the opportunity to optimize your transaction quality and achieve the lowest total cost of processing.
Your actual deposits will never match the theoretical discount rate, because of some combination of the following:
— Flat fees for "front-ends" or gateways
— Per transaction fees for "front-ends" or gateways
— Periodic flat service fees
— Periodic proportional service fees
— Lease fees for terminal devices
— Service fees for terminal devices
— Per-transaction flat fees (usually for authorizations)
— Downgrades (penalties) for unqualified transactions:
— Lack of Address Verification attempt (not match)
— Lack of Invoice number
— Lack of Customer PO number
— Lack of destination zip code
— Lack of tax flag showing tax charged
— Lack of specified tax amount
— Lack of Level III data for CPC purchasing cards
— Lack of PS2000 data
— Lack of CAPN data
— Settling more than one day after auth
— Settling more than three days after auth
— Settling more than 7 or 10 days after auth
— Settling a different amount than that authorized
— Settling as retail without card mag stripe data
And many, many other factors…
Some downgrades are inevitable. For instance, for merchants who rarely do B2B, purchasing software options to support Corporate Purchasing Cards is not cost efficient. So if an occasional customer happens to use a Corporate Purchasing Card, the downgrade resulting from not providing Level III data is inevitable. The merchant's responsibility is to regularly review their acquirer's downgrade charges to see what can be eliminated.
Published by the card brands, these are excellent materials on avoiding chargebacks:
Subtract your actual deposits from the settlement totals to determine the EFFECTIVE rate for your processing. Compare that to the quoted discount rate, and then question your acquirer as to what the difference is. Only when you know what the downgrades are can you work to eliminate them.
As a merchant, it is important that you include intangibles such as the quality of service and support in the analysis. The analysis is complicated enough by the factors outlined above. But it is a given that no acquirer can discount their services enough to make up for poor customer service. While your analysis will include pricing and other numbers it is critical that you look closely at the service and support metrics no matter how fuzzy they may appear and consider such factors carefully. Most acquirers require lengthy contracts so due diligence is a must.
Save money by insuring that you are processing through a Tier 1 authorization network, and not a "gateway middleman". "Gateways" tend to add fees and not value. Discuss this with your Curbstone Account Representative.
As a user of the IBM iSeries AS/400, your effort to provide integration for card processing can be expensive. Mae sure that when you invest n the integration, you RETAIN the flexibility to connect to several auth networks. Since most bank/acquirers support one of more, you will be able to obtain competitive bids for your business from bank/acquirers. If you are locked in to one network, or just one bank/acquirer, you have lost the ability to shop for competitive rates and service. Curbstone is network and bank/acquirer agnostic, so we support the broadest range of banks, allowing you to obtain competitive bids on your processing.
1, 3, 7/10 - just numbers that can cost you. If you pre-auth on one day, and later flag the transaction to settle, the timing is critical to your fee. If the transaction is settled the same day it is authorized, you should get the best rate. If it is the next day, up to three days later, you pay a slightly higher rate. After three days, the rate increases again. After 7 to 10 days (MC and Visa), the rate increases. Once you hit 30 days, most networks will not settle it at all.
MONEY! If you do not attempt a match, you WILL be charged a higher rate. The result does not have to match, but you must ATTEMPT the match with at least zip code to avoid a downgrade that costs big bucks.
Because - MONEY again. If you can settle the same amount you authorized, you pay the standard rate. But, if you settle for any amount different than the auth, you will pay a higher rate.
Level II Corporate cards require you to send four additional fields at the time of settlement
1. Customer PO number
2. Tax Flag
3. Tax Amount
4. Destination Zip Code
If these are not included, you will pay a significantly higher rate for that transaction. Curbstone software supports those four fields as a standard feature, and your Implementation Project Manager will show you how to use them - even if you do not have that info available!
Just as Level II requires more data sent at settlement, Level III require a full line item detail of what was purchased. If you are taking those cards and not supporting Level III reporting, you will pay a significantly higher rate. Optionally, Curbstone supports the submission of the line item detail through the use of AS/400 physical files that are filled in once the order is invoiced.
In summary, the decision to contract with a specific acquirer is an important one. The good news is that you, representing the merchant in the system, have many options. From our perspective the key points are to look for an acquirer that offers a clear and understandable agreement with an explicit description of the rates that they will charge for their services. Also, the acquirer must demonstrate good customer service with timely and accurate responses to any issue that will arise during the term of the contract.
For customers using an application that supports card processing:
- The system will not facilitate collection, storage, or handling of sensitive credit card information directly in any way.
- The system will instantiate PCI PA-DSS-validated software, a "Payment Application", (transferring relevant non-sensitive information such as payment amount and Approval/Decline to/from the software) to facilitate the collection of sensitive credit card information for the purpose of authorization, sales, and other transactions.
- The system will manage and store only tokenized references to sensitive credit card information collected, handled, and stored by the Payment Application.
- The system should maintain a tokenized reference to the card and the transaction (specifically Approval/Decline) in order to perform required business functions such as automatic or manual re-authorization, ship against an existing authorization, or provide credit, without requiring the card information to be re-input.
- The system will optionally allow known credit cards to be saved by customer/contact for re-use in recurring orders, repeat orders, increased orders, credits, etc.
- The system should provide appropriate error notification should an attempt to use a card fail to be accepted by the Payment Application, including the potential for automated re-tries, or notification to users that the card has expired, been cancelled, or is otherwise unusable.
- The system should facilitate the use of multiple (unlimited) card payments for any order or invoice, and should accept payments against any open order or invoice at any time.
- The system should facilitate the application of a credit against a card for returns and cancellations. Cancelled order should prompt the user for an automatic authorization reversal or credit against the card(s) on file for the order. Partial cancellations may need to provide a selection among card(s) to provide a refund against. Any balance paid by means other than credit card must be processed in the usual way.
- The system should fully automate settlement processing, alerting the user only to significant exceptions that require attention.
- The system should provide an automated process for error recovery and re-authorizations that executes automatically on a scheduled basis without human intervention. Authorization or sale failures in this mode must alert users that actions (call the cardholder) must be undertaken to resolve issues.
For customers accepting credit cards external to their ERP software:
- The system documentation will explicitly declare that PCI PA-DSS compliance of the software applications, and PCI-DSS compliance of the systems and processes, is the sole responsibility of the organization licensing the software.
- The system documentation will strongly recommend against storing any credit card information within the system in fields not designated for it.
- The system documentation will strongly recommend that the customer develop and document appropriate procedures and controls surrounding any access to or handling of credit card information outside of or within the HarrisData system, in compliance with then-current PCI DSS guidelines.
- The system documentation will strongly recommend that the customer maintain the IBM i operating system and all related software at current version levels and that patches are reviewed and installed in a timely manner.
- The system documentation will strongly recommend that the customer consult with IBM or other competent entity to insure that no vulnerabilities exist on the server outside of the system.
In1999, Visa USA realized that the proliferation of businesses that use computers, take orders, and store card information presented a great risk to cardholders. Visa hired security consultants to develop a "best practices" document as a guideline for businesses that store credit card information.
In April 2000, Visa launched its CISP. Approved in October 1999 and mandated May 1, 2001, the program was created specifically for merchants and service providers who process, store, or transmit cardholder data.
Today, all of the credit card companies have joined the Payment Card Industry (PCI) to merge their security programs into what is called the "PCI Data Security Standard." The PCI standard offers a single approach to safeguarding sensitive data for all card brands, and it categorizes merchants into various levels and associated responsibilities:
Key Event - December 14, 2004: Payment Card Industry (PCI) heavyweights American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc., together empower the Payment Card Industry Security Standards Council with the authority to create payment industry best practices. The resulting Payment Card Industry Data Security Standard (PCI DSS) is at Revision 1.2, and is the industry's mandatory requirement to improve the security of credit card information.
The PCI DSS is not an actual legislative law. The enforcement of the standard is by the major payment brands through fines, sanctions, and more, makes non-compliance unacceptable to merchants. Possibly the greatest liability of non-compliance is the consequential damages that merchants are responsible for to the banks who issued cards to the merchant's customers. If a security breach exposes card numbers, the issuing bank must issue new cards to their customers, at great expense. In the case of TJX (T.J. Maxx Companies), they were found liable for about $120 MILLION dollars in card re-issuance costs charged to them by the banks who issued cards to their customers. That does not include the fines and penalties from the card organizations.
Finally, the banks who sign up merchants for processing accounts are now requiring proof that the applications used by those merchants are validated against the PCI DSS standard. For those merchants with substantial card processing, the standards must be officially evaluated by certified, independent Qualified Security Auditors (QSAs), and must be re-validated annually.
To most effectively enforce the new regulations, the standards were enforced at the merchants who processed the most transactions, first. Visa identifies four levels of merchants as based on pure transaction volume in any 12 month period https://usa.visa.com/partner-with-us/pci-dss-compliance-information.html:
The card industry is not the only entity concerned about credit card security. After many public hacker attacks and leaked card databases, legislative bodies have sprung into action. In 2007 Minnesota established the "Plastic Card Security Act" which states that any company that is breached and is found to have been storing "prohibited" PCI data (e.g., magnetic stripe , CVV codes, track data etc.) are required to reimburse banks and other entities for costs associated with blocking and reissuing cards. Note that the reissuance costs in a large breach will far exceed the costs of the penalties and fines. This law also opens up these companies to private lawsuits. Currently, the law does not affect Level 4 merchants (less than 20,000 transactions a year) - http://www.pcicomplianceguide.org/ Assume that legislative efforts to protect cardholder data will be imposed on Level 4 merchants soon.
Fortunately, the PCI has provided free tools to assist in implementing security enhancements to establish a credit card security baseline. Their superb "best practices" documents are free to the public and have the official PCI stamp of approval. No need for you to hire a security consultant and pay for the creation of a set of security guidelines.
— PCI Self-Assessment Questionnaire ('D')
— PCI Data Security Standard v2.0
— Prioritized Approach for PCI DSS Version 2.0
— Prioritized Approach Tool Version 2.0
— PCI DSS Quick Reference Guide v2.0
— PCI Security Audit Procedures
— PCI Security Scanning Procedures
— Qualified Security Assessor List
— List of Validated Payment Applications
— Frequently Asked Questions
— What to Do if Compromised
In a valuable effort to set minimum guidelines for enterprise security, Visa identified a dozen areas of concern, grouped into six general headings.
1. Install and maintain a firewall configuration to protect data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
3. Protect stored data
4. Encrypt transmission of cardholder data and sensitive information across public networks
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
7. Restrict access to data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
12. Maintain a policy that addresses information security
The requirements relating to the components of the overall security infrastructure are well-defined in their specifications and are unique to each installation. A majority of the security infrastructure requirements relate to non-iSeries procedures, such as updating router and firewall firmware, physical access, and more. However, there are still many that are directly applicable to the iSeries environment. For instance, much of the requirements for complex password can be set with adjustments to the following system values:
o QPWDEXPITV -- Password expiration interval
o QPWDLMTAJC -- Limit adjacent digits in password
o QPWDLMTCHR -- Limit characters in password
o QPWDLMTREP -- Limit repeating characters in password
o QPWDLVL -- Password level
o QPWDMAXLEN -- Maximum password length
o QPWDMINLEN -- Minimum password length
o QPWDPOSDIF -- Limit password character positions
o QPWDRQDDGT -- Require digit in password
o QPWDRQDDIF -- Duplicate password control
o QRMTSIGN -- Remote sign-on control
Many other security enhancements can be performed with these system values:
o QSECURITY -- System security level
o QDSPSGNINF -- Sign-on display information control
o QINACTITV -- Inactive job time-out
o QLMTDEVSSN -- Limit device sessions
o QLMTSECOFR -- Limit security officer device access
o QMAXSGNACN -- Action to take for failed sign-on attempts
o QMAXSIGN -- Maximum sign-on attempts allowed
The second set, policies/procedures, is aimed at protecting the storage of card information. The gist of these requirements is outlined below:
— Card Account Number -- This is the 14-to-16-digit number on the face of the card. The first six digits are the BIN representing the bank that issued the card. The last four digits are all that should be displayed on printed receipts or other documents, with the leading numbers masked with asterisks. This information should be strongly encrypted when stored, with Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) preferred.
— Card Validation Code 2 (CVC2), Card Verification Value 2 Code (CVV2), or Cardholder Identification (CID) -- These three confusing card verification acronyms represent the security codes that appear as the last three digits on the back of a MasterCard (CVC2), Visa (CVV2), or Discover, and the four digits on the front of an American Express card (CID). This should never be stored for longer than it takes to process the transaction.
— Expiration Date -- The two digit month and two digit year should not be stored, although it is allowed; however, if it is stored, it should be encrypted.
— Magnetic Stripe -- The contents of the stripe on the back of the card should never be stored for longer than the transaction takes to process.
— Personal Identification Number (PIN) -- This is the four-digit security code associated with debit cards. The PIN is encrypted immediately after being keyed, by dedicated hardware like a Hypercom PIN pad. A merchant is unlikely to ever have possession of it unencrypted; however, it is never allowed to be stored in any format.
— Access Logging -- One of the most important directives is that any user who gains access to the unencrypted card data, possibly for accounting or customer service reasons, must have that access logged in a security file. The file must record the time, date, user ID, and specific record accessed. Obviously, the identifier of the record accessed cannot contain the actual card number. Good commercial credit card processing software will provide this logging--or at least a unique key to the transaction for access and identification purposes.
Once you meet the minimum requirements outlined in the PCI documents, you can be comfortable that you have created the proper security environment and that your company will not be held liable should a security breach occur.
The primary security standard for all merchants who touch card data is the PCI Data Security Standard (PCI-DSS). The PCI definition of a "merchant" is:
"For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services..."
The PCI DSS, a set of comprehensive requirements for enhancing payment account data security, was developed by the founding payment brands of the PCI Security Standards Council, including American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa International, to help facilitate the broad adoption of consistent data security measures on a global basis.
The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data.
In summary, from PCI: "All merchants, whether small or large, need to be PCI compliant. The payment brands have collectively adopted PCI DSS as the requirement for organizations that process, store or transmit payment cardholder data. PCI SSC is responsible for managing the security standards while each individual payment brand is responsible for managing and enforcing compliance to these standards…"
Merchant PCI Reporting "Levels"
In addition to adhering to the PCI Data Security Standard, compliance validation is required for Level 1, Level 2, and Level 3 merchants, and may be required for Level 4 merchants.
Level / Tier1
Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region 2
Merchants processing 1 million to 6 million Visa transactions annually (all channels)
Merchants processing 20,000 to 1 million Visa e-commerce transactions annually
Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually
Obtained October 17, 2013: https://usa.visa.com/partner-with-us/pci-dss-compliance-information.html
The other standard is that imposed on the vendors of "commercial" applications that process credit card information. This used to be called the Payment Application Best Practices (PABP) standard, and is now renamed to the Payment Application Data Security Standard (PA-DSS). This standard is ONLY achievable with a time-consuming, expensive, third-party security auditor evaluation, and formal submission to PCI for inclusion in the list of approved applications ( https://www.pcisecuritystandards.org/security_standards/vpa/vpa_approval_list.html ).
Act now to avoid potentially massive fines!
Does your company process credit card transactions through the iSeries? If so, a high level of security is required for these transactions. Recent edicts from the credit card organizations (Visa, MasterCard, American Express, etc., now called the Payment Card Industry, or PCI) require that companies safeguard sensitive credit card data. Failure to comply can mean fines of $500,000 or more! If your company has not instituted compliance measures, do not delay further.
The key to a merchant's compliance lies in the "merchant agreement," the card processing agreement that the merchant signs with its "acquirer." The acquirer is the entity that buys the card transactions from the merchant at a "discount." This could be the Merchant Services Division of the merchant's bank, or an independent acquirer.
The merchant agreement stipulates that the merchant adhere to the current security standards outlined by the credit card companies. If the merchant loses data and is found to not adhere to these standards, the merchant is liable to the card organizations for possible huge fines.
Here is an excerpt of the security regulations from Visa: "Members (merchants) receive protection from fines for merchants or service providers that have been compromised but found to be Cardholder Information Security Program (CISP)-compliant at the time of the security breach… Members are subject to fines, up to $500,000 per incident, for any merchant or service provider that is compromised and not CISP-compliant at the time of the incident."
That's right; the fine can be up to half a million dollars per incident!
In addition, merchants must immediately notify the acquirer if they lose data. For instance, if a merchant fails to immediately notify Visa USA Fraud Control of the suspected or confirmed loss or theft of any Visa transaction information, the member will be subject to a penalty of $100,000 per incident.
Beyond that, a merchant could also be responsible for the re-issuance costs of the banks involved. For every compromised card number, a new card must be issued to the cardholder. The bank that issues the new card can take the merchant to court to recover those costs; in fact, a suit is pending right now against a large multi-store discount retailer for precisely these costs.
Various methods are provided by the card industry to combat fraud. In reviewing fraud prevention, we must consider the two primary ways transactions are processed:
— Card Present - retail Point Of Sale
— Card NOT Present - like mail order, telephone order
Each of these payment methods has its inherent challenges.
The biggest threat in accepting cards that are swiped in a magnetic strip reader are the prevalence of cloned cards. These are cards that are usually expired, but have the magnetic stripe data RE-WRITTEN on them so they swipe as a valid - stolen - card. This is the main reason that the PCI has banned the storage of mag stripe data. Steps to prevent this include:
1. Comparing the last four digits of the swiped card number with the embossed card number
2. Matching the expiration date of the swiped data with the embossed expiry data
The risk of taking card by mail or phone is that you cannot see the plastic embossing. The two methods the industry uses to authenticate cards used this way are Address Verification and Security Code.
Address Verification Service - Billing Street Address
AVS is used by providing data in one or two fields, the billing street address field, and/or the billing zip code field. When you attempt a match on the street address, the algorithm used by the industry attempts to match ONLY the numerical portion of the address. This is because spelling errors on street names are so common. Note that the authoritative source of the billing address components is the address on file with the specific bank that issued the card. Given that the address was likely keyed by a person from the account application sheet, it may not even be the correct address.
Every branded card has a three or four digit security code printed on the back or front. Visa calls it a CVV2 and prints three digits on the back. MasterCard calls it the CVC2 and it consists of three digits on the back. American Express calls it the CID, and prints four digits on the front of the card. These numbers are prohibited from being stored, as they are key to the security of a card not present transaction.
Curbstone's ROADMAP for protecting merchant card data stretches back to 1993 when the founder released the first commercial credit card software for the IBM Midrange AS/400. In 1996, he released the first commercial software to use strong encryption for the card data. This rich heritage continues with the new CorrectConnect™ initiative that is the future of Curbstone products. Based on a new technology secure Internet portal, CorrectConnect will allow the merchant to eliminate all direct contact with credit card sensitive data for Call Centers, Telephone Orders, Mail Orders, Retail, and e-commerce. This new technology uses proprietary technology that is Patent Applied For.
One Merchant Account (Virtual Codes)
primary bank merch. acct.
primary bank merch. acct.
primary bank merch. acct.
Merchants who have multiple locations could use the following:
Multiple Merchant Accounts (Physical Codes)
primary bank merch. acct.
secondary bank merch. acct.
tertiary bank merch. acct.
And multiple location organizations could use a scheme similar to this:
Curbstone Card is capable of eliminating ALL downgrades that are related to passing fields of data under control of the merchant, since the software is certified to pass all required fields. If the merchant fills them in, Curbstone will pass them, and thus avoid the costs of downgrades.
Also, Curbstone Card is capable of eliminating all downgrades that are related to passing fields of data under the control of the merchant. How is this so? Curbstone Card is certified to pass all of the required fields to the authorization network. If the merchant fills in the required data fields as part of the authorization and settlement process then Curbstone Card will pass the data to the acquirer and thus avoid the costs of downgrades. These costs can be substantial and we have seen downgrade fees range from the hundreds to the hundreds of thousands of dollars.
In addition, Curbstone's UNLIMITED Technical Support includes working with you to insure that any downgrades based on timing or amounts are the result of your informed decisions.
Curbstone does not support "middlemen" gateways, so your transactions pass directly to Tier One authorization networks, eliminating gateway fees as well as limitations on the critical information you can pass.
As presently constructed, the payment card system includes several interdependent components: the merchant, the cardholder, the cardholder's bank, the acquirer, the processing platform/authorization network and the merchant's bank. Payment card processing uses an industrial strength data communications network that is truly a key foundation of our economy. Data is moved quickly and cost effectively throughout the network.
By both the design of our product - Curbstone Card - and our business practices Curbstone is not tied to any one authorization network, acquirer or bank which provides the merchant with a level of independence and flexibility. While Curbstone works seamlessly with the merchant and the acquirer to process payment cards we do so in a loosely coupled or arm's length manner relative to the acquirer. We believe that we offer greater value to our customers by being independent of the other components of the payment card system.
In fact, one very important feature of Curbstone Card is that it shields the merchant's IT systems, including the business applications, from the need to be modified to adjust to changes made by the processing system or in the event of changes in your business relationships related to a specific acquirer. Indeed, there have been and will continue to be many technical and business changes to the processing system.
The acquirer, also referred to as the acquiring processor, is an entity with who the merchant has an agreement to process payment card transactions. The acquirer controls the settlement process. The settlement process is the sending of a merchant's batch to the network for processing and payment. For bank cards, the acquirer deposits money in the merchant's bank account (less applicable fees) with funds from Visa/MasterCard. The bankcard issuer then bills the cardholder for the amount of the sale.
Curbstone Card communicates with the acquirer via one of the industry standard authorization networks or platforms. Curbstone goes through a lengthy and detailed certification process for each network with which it is certified to ensure that all transaction data exchanged with the network is formatted correctly, secure and routed appropriately. The acquirer, in turn, contracts with the authorization network or platform as well-whether the network is directly affiliated with the particular acquirer or not. Currently Curbstone is certified with the following authorization networks:
— TSYS/Vital/Visanet (independent)
— Elavon/NOVA (US Bank)
— First Data
— VirtualPay (Bank of America)
— Global Payments (independent)
— Paymentech Tampa (Chase)
— Paymentech Mapleleaf Canada
A hosted solution for payment card processing and management
Curbstone Correct Connect (C3) is the follow-on offering from Curbstone Corporation that builds on the experience and knowledge gained by working with hundreds of merchants over the past twenty years.
C3 is an extension of the award-winning and industry-leading Curbstone Card (C2) with one very important and far-reaching difference. While C2 ran or operated on the merchant's server, C3 is a Payment Portal. As a "Payment Portal," C3 will maintain or host the merchant's cardholder information with all of the proper security mechanisms--Curbstone is an approved PCI service provider-- to ensure that the cardholder information is both secure and available to the merchant as needed.
As with C2, C3 will provide a high-speed secure connection to the authorization network or bank of your choice as well as to the merchant system(s).
Curbstone's newest technical innovation, the fruit of 20 years of experience, permits merchants to:
— Dramatically reduce compliance burdens and costs by both IT and Finance/Accounting
— Answer over 200 fewer questions on your PCI Self-Assessment Questionnaire,
replacing the SAQ-D with the SAQ C-VT
— Improve the security and protection of cardholder data, reducing the risk of fines and sanctions
C3 will generate a unique token to provide a reference for each transaction for a given order and the related authorization and subsequent settlement. The merchant will be able to research any order in their system in the event of a dispute with either the customer or the bank.
Further, the authorization process can be integrated with the order fulfillment process to speed up the time required to accept an order and eliminate the myriad of manual steps that many merchants go through to authorization a transaction-saving both time and reducing errors. As merchants offer multiple channels for orders for products and/or services C3 will allow the merchant to integrate all of the enterprise computing platforms and applications, including web sites, with one point of payment card authorization and settlement-again saving time and effort and reducing errors.
Merchants realize that payment cards are good for business but that they must protect cardholder information. To protect cardholder information, steps must be taken by every merchant and investments must be made. Limiting the exposure to threats of all kinds is a good investment and limiting the scope of the PCI analysis/audit is also a good investment. C3 provides all of the operational benefits of C2 and will greatly reduce the exposure of threats to cardholder information and minimize the scope of a PCI audit. Further, C3 will improve the order fulfillment process, reduce processing fees and protect cardholder information.
Implementing the C3 Payment Portal allows merchants to offload the storage, processing and transmission of sensitive cardholder data from their IBM i server(s), ERP/MRP systems, network and web sites, dramatically reducing their "scope" of PCI oversight and the associated costs. Curbstone assumes the bulk of PCI responsibilities on behalf of the merchant by being the custodian of all sensitive cardholder data. Although data will be stored remotely, C3 provides easy and secure real-time processing for all transactions, including the reuse of card numbers for returning customers or recurring billing. Further, C3-hosted data will continue to be seamlessly integrated with your current order fulfillment and financial applications, just as it is today, but through an encrypted, PCI compliant, real-time IP connection.
o The merchant keeps his Curbstone API and all local functionality; users will perceive little difference in system operation,
o The merchant retains the current flexibility to keep … or to change … his bank and processor,
o The merchant retains full ownership of all remotely stored cardholder data and may retrieve the data as needed, consistent with PCI DSS requirements, and
o C3 Payment Portal will include an innovative (patent pending) feature to eliminate both the processing and transmission of cardholder data from the merchant system and data network while maintaining order entry performance and effectiveness.
Remember--"they can't steal what you don't store!
According to Raymond Keating, Chief Economist for the Small Business and Entrepreneurship Council, most businesses and households reap tremendous benefits from the expansion and use of credit and debit cards. Among the key beneficiaries of expanded credit usage have been small/medium businesses (SMB). These benefits come from payment cards being an important source of financing for SMB.
The market has spoken and the results are clear. For proof -- according to the Pew Study of On-line Shopping published in February 2008 the revenues from on-line purchasing increased nearly five-fold from $28b in 2000 to $139b in 2007.
So payment cards are good for the SMB community. Why is Curbstone Card™ Software the best solution for the processing and management of payment cards?
First, current processes can waste money. In your case, many older products are not passing the appropriate information about the specific transactions to your acquirer and they are charging you for those missing data fields. The result is that these transactions are downgraded and you are paying extra fees every month for these downgrades. Curbstone will work with you to pass all of the needed fields to insure that you get the best processing rate from your acquirer or acquiring bank. Minimizing fraudulent transactions is another way to save money.
Second, current processing are costing time due to the number of manual tasks involved. With Curbstone Software, daily tasks are handled automatically by the system working in conjunction with orders being processed through ERP systems and any other order processing applications such as any web-based applications. Successful authorizations can control the picking or shipping process so that nothing is done until you know that you will be paid. Card info can be stored securely in the Curbstone Software database for returning customers or for recurring billing. Customers have reduced order processing time by 35% when the card authorization process is integrated with order taking.
Third, all companies that store, process or transmit cardholder data must comply with the PCI Data Security Standards and use a formally validated payment application. Curbstone Card Software is not only validated, but was selected for IBM's RoadAtlas for the Power System. Older payment applications that are not validated exposes the merchant to great risk.
The founder of Curbstone, Ira Chandler, was the author of the first commercial credit card processing software for the AS/400 in 1993. His prior company, ROI Corporation, was sold in 2003 to Verifone and is now their software division. He founded Curbstone in 2002 and re-entered the payment server software business when Verifone failed to adequately support the AS/400, iSeries, and System i.
Curbstone Card is the only stand-alone Payment Server selected by IBM for their Developers' Roadmap for the System i. Their selection, originally in 2005, is based on the company expertise and status of Curbstone as an IBM Business Partner. Curbstone has what we believe to be the largest installed base of payment server software, and is the only company active exclusively in the "i" space. One hundred percent of Curbstone customers are AS/400 System i shops!
Curbstone does not charge transaction fees, period. Our pricing is based on the service that we provide as a middleware to provide access to the auth networks that you need to use. The transaction fees are levied by the acquiring bank with whom you have a Merchant Account. Curbstone does not add to that, nor do we receive a commission on the fees you pay your bank/acquirer. In fact, using Curbstone can likely REDUCE your fees, since we commit to passing all of the fields required by your bank to help you get the best rate and avoid downgrades!
Credit card processing is a very complicated business. Since we are so experienced with the implementation of card processing on the IBM Midrange platform, we decided that we could simplify your life by including our implementation charges in the initial fee that we charge. That means that you receive UNLIMITED technical and operational assistance with the implementation, short of us writing code for you, at no additional charge beyond our Initial Setup Fee (ISF).
We never want you or anyone in your operation to hesitate to contact us for support. Card processing is critical to your business, and we want to do everything we can to facilitate solutions to your operational challenges. We never want someone in your organization to have to get permission to contact us because there is a fee attached. So our support is UNLIMITED, and available 24 hours a day, every day. We commit to 30 minute callback, and you will have access to experts who can really assist!
Since Curbstone does NOT require a merchant to "sign up" through Curbstone, you can retain your existing bank relationships! Since Curbstone is certified formally with the major communication networks in the US who perform authorization and settlement, we can support virtually all of the banks who provide merchant accounts.
Every network with which Curbstone is certified to pass transactions through has a different protocol. A COMPLETELY different protocol. While many of the fields remain the same, the transaction types and response codes are all different. In fact, some networks operate on a "host" capture basis, while others on a "terminal" capture basis. Without getting into gory details, Curbstone decided that we would provide a set of consistent transaction types that would allow a merchant to write to ONE SINGLE API. This means that regardless of the network to which you connect, the Curbstone operation is the same. If a merchant were to decide to change their bank/acquirer, and that required a change of the communications network that handled the auths and settlement, there would be virtually no change to the implementation they originally performed. This allows the merchant to switch networks/acquirers without any programming or operational changes. Even if a merchant never changes, their ability to do so without technical complications is a strong bargaining chip when they negotiate their rates with their bank/acquirer. If a bank does not have you locked in to their protocol, they are more likely to be recognize the need to provide competitive fees and service.
Curbstone supports so many banks and acquirers because we only need to communicate with the primary communications networks that most all of the banks use. In the US, every bank on every corner can sign up a merchant with a Merchant Account. However, there are a VERY limited number of communication networks that can be used to handle the authorization and settlement traffic. Curbstone is formally certified with the largest of these in the US. These networks are used by all of the banks to handle the communications traffic. Just a few major networks alone, First Data, TSYS, and Paymentech, handle the vast majority of card transactions in the US. That is what insures that Curbstone can connect to the network that your particular bank uses to handle the communication portion of the card processing.
Yes, Curbstone development and testing is performed on 11 different AS/400 systems, covering V5R3 through V7R1. The vast majority of our code is RPG, with a smattering of PHP and Java for secure communications. Curbstone does not offer products for any operating system other than OS/400 and IBM i.
Unlike gateways who own YOUR data and will not allow you access to it, Curbstone is setup for you to have complete control of your card data. All of the card information your process is available for your use to service returning customer, recurring billing, issuing credits, and all other business processes. If you were to change your systems and leave Curbstone, you can be provided a complete file of all of your customer card data.
Curbstone's interface is the revamped design of the original API from 1993. Having learned all of the complications of that first design, Curbstone corrected those flaws and simplified the interface to what we believe is the simplest possible level.
The simplest example of using Curbstone with your Order Entry would be for the green-screen app to present the screen into which the card data is keyed. We support all types of variations on this, but we will use that as an example.
The majority of the operational code of our API is contained in two "include files" that are included at the "I/D" spec level and at the "C" spec level of your program. Just those two lines of code provide full functionality for your API calls. The Data Structure that is used for all communications with Curbstone is externally defined, and made available by the copybooks. Your application will present the screen into which the card data is keyed, and those fields are moved or z-added to the appropriate fields in the Data Structure. This includes the card number, expiry, billing address, billing zip, amount, and a few others. Once populated with the data, the transaction type field would be set to "RA" to Request and Authorization, and the DS is sent with a simple execution of a subroutine we provide: EXSR C@SEND. Immediately following that, execute EXSR C@RECV, and in about three seconds, our software return the DS populated with the response from the auth network. Curbstone returns "UG" for an approval, "UN" for a decline, and "UL" if we found an error in the requesting DS. In that case, the field in error will be identified in another field so it can be flagged and corrected!
Easy! The Curbstone API requires about 15 lines of code at the point of authorization.
The real question is how to link a transaction processed on the web server to the order in the AS/400 ERP software. Curbstone does that with the use of a token that is provided for every transaction. Move that from the web server to the System i host, and you have access to update the transaction when it is ready to ship. At that time, your invoicing thread can update the total charge based on what you actually ship.
Many commercial ERP packages support the Curbstone API already. Some include Harris Data, CMS/400 - Solarsoft - Epicor, Ximple, Commsoft, Bookmaster, Lexel, and more.
All of the fields in our Data Structure are six characters in length, and begin with "MF" for Management Field. The token that we use to identify individual transactions is a 15 digit number with leading zeros, handled as an alpha field. This key represents each unique transaction, so it is the Management Field Unique KEY - M-F-U-K-E-Y. Wepronounce that "mu-FU-key".
This is the field that your Order Management software could retain to indicate which transaction is the payment for a given order or statement. In fact, since the MFUKEY token is 15 characters, it can be stored in the field that your ERP software might have previously stored the credit card number. Storing the Curbstone MFUKEY is not subject to PCI regulations, as it is not sensitive data!
Use Curbstone's token to refer to the card transaction already on file. We refer to that as an "archived" transaction.
Generally, credits are performed through the use of a reference to the transaction that was the original charge. The token for that original one is used in a new transaction to credit or void the original. Simple!
Curbstone has the ability to assign a "Merchant Code" to any physical or logical part of your business. This 5 digit, Curbstone-unique number associates with an existing merchant account, and there can be multiple of them pointing to the same one. This means that one "merchant account" as assigned by your bank/acquirer can be used by multiple entities in your company, and Curbstone will always provide the processing and reporting to delineate that. For instance, you may have one bank/acquirer account, but break the processing in Curbstone down into departments, like sales, service, parts, or any way you choose. As each transaction is formed, it is assigned the appropriate Merchant Code and reported on that way.
Curbstone's typical authorization performance is about 3 seconds per authorization. If your company is performing 4000 authorizations per month, a two second slower auth would waste a total of 8000 seconds, times two, since your sales rep AND the customer are waiting. That is 16,000 seconds, or a total of about 4 ½ hours that your sales people could be selling more each month.
Curbstone comes out of the box ready to operate in SIMULATION mode. Just load the CD in your iSeries System i, and you can test transactions immediately, receiving dummy responses to your test transactions. You can even force particular responses based on the amount you send. In this mode, a local program provides the response, and there is no network communications reuired.
Once your testing is satisfactory in simulation mode, where the local software provides the dummy response, most of our networks allow you to send dummy transactions out to a test server so you can see the entire communication process as part of the testing.
Use tokens to ELIMINATE the storage of card transaction data on your iSeries AS/400 system. The field Curbstone uses is the MFUKEY (management field unique key) and it provides complete access to every transaction stored on the Curbstone systems.
Curbstone's reporting provides a full slate of standard reports that generate regular AS/400 spool files. They are also provided with source code for your easy modification. Since the entire Data Structure that contains all of the Curbstone fields is contained in one record in a standard iSeries System i physical file, you can also do easy reporting by using the transaction status flags in that file. We document that well, and will provide unlimited tech support for your reporting efforts. Our support is provided by real AS/400 System i programmers from the USA.
Our settlement process allows for a pre and post settlement user job to be designated. Discuss this with your Curbstone Implementation Project Manager.
One of the most common questions we hear is this. Bottom line, discuss this with you bank/acquirer. It means that the card probably cannot be authorized electronically, and will require a voice call to obtain an authorization. This can be due to many factors, one being the suspicion of fraudulent activity on the card.
The following diagrams provide a great list of the things that should be considered in the OS/400 operating system to provide better security on your iSeries System i.
- "PCI Security Standards Council" https://www.pcisecuritystandards.org is the definitive source for up-to-date information on PCI compliance from the source. Formed by the major payment brands to develop standards and guidelines, the Council publishes a wealth of information on the site, including the Payment Application DSS (PA-DSS) guidelines and assessments. Key terms used in system development, documentation, and support activities should be derived from this source whenever possible. This source should be considered the authoritative source on any PCI Compliance issues.
- "PCI DSS', Wikipedia, http://en.wikipedia.org/wiki/PCI_DSS offers a good high level introduction to the topic of PCI compliance, with substantial background material available through related links and cited references.
- "PCI Compliance Guide" http://www.pcicomplianceguide.org is an educational site provided by a security software company focused on articles and discussion on PCI Compliance issues. While not as authoritative, information on the site is easily comprehensible and accessible.
- Board of Governors of the Federal Reserve System (Federal Reserve), Press Release, June 20, 2011, http://www.federalreserve.gov/newsevents/press/bcreg/20110629a.htm
- Federal Reserve, Average Debit Card Interchange Fee by Payment Network, August 10, 2012, http://www.federalreserve.gov/paymentsystems/regii-average-interchange-fee.htm .
- MasterCard, MasterCard Worldwide and Interregional Interchange Rates, October 2012, http://www.mastercard.com/us/merchant/pdf/MasterCard_Interchange_Rates_and_Criteria.pdf
- Shy, Oz, Who Gains and Who Loses from the 2011 Debit Card Interchange Fee Reform? Consumer Payments Research Center, June 19, 2012, http://www.bostonfed.org/economic/ppdp/2012/ppdp1206.pdf
· United States Government Accountability Office, Credit Cards: Rising Interchange Fees Have Increased Cost for Merchants, but Options for Reducing Fees Pose Challenges, November 2009, http://www.gao.gov/assets/300/298664.pdf.
- Visa, Interchange Brochure, https://usa.visa.com/support/small-business/regulations-fees.html
A Payment Application is "any third-party payment application utilized by a merchant or service provider that is involved in authorization and settlement of credit or debit card transactions."
PABP is a precursor to the current PA-DSS standard originally proposed by Visa in 2005.
Standard security audit protocol developed to allow merchants to acquire and use third-party software packages that have been verified to meet minimum security standards. The PA-DSS is applicable to off-the-shelf Payment Applications that store, process or transmit cardholder data as part of authorization or settlement. Compliance should be verified through an audit of the software by an independent PA-QSA company.
Generally refers to the payment card brands that are members of PCI Security Standards Council, currently American Express, Discover, JCB, MasterCard, and Visa.
The PCI security standards are technical and operational requirements that were created to help organizations that process card payments prevent credit card fraud, hacking and various other security vulnerabilities and threats. The standards apply to all organizations that store, process or transmit cardholder data. A company processing, storing, or transmitting cardholder data must be PCI DSS compliant, or face steep fines, penalties, or revocation of processing privileges. The formal PCI DSS standard was originally released on December 15, 2004.
The PCI SSC ("Council") is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council: American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.
Companies processing credit card transactions with one or more of the payment brands risk significant fines and penalties. All in-scope companies must validate their compliance annually. This validation can be conducted by Qualified Security Assessors - i.e. companies that have completed a three-step certification process by the PCI SSC which recognizes them as being qualified to assess compliance to the PCI DSS standard. However, smaller companies have the option to use a Self-Assessment Questionnaire (SAQ). Whether this questionnaire needs to be validated by a QSA depends on the requirements of the card brands in that merchant's region.
Ira Chandler is the founder of Curbstone Corporation and has been programming communications software for the last 35 years. Mr. Chandler wrote the first commercial credit card processing software for the IBM AS/400 in 1993. He has authored and supported AS/400 - iSeries - Power i communications software currently in use at hundreds of locations. Currently, both large and small companies depend on the IBM i operating system and Curbstone Card, including MIT, Harvard, WW Norton Publishing, RegalWare, Fisher Scientific, Campbell Hausfeld, AdoramaCamera.com, FujiFilm Medical, Terminix.com and US Space & Rocket Center.