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

Jo Rhett jrhett at netconsonance.com
Thu Dec 7 09:24:23 PST 2006


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 );

-- 
Jo Rhett
Network/Software Engineer
Net Consonance


More information about the bop-devel mailing list