foreach my $attrib (@_) {
  no strict 'refs';
  *$attrib = sub {
    my $self = shift;
    $self->{$attrib} = shift if @_;
    return $self->{$attrib};
  } unless defined &$attrib;
}
[download]

Oh, and to answer your question, I think a lot of people just ignore warnings in their error logs :-)

The bugs haven't been fixed primarily because there are dozens of people who have written subclasses to go with it and I no longer work with e-commerce, so I was reluctant to change things that may break other people's subclasses by trying to update a module that I don't even really use anymore (and I don't have access to the test environments for any of the processors anymore).

Ivan Kohler has taken over maintenance on many of the subclasses that I used to maintain (and has written many more) and has been working on the next generation of the module. You can find more information on his effort as well as a developer mailing list you can join if you are interested in helping him out at http://420.am/business-onlinepayment/ng.html.

I've left the last version of it that I wrote on CPAN simply because there are so many people using it, but I'm not actively maintaining it.

Thanks for the response, Jason. I'll check in on the new list.

$ perl -MBusiness::OnlinePayment -we 'for( 1..2 ) { \
   my $tx= Business::OnlinePayment->new('AuthorizeNet'); 
}'
[download]

Usually when you use multiple instance of a module, you name your "instances of the module" differently, like $tx and $tx1. Usually you would use a hash, like

my %tx;
for(1..2){ 
$tx{$_}{'object'}=Business::OnlinePayment->new('AuthorizeNet'); }
[download]

But I havn't actually tried the module, so I may be missing something. ;-)

You are missing something. The variable names are irrelevant -- you get the same warnings if you use different variables. It's also perfectly legal to overwrite a variable with a new instance of an object, but that has nothing to do with the bug.