By Scott Henry
Would you tell merchants their payment terminals are Class B-certified? Probably not; odds are they would wonder why their devices didn't merit Class A.
But that doesn't mean you shouldn't know the differences between the two levels and fully understand what certification is all about. Certification can be a time-consuming and expensive proposition for system vendors, but it is a necessary step in ensuring that devices will interoperate properly with the payment network.
Essentially, there are two forms of certification:
· Class A: The processor endorses use of a device to process payments on its servers and provides help-desk support directly to merchants.
In many instances, Class A certification also includes processor-branded documentation for acquirers and merchants, download support, and sale or lease of POS hardware on which the certified software runs.
· Class B: The processor has reviewed the content of the various authorization and settlement messages from the POS application and formally endorses that the software may be used to process payments on its network.
However, support is provided by an ISO, or in some cases, the vendor of the hardware/software solution. In effect, Class B certification is a small but critical subset of the Class A certification process.
Without certification, a payment terminal cannot connect to a processor, which makes it effectively useless. If no processor has certified the payment solution, there is no way the solution can obtain the payment authorization for a transaction. That's why vendors line up to get their systems in the evaluation queue with each processor organization.
Class A certification not only requires meeting Class B requirements for connecting to the processor, but there is also an extra set of hoops to jump through. System vendors pursuing Class A certification will need to provide on-site training to the processor's staff to ensure they have the information and skills to support merchants.
Vendors must also set up an escalation process to resolve issues that the help desk can't reconcile. The processor staff has to be fully competent in regard to software downloads, software application procedures and error messages.
Payment solution providers must certify both the hardware device and the actual payment application that will run on that device. But assuming a device meets the processor's specifications, the payment application — the software -- will require the most time and effort to attain certification.
From the system supplier perspective, the certification process generally starts with a request from its sales force to deliver a solution that complies with processor specifications. Those specs can include message format, communication protocols, interchange processing requirements and so forth.
The vendor's application development group will deliver an estimate on what is required to complete the task and what will be needed from the processor to complete certification.
The actual software development will go through several processes, including design, programming, quality assurance and project management review. Upon completion, it will be delivered to the processor for testing.
In the meantime, the vendor must develop a user manual; the vendor may also have to produce keypad overlays and quickcard reference materials. Training courses and materials will also be created for the on-site training requirements. In practice, certification can take as much as six months to a year from start to finish.
Many variables can impact the timeline. Relationships always play a role. It's a lot easier for a processor to reserve a place in the queue for a vendor with which it has worked smoothly in the past. The amount of documentation that a vendor is able to deliver to a processor's technical staff may also have an impact on certification timelines. And, of course, the processor's workload will affect the schedule.
Certification can be hard or easy based on the architectural foundation of a vendor's product line. In some cases, vendors may have to write a payment application specific to each device they manufacture, which makes each product certification a unique situation.
Architecture that enables one application to work the same on multiple platforms, and POS applications that do not require changes to achieve separate payment processor certifications for separate connectivity configurations are ideal.
In addition to obtaining certification from a processor, wireless devices using cellular networks must meet certain requirements from the Federal Communications Commission, as well as wireless carriers.
The internal radios of wireless devices must be FCC-compliant. And the systems themselves have to meet the carriers' certification provisions, for example, code division multiple access (CDMA) systems for Verizon Wireless and Sprint, and general packet radio systems (GPRS) for AT&T.
Wireless carriers want to ensure the POS devices will interact properly with their networks and adhere to FCC requirements regarding frequency usage. The testing process can take from two to three months.
Vendors' systems must also comply with major card issuers, associations and government entities.
In particular, vendors are focused on Visa U.S.A.'s mandate in relation to the Payment Card Industry (PCI) Data Security Standard: As of Jan. 1, 2008, vendors may no longer offer for PIN pad use any system that doesn't meet the PCI spec.
VeriFone has been building new systems with this in mind for some time, so compliance is not a major issue. What's tougher is evaluating pre-PCI systems to determine whether they will need to be retooled, refreshed or replaced to meet the new requirements.
There are many issues regarding certification, but for the most part, merchants just want to know somebody is there to provide support if something goes wrong.
Merchants are not likely to be concerned with whether the product has Class A support from a processor, or Class B from an ISO. Large ISOs with an established support infrastructure are generally more than happy to go to market with Class B-certified systems.
VeriFone will provide those ISOs with the same types of training and technical information as provided to processors. The result is the ability to go to market much faster than ISOs that wait for Class A certification by the processor.
Scott Henry is VeriFone's Director of Product Marketing for North America. He can be reached at firstname.lastname@example.org en
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next