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

[Ivan Kohler]

On Thu, Dec 07, 2006 at 09:02:58AM -0800, Jo Rhett wrote:
> Ivan Kohler wrote:
> >>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?
> 
> Card expiration dates are a good example of why not.  Some gateways will 
> take it several different forms.  Some will only take it in a specific 
> format.  I believe that it would be better for B:OP to accept only a 
> single format (or N number of well-documented formats) and then have the 
> module maintainer munge the known format into the form desired by the 
> gateway.

Yes, I agree, and I thought that's what I said above.  In the same way, 
the payflow pro "filter" is supposted to munge standard "XXXXX-XXXX" 
zips into the format desired by the gateway... (perhaps the 
implementation is too sloppy for your liking, but that was the idea..)

> Right now we have a big if/then/else structure listing every gateway we 
> support trying to make sure that the expiration is in the right format.

Weird.  I just use "mm/yy" with all gateways.

Not that I disagree about the "standard accepted formats" for 
expirations, like I said in my other message.

> >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);
> 
> I disagree.  Er, I agree conditionally.  As long as you can get away 
> without supplying %processor_info at all, and instead use
> 
> $tx->processor_param( $option1 );
> $tx->processor_param( $option2 );
> 
> ...later then I agree with your original statement.

Implementation plan in my other message that gets you what you want, 
plus adds introspection for auth options... go for it.  :)

-- 
_ivan