Please contact sales@jpos.org if you want to get additional information about training options.

I thought we could use an hybrid approach, local encryption until you transmit the transaction and get the acquirer-generated cryptogram. But this is actually not required if we use PKI.

So the proposed scheme seems good to me for local encryption where you need to protect customer information. When you can use a remote encryption service, PKI is the way to go. You just need to encrypt using your acquirer’s public key.

For auditing purposes and network compliance, applications connected to the Visa network (either directly or through a payment gateway like FDR, Fifth Third, NPC, etc.) must adhere to Visa’s Cardholder Information Security Program (“CISP”), which dictates acceptable practices in regards to the protection of cardholder data for official information, refer to http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html. The specific requirements at issue here are those related to cardholder data – these are discussed in bullets 3.3 and 3.4 of Visa’s Payment Card Industry (“PCI”) PCI Security Audit (see embedded PDF as hyperlink in Visa page referenced above). Those requirements read:

3.3 Mask account numbers when displayed (the first six and last four digits are the maximum number of digits to be displayed).

Note that this does not apply to those employees and other parties with a specific need to see full credit card numbers.

3.4 Render sensitive cardholder data unreadable anywhere it is stored, (including data on portable media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:

• One-way hashes (hashed indexes) such as SHA-1

• Truncation

• Index tokens and PADs, with the PADs being securely stored

• Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with associated key management processes and procedures.

JPOS it’s not GPL but it doesn’t have a standar license at leas it’s not a restrictive one.

Also I see that there is no support for transaction templates (predefined transactions ready to be created at request). I would preffer to write this part if the license would be “compatible” with my projects.

On one server, jPOS-EE is running smoothly as a Windows service. It listens to our client’s 3,500 stores via a TCP/IP connection. On the other server, we are running a copy of MS SQL Server (our client’s enterprise DB of choice). jPOS-EE makes calls to SQL Server through the jTDS driver.

The transaction mix in the throughput test was all internal (i.e., nothing switched out for faux-authorization) because these are the most resource consumptive varieties. For each transaction, our application validates store, terminal, card and cardholder on respective SQL Server tables and updates a tran log with a result. Througput the test, the new jPOS-EE Web interface was available to get real-time feedback on the test’s progress (this impressed our client a great deal).

We suspect throughput would be higher if the transaction mix consisted of switched-out transactions like goods purchases initiated with a Debit card.

By the way, some comments on the jTDS driver – we ran some traces on SQL Server and from that perspective it’s impressive to watch the way jTDS optimizes performance – it sets up a number of temporary procedures and then makes use of them resulting in very little CPU expenditure. HOWEVER, its critical that when using jTDS in conjunction with SQL Server, you take heed of the following variable:

sendStringParametersAsUnicode (default – true)

Determines whether string parameters are sent to the SQL Server database in Unicode or in the default character encoding of the database. This seriously affects SQL Server 2000 performance since it does not automatically cast the types (as 7.0 does), meaning that if a index column is Unicode and the string is submitted using the default character encoding (or the other way around) SQLServer will perform an index scan instead of an index seek.

See – http://jtds.sourceforge.net/faq.html

You MUST have this variable set to FALSE. Without it, SQL Server performance goes to Absolute Hell. On our quad-processor box, we moved CPU needles straight to 100% for the duration of the test and performance was 10-fold worse than our ultimate results (this is the reason we had the SQL Server traces on to begin with).