Re: Discussion of Credit Card Processing Requirements

["Chris Travers" <..hidden..>]

The real obstacle to doing card present via OnlinePayment is that we
would probably have to add the mapping to every back-end module
separately.

The difference between card present and card not present has to do
with the way the credit card data is verified.  The UI hasn't been
built yet, but current plans indicate it will consist of a single
<input type="password" name="trackdata" ... /> field which the card
reader will dump the data into and then it will be encoded and entered
into the main form for submission.  This will probably use the track1
on most card readers.  In most cases, the card reader will be a sort
of pseudokeyboard, but serial ones could be supported through
extensions of the current terminal port framework already a part of
the new POS program.

For more detail on card verification, there are three ways you can try
to track the card:
1)  With a cryptographic digital signature encoded in the magnetic
stripe (card present only).  This is called the CVV or similar terms.
2)  With a unique 3-digit number printed on each piece of plastic.
This is the CVV2 (usually used for card-not-present) or similar terms.
3)  By linking the billing information provided to the information on
file by the issuer.  This is the AVS system.

The only way that the first option works is if the magnetic track data
for either track 1 or track 2 are sent to the processing gateway in
their entirity.  If these are not sent, the transaction may be
downgraded and processed under the higher rate card-not-present
discount schedules.

The current approach is to create an extremely light framework which
is somewhat tightly coupled with the existing application.  There is a
simple module which does nothing except exposing a really simple API,
then there are plug-in drivers which provide specific functionality.
TCLink makes this very easy.  Something like Authorize.Net would be a
little harder.  The main advantage to this approach is that less
sensitive data will be exposed in the event that the namespace isn't
cleaned when we eventually move to mod_perl since the only thing that
needs to be cleared is $form.

Hope this helps,
Chris Travers

On 10/12/06, Tony Fraser <..hidden..> wrote:
> On Thu, 2006-10-12 at 15:18 -0700, Chris Travers wrote:
> > Did a little more digging on this.  Looks like I haven't been able to
> > find track data submission at all on their roadmap and that developer
> > releases havent been released in over 18 months (from a previous
> > release cycle of 3 months).  I suppsoe we will have to consider that
> > project dead :-(
>
> No, I wouldn't call it dead... I would call it mature. It's just a thin
> API Layer, the work gets done by the individual driver modules, like
> Business::OnlinePayment::TCLink.
>
> I didn't look at your framework to see that you were supporting Card
> Present transactions. Now I'm interested to see how you did that with-in
> the constraints of a web based application.
>
> Anyway, I still think it would be worth investing the time in adding
> Card Present support to Business::OnlinePayment rather than re-inventing
> the wheel.
>
> --
> Tony Fraser
> ..hidden..
> Sybaspace Internet Solutions                        System Administrator
> phone: (250) 246-5368                                fax: (250) 246-5398
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel