Re: New hierarchy for payment processors?
| From: | Stig Sæther Bakken | Date: | Mon, 24 Jul 2000 12:23:49 +0000 |
| Subject: | Re: New hierarchy for payment processors? | ||
| References: | 1 | Groups: | php.pear |
| Request: | Send a blank email to php-pear+get-158@lists.php.net to get a copy of this message | ||
David Croft wrote:
>
> 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?
>
> 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.
>
> 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.
>
> Regards,
>
> David Croft.
PEAR is intended for exactly this kind of thing. It's ok to have it in
the main CVS right now, but I think we should move most of the classes
out to separate distributions when the tools are done.
Welcome aboard :-)
- Stig