[bop-devel] Is this list live?

Ivan Kohler ivan at 420.am
Tue Feb 28 10:34:52 PST 2006


On Fri, Feb 03, 2006 at 06:23:07PM -0800, Bowen, Peter wrote:
> You're right, but since we all have day jobs, I'm left to make up my own
> field and method names. :)  I'm willing to rename the stuff that I've
> written that is unique to my module, but there are a ton of apps that
> use the 'standard stuff,' so those will have to remain the same.  As far
> as I know, all of the BOP stuff works with Freeside as a drop in
> replacement so a good number of methods are the same and the basic
> attributes should be the same.  Lacking good documentation, I tried to
> make BOP::CyberSource a drop in replacement, but some of the advanced
> stuff like fraud, etc. didn't have a template - so I improvised.
> 
> Validation is a good thing... however each processor validates
> differently. If you validate to the lowest common denominator then
> flexibility is lost.  If you leave it to the implementation, then it
> takes time for the validation to stabilize and get into the modules.  I
> admit my module pretty much relies on you being smart.
> 
> I suspect that if you wanted to head up those initiatives, Ivan has
> enough going on that he would let you do it... Ivan? 

Sure, I would.

-- 
_ivan


> 
> -Peter
> 
> -----Original Message-----
> From: bop-devel-bounces at 420.am [mailto:bop-devel-bounces at 420.am] On
> Behalf Of cpan at heckman.net
> Sent: Friday, February 03, 2006 12:29 PM
> To: bop-devel at 420.am
> Subject: [bop-devel] Is this list live?
> 
> Hey,
> 
> Is development on this module still ongoing?  Is there some kind of
> archive for this list?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Sorry for the rambling email - I've been thinking about this quite a bit
> lately.
> 
> -Mike


More information about the bop-devel mailing list