Re: RFC: Credit card processing
| From: | Ian Eure | Date: | Sat, 13 Dec 2003 05:10:28 +0000 |
| Subject: | Re: RFC: Credit card processing | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-24384@lists.php.net to get a copy of this message | ||
On Friday 12 December 2003 08:29 pm, Mike wrote:
> Ian Eure wrote:
> > On Friday 12 December 2003 06:36 pm, Mike wrote:
> >>>I'm leaning towards a simple success/failure model, and you can call a
> >>>function to get the exact error (which will vary from processor to
> >>>processor).
> >>
> >>I am writing some classes for Validate at the moment and have found the
> >>same, a true/false response is best.
> >
> > Well, best until we can overload '=='. But not too much more code is
> > required to check a class of a return.
>
> it may not be much extra, but it isnt 'nice'
>
> if (Validate::creditCard($ccno)){
> echo "valid";
> }
> else {
> echo "Invalid";
> }
>
> compared to
>
> $ret = Validate::creditCard($ccno)
> if (get_class($ret)=="PEAR_Result"){
> echo "Valid";
> }
> if (get_class($ret)=="PEAR_Error"){
> echo "Invalid"
> }
>
I don't think it's that bad:
$result = $payment->process();
if (PEAR::isError($result)) {
// failure
} else {
// success
}
> It leaves a lot of room for errors with newbies who expect a true/false
> response (like 99% of the php functions that validate data
> (function_exists, preg_match))
>
Well, nobody should be using a /credit card processing class/ without reading
the documentation and knowing what sort of return value to expect.
> A true false, with status has the benefit of being able to have a
> two-tier return method.. you can do either basic or fine graned... eg
>
That code is very similar to what's pasted above, with the exception of the if
test.
At that point, though, it's not much more difficult to have a unified result
class, and test it with if ($res->isError()).