Fwd: SPUG: online cc software or mechanism?

[Eric Johanson]

On Fri, 25 Aug 2000, James Munger wrote:

> 
> > Can anyone suggest software/services for credit card varification
> > that will run work smoothly with Perl/Linux? 
> 
> At my last job, I made the first version of our billing system.
> I spent the first few weeks researching third-party companies
> that do this sort of thing (this was spring of '99).
> 
> The industry leader is CyberCash, but I found them to be
> slow to respond to questions, and their code interface was
> very kludgy.  Instead, I went with authorize.net, which
> was faster, had relatively simple means of communicating
> with their tools, and had better customer service.

I would agree with your notes about cybercash; It would seem that they have not
really done any software updates in a few years, and it also seams that they
want to make $$$ for each phone call. :(  I used them for CC processing a few
years ago, back when it was free! (It was a good deal then... but now... umm..)


> 
> > I have several merchants with website catalogs who already have
> > merchant credit card accounts. They would like to speed up the
> > process. Presently we ship the web orders to them via email and
> > they call in the credit card for approval after the fact.
> 
> If they want to speed it up from this, then you need to either
> keep their information on site, or have them submit it each
> time through a web interface.  The latter is probably more
> safe (see below), but doesn't save as much time.
> 
> > My take on how it would work is that our order scripts would send
> > the vital information about the card to a service that chases down
> > the cardholder's data and returns the results. Does this require
> > software, or can it be done by mail?
> 
> It's done by web interface.
> 
> The lowdown is thus, if using authorize.net:
> 
> - Version A (information not yet available)
>   - User submits cc information via your web page (SSL).
>     This includes "name on the card" and zip code.  These
>     are the only two pieces of information (besides cc#
>     and expiration) really needed to verify a valid holder
>     of that card, if I remember correctly.
>   - The form that gets this information goes to a script
>     that sends this information to the site.  In my case, I
>     used LWP to connect to their "input cc order by hand"
>     web page, which returns another page that you scrape
>     back with LWP and hopefully has "Authorization Accepted"
>     (or something, I forget) on it.  Otherwise there's an
>     error message you can parse out for the user.
>   - One it's accepted, you do what you do with the order,
>     knowing you'll get your money.

This is true unless they do a charge back on the card. Then you are out of your
money. :)

> 
> - Version B (information on site, automated)
>   - If your users have their own identifier (e-mail,
>     whatever), then you can save their information
>     on site, and bring it up and the submit page when
>     they get to that part.  If you want to do this,
>     though, you'll still have to have them go through
>     step A the first time through, of course.
> 
> Whether or not you want to keep the clients' information
> digitally is a whole other issue, involving lots of
> security questions.  As I'm a programmer, and not a
> systems person, and the system I worked on never made
> it into production (don't ask), I can't help much with
> this part (yeah, I'm copping out here).
> 

Using a standard RDMS of some sort, you can record all of the transaction
history on your own, and keep track of the CC info.  Security is a big issue; I
setup an external RDMS using Sybase... (not on the same server, on a server that
only allowed DB connections from the webserver thanks to a firewall)

I setup a customer_billing_info table that the web_db_user only had write
perms.  This way, you can store CC info without having rights to read it. 

Is this wise? I'm not sure, it's worked well for me.  If you can get your
systems people to have faith in the security of the DB, (and it really is
secure!), it should be ok. 



Regarding Version A/B;  I did something completely different. :P   They have
something (poorly documented) called ADC (Automated Direct Connect).  Under
ADC, you can effectivly call the services directly from a HTTPS Post, passing
all of the parms (billing info, amount, account number) to it, where it will
then return a delimited string to parse out.   It was quite basic to setup; one
you have the Crypt::SSLeay module setup for SSL stuff, you should be ready to
go.  (or Net::SSLeay)

http://www.authorizenet.com/support/docs/



> The transaction works like this:
> 
> You submit the information, and it's accepted.  However,
> you don't have your money right away.  It goes into a
> large batch of transactions for the company (authorize.net
> in this case) to submit to banks at the end of the day.
> When the actual transactions are done, the money all goes
> into an account you've set up at some other bank.  From
> this same account, authorize.net takes its cut once a
> month.
> 
> The cost for authorize.net was $15 a month and $.35
> per transaction.

One of my customers told me that http://www.rtware.net/ was cheaper.  I don't
know for sure, but I know they use the same servers as authorize.com. (three IPs
apart, same docs) You might check them out. 

> 
> Asides:
> 
> You can submit batches of comma-delimited (or was it
> tabs?) to a different page.  This is useful for subscriptions
> and other recurrent charges.
> 

I personally found it easier to just have my code submit batches via the ADC for
things like subscriptions/monthly billing.  The web-import for delimited files
was just to buggy, and painfully manual each month.   But I have heard of some
folks using it sucessfully. 

> Also, it takes checks.  Submit the routing number, account
> number, and bank name, and you can deduct right from the
> user's checking account.  Same cost, I think.
>
> > Would love to see a presentation at a user-group meeting about
> > setting this up.
> 
> (I feel like I should be charging billable hours :)
> 
> Unfortunately, I wouldn't feel up to snuff enough to
> go through a full presentation on this, as I haven't
> touched it in just over a year.  I can feel "the little
> things" trying to resurface as I type this.

If I can find the time, I may be able to pull some info on this to present.  I
would also like to note that I'm no expert on this, but I have setup 5
E-Commerce systems using this method of CC Processing. (2 in perl,
1 ASP/ 1 ColdFusion) The bad part is most of my code is under NDA; so anything I
present would just be 'how to do it yourself'. :)    Somebody shout if they are
interested.  (Any contribs welcomed!)


> 
> I know there are some other such clearing houses out
> there, maybe on Yahoo! or some of the other big names
> (which probably bought or partnered for the technology,
> but I digress).
>

I'm sure that there are other options; CC processing is getting (is?) a huge
market.  I know what works; and I've had good luck with it.   :)

-Eric Johanson

See James Munger's great Disclaimer below. 
 
> James Munger
> IS, Cobalt Group
> 
> Disclaimer:  I am not affiliated with authorize.net or anyone else
>   in its market.
> 
> 


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For full traffic, use spug-list for LIST ; otherwise use spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/