When attempting to process a credit card with Woocommerce Authorize.net DPM plugin, the browser does not redirect after processing through the gateway. Instead it is "stuck" in the gateway and echoes the following message below. It has only been happening since we upgraded Woocommerce. We have version 2.1.12 and version 1.5.0 of the Woocommerce authorize.net DPM. I have tried disabling other plugins while checking out, no errors in the error log, making sure no values are in the relay urls on the account, etc. I'm pulling my hair out! Please help if you know what could be going on!
An error occurred while trying to report this transaction to the
merchant. An e-mail has been sent to the merchant informing them of
the error. The following is the result of the attempt to charge your
credit card.
This transaction has been approved. It is advisable for you to contact the merchant to verify that you will receive the product or
service.
I had a similar issue recently, caused by our security plugin (iThemes, in this case) blocking requests with no user agents. I think this block may have come about in a recent update as I was able to resolve my issue by disabling the HackRepair.com's blacklist feature. If in fact this is your problem, you'd be looking for a line in your htaccess that looks similar to RewriteCond %{HTTP_USER_AGENT} ^$.
This is a Relay Response error. As noted here, this means that "that Authorize.Net is unable to connect to the page that you have specified as your relay response URL".
According to Woocommerce's article about troubleshooting common problems with the authorize.net DPM payment gateway, a good place to start is by deactivating nonessential plugins to see if there is a conflict.
As I just learned from encountering this problem, another possible cause for this (somewhat vague) error message is an empty MD5 field in the woocommerce settings if an MD5 Hash Value has been set for the merchant. You can check or set the MD5 hash value in authorize.net by going to Account > Settings > Security Settings > MD5-Hash.
If no hash value has been set through authorize.net, that setting can be left blank. But if it has been set, leaving it blank will apparently produce a Relay Response error.
Hope this helps someone.
I contacted woocommerce for this issue and it was resolved by changing to permalink setting for woocommerce to something other than default. You can change this setting in the Settings > Permalink page at the bottom.
Related
I get 'Sorry, your session has expired' on Checkout page. I am using CartFlows for creating a funnel, and Stripe as a payment processor. All other flows and checkout pages are working well except the last one: https://awesometuts.com/ch
It works sometimes, but mostly gives me session expired. In console I have no error related to that. Documentation is no help.
I am using Cyberpanel and my own VPS for a server.
It sounds like the service you're using is creating the Checkout sessions too early and providing the URL or redirect after the session has expired.
If you control the Checkout session creation, you need to do that closer to the customer redirect. If the platform you use controls this, you should reach out to them to understand expected behaviour and get some help with fixing this issues.
The maximum (and default) time to expiry is 24 hours after creation: https://stripe.com/docs/api/checkout/sessions/create?lang=php#create_checkout_session-expires_at
I have resolved the problem. Issue was with CloudFlare. I was using some speed optimisations that created some kind of conflict. Have turned them off, now all runs smoothly. Thanks
My WordPress website is using Stripe and WooCommerce plugin to accept credit card.
But on final checkout page, the credit card field is not working and showing very small size:
"Live Publishable Key" and "Live Secret Key" are correct.
Any idea how to fix it?
There are many types of solutions for this problem, like having SSL installed, using the correct domain, etc.
On my site there was an error with the PayPal Checkout, which I had active too, that caused the stripe credit card form to not get filled with the according input fields. When I deactivated PayPal Checkout I could use the form just as expected again.
So far that's enough of a solution for me since I can continue using the normal PayPal implementation on WooCommerce without needing PayPal Checkout.
The PayPal Checkout error I received was:
Uncaught TypeError: Cannot read property 'FUNDING' of undefined at getFundingMethods".
I have not been able to resolve it yet though without deactivating PayPal Checkout.
This issue may due to the incorrect domain, license keys from Stripe or the setup process in the documentation haven’t been completed:
Please follow this documentation step by step:
https://docs.woocommerce.com/document/stripe/#section-2
Setting up a site for someone and using Sage Pay, the site is built in WooCommerce and it is using a plugin for the payment gateway from the Sage Pay site.
Currently i am getting this error: 5080 : Form transaction registration failed.
The Sage Pay account holder said to fix it i need to have a success and failure page. However between WooCommerce and the plugin i cant imagine those would not be included. Would this be a issue with the setup of Sage Pay or am i missing something?
I recommend you look in My Sage Pay. Under Transactions -> Invalid, you may have an entry which corresponds to the transaction - this will have an error message which actually relates to the specific failure (instead of the generic 5080 error)
Issue was the surcharges, once deactivated it worked fine.
I purchased the Tickera wordpress plugin from Tickera.com. I have repeatedly requested support from them, but they don't respond.
I installed this plugin on a client's website to sell tickets for an event. The plugin works. The visitor buys the ticket via paypal and then they are sent an e-mail with a PDF attachment of the ticket which can be scanned at the event.
The problem is that with each transaction, my client gets an e-mail from PayPal with this statement:
Please check your server that handles PayPal Instant Payment Notifications (IPN). IPNs sent to the following URL(s) are failing:
and then it has my client's URL with the folder where the WordPress lives and then ?ipn=paypal.
Do I need to open a IPN account on PayPal to stop the error e-mail? I have been afraid to do this, in case it screws up the function of the plugin. It is working now.
Does anyone have experience with this?
-w
It sounds like the plugin must be setting the IPN URL using the NotifyURL parameter of API requests, or just the notify parameter in a standard HTML button/form. That would override anything you set up in your PayPal profile anyway.
It sounds like there must be some sort of a problem with the IPN script itself that is causing it to send a failure code of some sort back to PayPal's IPN server. You should be able to check your web server logs for the times that URL is getting hit and see the result there so you can look at the error and resolve it.
I would be very reluctant using this plugin - see Facebook for more than enough reasons. As to not try to say too much, I will just say "client side only validation" and "tickera == name your own price ticket system". What made this bug even worse is that it could be triggered accidentally by merely using normal browser behavior and so a kid with no knowledge of Javascript or the sort could still easily add 4 tickets, proceed to payment, click back in the browser and again proceed and get 4 tickets for the price of 1... Someone with a bit more knowledge and malicious intent could mess with a client side value array and set prices to $0.01/ea if they wished... I was consulting for someone in an attempt to clean up the mess from using this plugin and quickly discovered Tickera to be less than helpful on the support front... Best I can tell, the client-only-validation "bug" (horrible design) is still in play.. When notified of the bug, they were pretty much like "Oh, no biggie - just review all sales and cancel/refund/etc manually" - an unacceptable solution for medium/large events and just bad business for an event of any size... There are some serious security concerns with this plugin and their lack of response or support is just the icing on the cake... Beware.
I have a wordpress site with Membership and Events. I am using Paid Membership Pro for memberships and Event manager Pro for events. I am using Authorize-net payment gateway and most event bookings are successful.
But I can see some booking in the Admin with the status Processing(Authorizenet AIM).
I have log to the Authorizenet and there is no processing transaction for this booking.
Could you please help me to solve this. What is the reason for that status?
Thanks
You will need to have SSL enabled for you site otherwise this will not work. Events manager will always force the https connection if a booking form accepting Authorize.net is used.
Wideload Shipping may be correct here, if you don't have a valid SSL certificate or SSL enabled then the booking process won't work with Authorize.net since you must be able to send card info securely.
I'd suggest you ask this on our pro forums, as a pro customer we'd be happy to help you troubleshoot there. If you supply us a link we can also probably have a better idea about what's going wrong and provide you with further steps to remedy the issue.
I noticed this same behavior starting to happen on my Events Manager Pro as well. Seemingly randomly some bookings will show "Processing (Auth.net)" while others show "Completed" (as they should).
From this thread's suggestion, I took a look at my https URLs. I found that sometime in the last month, we ran an update that has inserted some link hrefs and other unsecured URLs in the source code.
I had been using HTTPS plugin to force https on the events pages, but since the site URL was http only, it was pulling in these "external" files as http. I noticed in Firefox that my SSL connection showed broken. While in Chrome, it felt it was secure. My GUESS at this time is that the ones that go thru are where the page in the browser looks to be secure. While the ones that only get "Processing" are happening on the broken SSL browser views.
I've now changed my site URL to https as the base URL which ensures Wordpress uses it throughout. I now don't get a broken SSL in Firefox. My presumption is that this will fix this issue. Time will tell. I'll come back to update IF I'm wrong. But hopefully that might help for you to look at URLs, such as wp-json and other link rel URLs.
Of note, it seems the credit cards ARE authorizing/captured for those transactions. So it's more likely the return trip from Auth.net for the silent URL to changes the status of the booking?