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

[Peter Bowen]

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
AND putting together a small steering group to try to help developers to
play nicer?

-Peter


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