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

[Ivan Kohler]

On Thu, Dec 07, 2006 at 09:24:23AM -0800, Jo Rhett 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?

Requiring separate names as the "right way" going forward is fine with 
me.

For backwards compatibility, if only a single name is provided, I think 
B:OP should use Lingua::EN::NameParse to parse that to first/last rather 
than break old code (and carp that the single field is deprecated and 
separate names should be provided).

> 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.

I'm not sure I understand what you're talking about in full here.  Can 
you expand on this?

> 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.

I think we should accept a variety of reasonable formats with month and 
year (handing the mm/dd vs dd/mm stuff seems silly though), and yes, 
send consistent values to the gateway module.  All the expiration 
munging in different gateway modules is gross.

> 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() ?

Yes, think there's a ton of introspection stuff like this that we should 
define, so you can ask the processor modules about many different 
aspects of their capabilities.

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

Sure.

> 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.

Use Business::CreditCard to provide card type information.

> 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. 

So mote it be.  notes_for_module_writers_v3 once we've firmed up the 
implementation/API.

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

-- 
_ivan