innerfence has developed an iPhone App called the Credit Card Terminal.  It is a thin application that acts as a front end and uses an Authorize.net Merchant account using the Authorize.net API over SSL. Looks pretty neat and a useful option for mobile acceptance of credit cards.

Looks like innerfence is a Authorize.net reseller, since you can use any authorize.net merchant account – I suggest you shop around the the best rates, theirs appear to be a little high.

I’ll put this in the "Why didn’t I think of that ?" category.

EDIT:  Check out this link to the innerfence blog where there is a video on the app, and its integration to another iPhone App – Ring It Up Point of Sale.

I’ve been developing some small tools that allows for us to send transactions via a swipe in a .NET windows based application as well as in a Java Web based version to a test instance of OLS.Switch. I used to (and still do) just pipe binary message dumps over netcat pointed to our OLS.Switch’s configured server port for this specific message format.

for example:

$ cat visa_credit_sale.dump | nc 192.168.1.50 33000

where visa_credit_sale.dump would just be a binary file of the message

$ hd visa_credit.sale.dump

would look like this (intentionally blurred and is a test card number)

Here is a shot of the Virtual Point of Sale System:

and a shot of the Virtual Terminal:

Basically you can swipe a card or key-enter a card on the virtual terminal and depending on the configuration of OLS.Switch – (I’m using bin based routing here in this test setup)

Cards that start with:

• 4 – Visa
• 5 – Mastercard
• 6011 – Discover

go to our FDR North (ChasePaymentTech) Simulator and and return a simulated response.

• 3 – Amex

go to our American Express Simulator

• 7 – Stored Value

go to our Stored Value Systems Simulator

• 6 – OLS Stored Value

get switched to our own instance of OLS.Issuer – our authorization host which is not a simulator.

The vPOS and VT are sending in messages in the Visa K/Visa D or otherwise known and Visa Gen II message format (one of the incoming message formats that we support from the device side) and depending on the card type, we are building the appropriate outbound message according to the interface specs (generally an ISO8583 variant), hitting our simulators to get different responses based on amount prompting or in the case of the OLS Stored Value cards, it uses the card files, velocity and limit checking, card status and other authorization rules to authorized the card.

The neat thing? an end-to end transaction take less then 50ms on a sub $1000.00 test server on a local lan.

Here is a link to a PDF that shows the full transaction flow.