credit card processing on unix with fp

[Bill Campbell]

On Wed, Nov 14, 2007, Fairlight wrote:
>When asked his whereabouts on Wed, Nov 14, 2007 at 04:11:45PM -0500,
>scooter6 at gmail.com took the fifth, drank it, and then slurred:
>>    I too am looking for this - and after attending the filePro conference I
>> might be convinced that
>>    sockets is the way to go on this - unless there is an alternative.
>
>The problem with this plan of action is that if the CC company (or the
>bank, if you're dealing with ACH) requires SSL, you're screwed. fP has
>(TTBOMK) -no- SSL library support built in.  If they have it, it hasn't
>been advertised well/at all.
>
>What you have with fP-Sockets is access to the basic socket and networking
>API via fP's language.  However, that comes with NO application-level
>protocols.  You get TCP [and possibly UDP] as your network protocol, that's
>it.  But the app-level protocols that ride on top of TCP are entirely
>non-existant in their offering.  Here's the networking layer cake:

If the credit card company supports XML-RPC, it's pretty easy using the
python xmlrpclib to hack together scripts to talk to an an xmlrpc server
(far cleaner that perl's implementation).  One should be able to put
together a request in FilePro, execute an external script that handles the
transaction, then get the results back in a file or on standard output.

We use xmlrpc extensively to handle special purpose administrative tasks,
some of which require root priviledges, from remote machines.  Usually the
remote machine connects via an https call to a procedure that restricts
connections by IP or other methods.  The public interface runs at the
normal low priviledges of Apache.  It can then execute priviledged commands
via another xmlrpc server running on localhost as root.

One example is updating DNS from customer systems.  When they make a change
in their local DNS (djbdns), their machine updates our secondary records
using an rsync module that permits the update to a specific directory, and
only from their IP address.  After this is done, their machine sends and
xmlrpc call to our public server requesting that make be run in our djbdns
directory.  When our main machine runs make in that directory, it updates
its master DNS data files, then performs a similar process using rsync and
xmlrpc to update all of our DNS servers.

The main advantages of doing things this way is that the file transfers are
done to specific directories limited by IP address, and all root level work
is restricted to a specific tasks without having to do things like have ssh
authorized_keys without pass phrases.

Bill
--
INTERNET:   bill at celestial.com  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
FAX:            (206) 232-9186  Mercer Island, WA 98040-0820; (206) 236-1676

Anyone who thinks Microsoft never does anything truly innovative isn't
paying attention to the part of the company that pushes the state of
its art: Microsoft's legal department. 
   --Ed Foster, InfoWorld Gripe Line columnist