Re: New hierarchy for payment processors?

> > Hi, > > I have developed a PHP extension for processing credit cards and other > transactions with Verisign Payment Services. This is in the current CVS > tree as ext/pfpro. > > These functions currently accept and return arrays of raw transactions and > responses. I was thinking of adding to it some user-friendly functions, > for example, Sale, Authorise, Capture and Void. > > However since these would use the existing functions, but wrap around to > add functionality and simplify their usage, John Donagher has suggested > that they would be better in user-land as a PEAR package. > > First of all, I note that the pear files are in the standard source > distribution, but I cannot see why this is unless it's to force everyone > to install the base PEAR packages when they install PHP. (I can't see any > mention in the documentation). Is this the reason? > PEAR is a part of PHP (currently), therefore it is automatically installed along the the rest of PHP. Sort of like Perl comes with a standard module set. > Secondly, if this is to be implemented as PEAR package, a new top-level > hierarchy needs to be established. I would like to hear thoughts on what > this should be, as "Payment" isn't really descriptive and something like > "CardProcessing" is too restrictive as the functions can be used for > electronic checks and other forms of payment. > What are you thinking of naming the class? > As a quick summary, let me show how my class works at present: > > - method SetCard to set credit card number and expiry date > - method SetHost to set verisign hostname and port if required > - method SetProxy to set proxy details if required > - various methods to process stuff, e.g. sale() authorise() void() and > capture() which take parameters like amount and reference number > > I look forward to hearing back a suggestion for how this would fit into > PEAR, or whether you believe it would not be suitable for this. > It would be suitable for PEAR... -Sterling