[bop-devel] Is this list live?

[Bowen, Peter]

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? 

-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


_______________________________________________
bop-devel mailing list
bop-devel at 420.am
http://420.am/cgi-bin/mailman/listinfo/bop-devel