Re: RFC: Credit card processing

> The problem with PEAR_Error / true response it that in this case there > is more finely graned information that needs to be returned. Why not use the DB model? DB Error of some sort? Return a DB_Error class (extended from PEAR_Error) Result good? Return a DB_Result class. There should be a Payment_Process_Error class and a Payment_Process_Result class (which we have talked about - it would contain transactionID, etc.). --Joe > > eg. > > - card data invalid - return pear error with msg to state that card is > invalid (simple) > - card not chargeable - same as above > - charging deferred - return true, but there is extra information (like > await for confirmation before shipping) > - card charged with transaction id - return true, transaction id needs > to be accessed as public property of processor object, need to ship asap > as it is bought and paid for > > What we really need is some sort of PEAR_Success class, which is the > good twin of PEAR_Error, until this happens, true or error (with code) > is not good enough... It would be a simple class which just holds a > status code and the message, along with the methods to set them > > Mike > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Joe Stump <joe@joestump.net> http://www.joestump.net "Label makers are proof God wants Sys Admins to be happy."