Re: RFC: Credit card processing

On Friday 12 December 2003 05:00 pm, Joe Stump wrote: > > I think having a standard response format would be nice. > > It allready happened to me that a client switched his payment company > > just before the site was ready for deployment. > > Having the possibilty to just switch 'backends' would be very nice. > > Totally agreed. > Ok, I'll start working in this direction. > > AFAIK the different responses the diferent payment gateways return all > > point back to either: > > > > - card data invalid > > - card not chargeable > > - charging deferred > > - card charged with transaction id > > I agree - I also think other things can be added in case gateways > eventually add features (ie. insert id is a part of PEAR::DB, but only > supported by a few DB's that have auto_incrememnt IIRC). > Yes, but it gets silly in some cases. DPILink has 32 seperate return codes! I was going to have a unified return code anyways, with a function to get the full code and textual message. I think that everyone agrees that this is a good thing, and having common fields which all the processors is a pretty logical extension of this. Maybe it wasn't clear, but I was thinking of having e.g. a Payment_Foo_Result class which could then be extended by Payment_Foo_Result_Dpilink (or whatever) and was responsible for parsing out the response and making it sane and consistent. That way, the processor code itself doesn't have to care about that abstraction, it just hands the job off. Hence my concern about bloat.