[bop-devel] inconsistencies / a need for a more formal B::OP specification?

[Ivan Kohler]

On Thu, Dec 07, 2006 at 12:12:59AM -0500, Phil Lobbes wrote:
> I'm slowly starting to use more B::OP backends and the more I use
> different modules the more there are differences that make B::OP less
> than ideal in my mind.  I know this isn't a trival problem, but perhaps
> we should be trying to evolve some standard specification for
> functionality that's "common" among drivers?

Yes.  I'd hope we can normalize more things going forward, not only the 
field names but also in other common functionality.

For an example on my part, the new "failure_status" functionality (see 
notes_for_module_writers_v3) was recently added and I hope more of the 
gateway modules will start supporting this - it allows app writers to 
take different actions based on the different "shades of gray" of 
decline responses rather than just the boolean "is_success == 0".

I'd also hope for some amount of introspection (may have mentioned this 
before), so you can ask a module about what sorts of functionality it 
supports.

> Some examples (I haven't surveyed too many modules -- but I'm sure the
> problem is bigger than just these few observations):
> 
> 1. CVV2 information
> 
>   * PayflowPro and Paypal backends have a cvv2_code() method
>   * Authorize.Net has a cvv2_response() method
> 
> It sure would be nice to have a standard for this.

Agreed.  Lets pick one and call it the standard.  Authorize.Net was 
probably first, though if more other popular modules are using a 
different method, we could change it.  In whatever modules that change, 
would be best to retain a method with the old name that carps a warning 
telling you to change to the new name, rather than break things 
outright.

> 2. PayflowPro will "filter" the zip field in content:
> 
>       ( $zip = $content{'zip'} ) =~ s/\D//g;
> 
> Other drivers leave this as a responsibility of the caller to "do the
> right thing" (my preference).  Perhaps we make a standard for this?

I'm not sure.  My first inclination would be to go Postel and try to be 
"liberal in what we accept".  If most gateways accept "XXXXX-XXXX" (and 
that's how you'd expect to see zips), why cause extra pain for people 
who switch to Payflow Pro from some other gateway?  I'd consider it part 
of presenting a standard interface across gateways, don't you think?

> 3. Handling authentication data
> 
> Some drivers use %processor_info to pass along user/pass/etc. but others
> do not.

This is one of the worst warts I inherited IMO.  Gateway authentication 
is distinct from transaction data.

Gateway auth data should be passed in as %processor_info.  Login and 
password in the transaction %content should be deprecated, still work 
for now but warn.  I don't think we want to try and standardize the 
gateway auth (many use login and pass, many use all sorts of other 
different stuff), just allow arbitrary key/value pairs in the 
%processor_info like we do now.

>   my $tx = Business::OnlinePayment->new($processor, %processor_info);
> 
> This one is definitely trickier as the way you authenticate to various
> backends certainly varies but if we can find a standard-ish way to deal
> with most cases that would be nice.  For example:
> 
> * PayflowPro requires auth info as part of %content
> * Paypal does not allow this
> * Authorize.Net needs login and transaction_key (at least for what I've
>   done it does -- password seems not used or perhaps completely optional
>   but it isn't the same as transaction_key)

If the gateway does or doesn't requires auth info as part of %content, 
that's an implementation detail of that processor, I think we should 
still have the auth passed in as %processor_info, not the transactino 
content.

> These comments are along the same lines as some from Jo Rhett recently.
> I certainly see a need for more standardization if at all possible to
> ease transition between different backends (or to support the use of
> multiple backends at one time).
> 
> I'm willing to help out where I can one these, anyone else care much
> about this topic?

I'm certainly interested.

-- 
_ivan