[ic] RFC: Payment.pm map_actual() modification to preserver empty
b_address2
Mike Heins
mike at perusion.com
Mon Oct 6 13:51:58 EDT 2003
Quoting John Young (john_young at sonic.net):
>
> In Payment.pm, map_actual() creates %actual for data submittal to
> payment gateways.
>
> It performs a nice fallback of looking in $::Values, then
> \%CGI::values, and lastly filling in any b_ variables with values from
> non-b_ variables if the b_ variable is empty (ie, if 'b_address1' has
> no value, it falls back to using the 'address1' value).
>
> That is fine mostly, except in a case such as the b_ variables are
> filled out as you wish, and you have intentionally left b_address2
> empty. If address2 contains a value, $actual{b_address2} is set to
> address2 (which is not desired). This only affects what is sent to the
> payment gateway, so it's not a big deal, for the most part. I only
> noticed the problem when reviewing receipts from the payment gateway.
>
> I have modified my Payment.pm as follows:
>
> --- Payment.pm.orig Thu Dec 12 19:22:27 2002
> +++ Payment.pm Fri Sep 5 01:34:50 2003
> @@ -182,6 +182,7 @@
> foreach $key (keys %map) {
> $actual{$key} = $vref->{$map{$key}} || $cref->{$key}
> and next;
> + next if ( $::Variable->{BILLING_NULL_OKAY} &&
> $::Variable->{BILLING_NULL_OKAY} =~ /\b$key\b/ );
> my $secondary = $key;
> next unless $secondary =~ s/^b_//;
> $actual{$key} = $vref->{$map{$secondary}} ||
> $cref->{$map{$secondary}};
>
>
> ...and added to catalog.cfg:
>
> Variable BILLING_NULL_OKAY b_company b_address2
>
> (even though 'company' and 'b_company' are not in the list through which
> map_actual() iterates at the moment)
>
>
> Any comments or suggestions for a better solution are welcome!
I have thought about this one quite a bit. I think the best thing
to do is have a set of indicators to sense whether a transfer
of the fields is necessary (I chose b_address1 and b_city), and
a set of fields that will be always transferred enmasse, which I
chose as:
b_address1
b_address2
b_address3
b_city
b_state
b_zip
b_country
These would be set by default, and could be modified in the variables
MV_PAYMENT_BILLING_INDICATOR an MV_PAYMENT_BILLING_SET. (The MV_ is
wanted when the variable is going to be put in the core.)
The result of this is that those fields would be transferred enmasse
or not at all. The other b_ fields not in MV_PAYMENT_BILLING_SET
would be transferred as they are now.
Thanks for bringing the problem up!
--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.513.523.7621 <mike at perusion.com>
If you think nobody cares if you're alive, try missing a couple of
car payments. -- Earl Wilson
More information about the interchange-users
mailing list