[bop-devel] Is this list live?

[Ivan Kohler]

On Fri, Feb 03, 2006 at 07:29:13PM -0000, cpan at heckman.net wrote:
> Hey,
> 
> Is development on this module still ongoing?

Not the sort of "ongoing" where anybody is currently giving it tons of 
attention, but it hasn't been abandoned.

Most recently I updated B:OP:HTTPS to remove a workaround for old 
Net::SSLeay versions and depend on Net::SSLeay 1.30.

> Is there some kind of archive for this list?

http://www.sisd.com/pipermail/bop-devel/

I added a link to the list archive next to the subscription information.

> While I'm a newbie to the OnlinePayment module history a few things 
> jump out at me regarding v2 and v3.
> 
> It seems like there should be a standard for field names with each 
> module adapting the field name to their processor's idiom.

There isn't a formally-documented standard other than the woefully 
inadequate basic list in the B:OP manpage, but for the most part 
processor modules *do* adapt standard field names to their processor's 
idiom.  There might be a very few obscure fields defined differently in 
different modules, but I haven't had any trouble using swapping out 
dozens of different backend moules in my application, for example.

B:OP:AuthorizeNet is probably the "canoical" source for field names at 
the moment, most other modules were inspired by or based on it, or at 
least duplicate its field names.  As Peter points out, making a master 
list of all field names currently in use would be the logical first step 
here...

> Is there a reason we don't have standardized data validation?  I know 
> that some processors charge by request so a user putting in invalid 
> data can cost you $.20 - $.30 per attempt.  By having the data 
> validation routines in the core OnlinePayment module we can catch and 
> reject requests before we even make an outside connection.

This seems like it could get really messy, really quick.  The last thing 
we want to do is kick out a valid transaction because of an overzelous 
data check or some weird UTF-8 problem.  Most processors I've worked 
with don't charge you a transaction fee unless the transaction is 
actually submitted to the underlying financial network.

Just an offhand thought, but maybe we could figure out what hooks and 
callbacks we need to add so that a separately-maintained validation 
module or modules could optionally be used, rather than add validation 
to the B:OP core?

> Is there a reason we don't have authorize, capture and refund methods 
> in addition to the commit method?  Leaving each module author to 
> define the value you send to determine if you're doing an authorize or 
> a capture makes it difficult to change from one module to another.

Here's where you totally lose me.

We don't have a commit method - I assume you're talking about the 
"submit" method.

Module authors don't define a local value you send to determine if 
you're going to do an auth vs. capture (authcapture, refund, void).  
This is one of the few things that *is* defined in the base class.  You 
pass a (standardized) "action" value along with your content.  Possible 
(documented) values are:

Normal Authorization
Authorization Only
Credit
Post Authorization

There also an undocumented (but de-facto standard) "Void" action as 
well, for the few processors that support voiding 
not-yet-captured-or-settled transactions as distinct from a "Credit".

> Personally, it also seems like creating a 'merchant' object which 
> contains the merchant information and is an object factory for 
> transactions would better seperate the merchant specific information 
> from the client information.

This seems a bit OO overkill to me, but I'm not going to veto it or put 
up a fuss or anything if you think its a useful refactoring and folks 
agree.  It would be trivial to support the "one step transaction against 
a merchant" method of the current API, so current code wouldn't break or 
anything.

-- 
_ivan