[ic] BUG in &charge= when passing options (IC 4.8.2)

Javier Martin interchange-users@interchange.redhat.com
Wed Oct 31 16:12:00 2001


Hello,

I would like to share my experience with &charge and what I think it's a bug
in a specific part of its implementation.

THE SCENARIO:

We use &charge=... in our profile and we want to specify options, for
example 'transaction=mauthonly' to say that we don't want to capture, only
authorize. The line for this would be:

  &charge=[var MV_PAYMENT_MODE] transaction=mauthonly

If we do so, as a result we see that all options are IGNORED, ie. no matter
what parameters are passed they don't arrive to the payment module (say
AuthorizeNet.pm).


The problem seems to be in the file lib/Vend/Orders.pm:

>>>>>>>>>>>>>>>>>>>>>
	sub _charge {
		my ($ref, $params, $message) = @_;
		my $result;
		my $opt;
		if ($params =~ /^custom\s+/) {
			$opt = {};
		}
		else {
			$params =~ s/(\w+)\s*(.*)/$1/s;
			$opt = get_option_hash($2);
>>>>>>>>>>>>>>>>>>>>>

Here $params receives all the parameters passed to &charge (authorizenet
transaction=mauthonly). This piece of code splits that in two
($1=authorizenet, $2=transaction=mauthonly), and then $2 is converted to a
hash ref through get_option_hash. The problem is that get_option_hash makes
some regex checkings at first, and all $2 gets DESTROYED before it's
actually used.

The way to solve this is:

- Use routes to specify payment options.

- Use the tag version [charge] but care! if you use it in the profile, you
will charge even before the credit card is checked, as all tags are parsed
before the profile execution starts.

or...

- Patch the interchange code to pass a copy of $2, instead of $2 itself:


>>>>>>>>>>>>>>>>>>>>>
		else {
			$params =~ s/(\w+)\s*(.*)/$1/s;
			my $options = $2;
			$opt = get_option_hash($options);
>>>>>>>>>>>>>>>>>>>>>

The last has worked for me.


Javier