Daniel Watrous

ceekeigh, the confusing bit here is that you’re troubleshooting a php application (wordpress is obviously php, not perl cgi), but your error references a perl script.

I suppose it’s possible that your hosting provider has rigged some type of custom CGI passthrough to send requests to PHP, but it appears to be a non-standard server configuration.

That makes it difficult to know if the “Premature end of script headers” resulted from the PHP script or from the CGI script. I think you’re hosting company will have to answer that question.

I have just confirmed that this is working as expected in 3.2rc1

The development version appears to have fixed this.

Just read above in this thread.

You can also download the latest version and I have confirmed that it works for me.

I just verified that it works as expected in 3.1.2.

Thanks Mike

I did resolve it using either of the two methods you read in this post.

I have marked the post as not resolved to hopefully get some attention from the plugin developer.

I’ve found that the issue comes from a normalization function the plugin performs. There are a couple of ways around this.

1) The easiest way to get around it is to change your Site Address value on your main settings page in WordPress so that it is https. That will circumvent the part of the plugin that is changing them back to http.

2) The other way is to open the file “/lib/WordPressHTTPS/Module/Parser.php” and comment out the second conditional in the function normalizeElements(). That will prevent the normalization from happening at all.

I’ve emailed the plugin author, but no response, so I’m not sure when a fix might make it into the plugin.

Send in a ticket about the IP feature and we can discuss further:
https://helpdesk.danielwatrous.com/

More sophisticated platforms, like Magento, may have that type of feature built in, but I’m not aware of other solutions like mine. It’s still mostly custom software to process credit cards.

Steve,

My plugin doesn’t currently store the IP address of the user. That wouldn’t be too difficult to add to the log files or even the transaction display. That feature would be a few months out unless it was sponsored.

I’m puzzled about the fraudulent transactions though. What could someone stand to gain by making a donation with a fraudulent card? And how would they find your site to make a donation?

I suppose it would make more sense if they were attempting to purchase something, but it seems pointless to make a donation with a bad card. Do you have any ideas?

I’ve replied to your support ticket…

Great. Let me know how it works. You’ll also get details about how to submit to the helpdesk if you have questions.

That’s right. Any combination, including variable amount donations.

My site uses the plugin:
https://www.danielwatrous.com/authorizenet-for-wordpress

So does this one:
https://www.ugmportland.org/donate/

So does this one:
https://www.wallstreetweek.com/subscribe/

I do provide support and I’ve created a bunch of videos too that should make it easy:

https://www.danielwatrous.com/authorizenet-for-wordpress/plugin-training

Ed,

I’ve got a plugin that will work great for that:
https://www.danielwatrous.com/authorizenet-for-wordpress

You’ll need SSL, but the plugin will do all the rest. It will even accommodate ARB recurring payments.