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

[Jo Rhett]

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.

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.

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

-- 
Jo Rhett
Network/Software Engineer
Net Consonance