[bop-devel] things that I propose that we unify in B:OP

[Ivan Kohler]

On Thu, Dec 07, 2006 at 10:43:34AM -0700, Peter Bowen wrote:
> I wrote the CyberSource module, and I had trouble figuring out what to
> implement and how to play nice with other modules...  I would love to see a
> wiki that can identify and define the methods and way that modules should be
> implemented.  I'm a little loathe to rewrite the module, but there's
> apparently some new stuff that I have to do for CyberSource in Q1 and I've
> seen some traffic about new fraud stuff this last week - so now would be a
> good time to do it.
> 
> Ivan - would it make sense to put together a wiki for building new modules

Sure, as I posted earlier, lets use 
http://www.sisd.com/mediawiki/index.php/Business::OnlinePayment/ unless 
anyone objects (and has an alternate location).

> AND putting together a small steering group to try to help developers to
> play nicer?

Besides the folks on the bop-devel mailing list?

I'm not entirely sure what you mean by that, but I'm open to hearing 
more.

-- 
_ivan


> On 12/7/06 10:24 AM, "Jo Rhett" <jrhett at netconsonance.com> wrote:
> 
> > I would like to start a list of things that I propose that we unify in
> > B:OP main module, which would require less if/then/else in the main code
> > and would present a more unified interface.
> > 
> > Naturally, each of these thing would require the payment gateway module
> > to parse the new input.  However, my reading of the modules indicates
> > that this is *reduce* the amount of code in then, because they'll only
> > have to expect a single format.
> > 
> > 1. First Name, Last Name.  Almost all gateways want separate names now.
> >   Why don't we modified B:OP to require both names and have the 1?
> > gateway that uses a full name add them back together?
> > 
> > 2. Test options.  We currently only support 1, but most gateways support
> > Pass/Fail/etc test options.  Lets have B:OP allow a consistent set of
> > tests and have the gateway Carp or falsify if the processor doesn't
> > support that test.
> >    ** My customers really like being able to test out negative
> > responses, which B:OP doesn't implement right now in any of the gateway
> > modules.
> > 
> > 3. A single format for Expiration date.  Let the gateway munge it into
> > the format it wants.  In particular, I think that B:OP should accept both
> >     expiration => 'mm/yy'
> > -or
> >     expiration_month => 'mm'
> >     expiration_year => 'yy'
> > 
> > And send a single consistent value to the gateway module.  (note that
> > others may have strong opinions on this, include mm/yyyy and how to
> > handle people with full dates mm/dd/yyyy or dd/mm/yyyy format.)  But
> > whatever we do should be the same across all modules.
> > 
> > 4. A standard method to ask the processor if it can reject based on AVS
> > mismatch.  So instead of hardcoding the avs stuff into the program
> > around the module names, you can just $tx->isRejectAvsAvailable() ?
> > 
> > 5. B:OP should strip all other characters from the card number field.
> > Some gateways accept them, some don't, but none will bark if they
> > receive only numbers.  (and the gateway module could fix that anyway)
> > 
> > 6. B:OP should look at the number and submit the right card type
> > information to the gateway module.  /^4.../ is Visa, etc etc.  Nobody is
> > going to ask the customer this, and the number formats are well known.
> > Right now our app does it, but it would be easiest to unify in B:OP.
> > 
> > Yes, if you know the code you're probably jumping up to say "But B:OP
> > isn't in the information flow!"  So yeah, I'm proposing that it be.
> > Either the method calls a B:OP method which calls a processor method
> > (easiest to implement with little change to gateways) or the gateway
> > module does a callback on the input
> > 
> > $input = Business::OnlineProcessing::parseInput( $contents );
>