[bop-devel] deficiencies in BOP modules/standard

[Jo Rhett]

Ivan Kohler wrote:
>> 1. Result text = most payment providers return text for successful 
>> results as well as error results.  Shouldn't there be a single field 
>> which includes this text?  All of our modules supplied this, and more of 
>> our customers used it than I expected.
> 
> Sure.  In general I think we need to start maintaining a proper master 
> list of input and output fields rather than continue with the current ad 
> hoc "I saw AuthorizeNet or some other module use this field" allocation, 
> before any worse incompatibilites arise than the cvv stuff Phil pointed 
> out.

Yes.  Strongly agree.

>> 2. Raw sent/receive data.  For debugging purposes it is nice to see the 
>> data sent and the result returned.  Right now you have to go and edit 
>> the BOP provider module to get this.  AuthorizeNet will give you the raw 
>> reply, but not the raw submission.
> 
> I'm not sure this is always applicable, but yes, I agree that when there 
> is this raw data, it should be available in a standard fashion.
> 
> A "raw result hash" of processor name/value pairs would also be a good 
> thing to have a standard method to return (parsing any transport XML or 
> whatnot, but otherwise returning processor data).  This is something the 
> Interchange developers have requested.

Yes, as long as *ALL* fields are returned.  For example, the 
AuthorizeNet module is only grabbing 3 fields from the reply.  When I'm 
trying to figure out WTFJH it's really nice to have the entire response 
available.  Not all the time.  Rarely in fact. But when you want it, you 
want it now. Without editing system-installed libraries :-)

>> 3. LinkPoint -- why are you using their very broken lpperl.pm instead of 
>> re-implementing it in a standardized fashion?
> 
> Because I needed to get something up and running to process 
> transactions, quick'n'dirty notwithstanding.  :)
	...
> You are more than welcome to work on B:OP:LinkPoint if you have the 
> desire.  Hell, perhaps I can even swindle you into^W^W^Wallow you the 
> privledge of taking over maintenance of the module.  :)

I will duck that like a free trip to Iraq :-)  But I may take on the 
merge of our old module and this sometime in the near future.  I really 
hate the fact that they call curl in an insecure manner, write things to 
STDOUT, etc.   (the B:OP module doesn't even redirect STDOUT before 
calling their routines...)

-- 
Jo Rhett
Network/Software Engineer
Net Consonance