[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