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?
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
we have recently implemented social login to our website. We are running ads to that website and after implementing the social login we lost all conversion data - everything is accounted to facebook.
Also we have kind of "sub-website" shop-domain.com where are some products that are sold separately and user can migrate between domain.com and shop-domain.com and vice versa. Can this loose conversions as well?
My question is:
how can we configure analytics / ads / website to correctly count the conversions?
What have I done:
In google analytics documentation I found something called linker to fix user migration between domains and page referrer after login. But it doesnt seem to help
gtag('config', 'UA-XXXXXXX-1', {
'linker': {
'domains': ['domain.com', 'domain.eu', 'shop-domain.com', 'shop-domain.eu']
},
'page_referrer':'domain.com'
});
Thanks for any suggestions
Honestly, this issue is a bit complicated to solve over a forum discussion like this. You will probably need to hire an expert to audit your setup and look for the cause of the problem.
But let me try giving you some hints and point you in the right direction so that you can debug on your own if you like.
If the Facebook login is the only addition to the code recently and you started seeing conversions credited to it since setting it up, then the probable culprit is that FB login. In that case, one of the possible solutions is to exclude it from referrers in GA, but that might or might not resolve the issue, and it might require bypassing it in some other ways (through GA filters for example).
If the actual problem appeared even before the FB login and the traffic sources for the conversions were not accurate (but back then, some other traffic source was taking the most significant chunk of the conversion sources, and you didn't see it as suspicious), then the something might be happening with the GA setup. In most of the cases, in GA subdomains shouldn't need any Linker parameters for the traffic sources to be credited properly, and you most probably should remove the Linker between them completely. Check if both domain and the subdomain have the cookieDomain set to "auto" and it should be fine.
Recently I've been experiencing a large amount of (what I think is) ghost traffic.
I need help in creating a filter to exclude this traffic from my Google Analytics.
URL's are showing up that have other websites appended to them.
Almost all articles I've read mention including only relevant hostnames but this doesn't seem to apply to my situation.
Here you can see the URL's with other random website addresses.(overworlf.com/evite.com/shmoop.com and many others)
Here is a screenshot of the hostnames none of them are out of the ordinary. I suspect this ghost traffic is using my main domain looking at the huge amount of users.
Posted the same question at stackexchange, someone there was able to help me
https://webmasters.stackexchange.com/a/118666/94264
"Almost all the analytics spammers insert data into your stats by pinging the GA tracker directly with fake data. They never visit your site and they usually just guess at the tracking id without knowing website host name associated with it. They won't send a host name, so it wouldn't appear in that report. See How to fight off Google Analytics referrer spammers?
That appears not be the case here. In this case these appear to be actual hits to your website. I tried one of those "top active pages" and it gives a 404 error. It looks like your 404 template has the GA tricking snippet installed on it. I don't think that is best practice. You could try taking the snippet off your 404 page. Then if you did get actual hits to such URLs, GA wouldn't count them as pages."
This can happen when there are search and replace or advanced filters. Are there filters on your view that alter the Request URI?
EDITED AFTER IT WAS CONFIRMED THAT THERE WERE NO FILTERS:
Typically, tracking 404 pages is best practice (referring to your other post).
I don't believe that removing the tracking from that page will help anyway. Like the other poster mentioned, these hits are sent from bots most of the time and they never actually land on your site. The hit is sent directly to your property with an http call. It bypasses the site completely, so whether there is a 404 page or not, the hit will show up in GA.
Adding an exclusion filter to exclude traffic with a page path (not hostname) ending in ".com"
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.
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.