Re: RFC: Credit card processing

Mike wrote:

Joe Stump 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). Everyone OK with that?

I would prefer a PEAR_Error, which is the standard in PEAR for most package.

The problem with PEAR_Error / true response it that in this case there is more finely graned information that needs to be returned. 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

This sound sloke a good idea to me. We do need more info than "it just worked". Some people, for instance, may not want to accept the "deferred" response as valid. Also, returning a PEAR_Error would allow for easy access to a general error message, which we really do need. I'd like 4-5 standard errors (like the ones listed elsewhere in the thread) so that you can code a more useful error message Processor independant. This is so the user can see "Payment declined" or "Error processing, try again in a few minutes" instead of a general "Your payment did not go through" message. So, you'd have a general error to decide what to show to the user, then you can get the specific one for debugging purposes. -- paperCrane <Justin Patrin>