In our Google Analytics ecommerce PayPal is getting credit as the referrer. I've found many articles outlining use on the utmnooveride to ensure PayPal transactions pass the data so that the original referrer gets credit.
We use PayPal to process our credit cards as well as allow people to pay with their PayPal account. When a visitor pays with credit card they never leave our site, so we are only seeing this inaccuracy when a user leaves our site to pay with their PayPal account.
More accurately we are using PayPal express checkout and using NVP (name value pair) API. https://developer.paypal.com/docs/classic/api/NVPAPIOverview/
We've implemented the suggestions and code changes we have found but PayPal is still getting credit.
We've even talked with PayPal and Google techs and aren't getting any thing more from them than what we are finding online.
Is anyone else encountering this issue, have you found a solution or have any suggestions? Your help is much appreciated.
-- Solution Update --
Moved to the answers.
Per request.. I am moving the answer from a followup in the question to the actual answer.
Based on some various articles on how to improve accuracy of data reporting I just happened to be messing with property settings in Analytics and came across the Referral Exclusion List. I've mostly used this to just cancel out links from other sites in our domain structure; subdoimain.foosite.com -> foosite.com, but decided to investigate adding PayPal to this and came across this support doc from Google.
After reading that article I wondered what would happen. The result = NO MORE PAYPAL referrals and referrals from the original source without having to worry about utm=nooverride=1 usage.
I have verified with a Google support specialist that the below has no negative effects on ecommerce reporting and they have submitted my case to their help team for future use. He also mentioned that this methodology actually recently added which is why there is little documentation about it.
Here is how.
Make sure you are using Universal Analytics
Admin -> Property Settings -> Tracking Info -> Referral Exclusion List
Add Referral Exclusion
Insert referral domain - my case was paypal.com but you may have this issue with others - key here is to identify any domain that might be hijacking ecommerce transactions. So if you are seeing anything that has ecommerce credit that you don't think should; add it
This should solve the problem but I would suggest taking things a few steps further.
Adjust your session settings. Admin -> Property Settings -> Tracking Info -> Session Settings
A few notes about session settings- depending on your site and how users engage I would initially adjust the session timeout so that session is longer than 30 mins. I set mine to 2 hours for testing. Then for campaign timeout I set it 1 day (much shorter time than our normal campaigns.
This allowed me to initially see that it was indeed eliminating PayPal from the referral source and but that my transactions in GA matched my internal reports.
After verification I set the session timeout to 45 mins - 15 mins longer than our site session settings and set the campaign timeout to 7 days.
Make use of Google URL builder and add parameters to your URLs.
This is not only good practice it saves you tons of time trying to segment out your referral sources in GA. It is especially helpful if you collect acquisition source in your internal reports or logs because you can compare those to GA to ensure you are getting accurate ecomm numbers from GA.
Let me share my experience with the 'referral exclusion list' in UA:
I added paypal.com and another similar payment provider to the list.
Consequence:
The traffic attributed to those referrers was reduced from that moment on - but far from beeing zero. (Let's say it was halfed.)
No idea why it is working for parts of the traffic only.
Just wanted to add my answer in case anyone comes across this same issue.
From my understanding the following no longer works with newer GA code:
utm_nooverride=1
However if you pass the _ga parameter google analytics will be able to relate the two instances before being transferred to paypal. Okay great so all you have to do is add the _ga parameter to the return URL...but how do you get it?
Unfortunately you need to grab it client side first:
ga(function(tracker) {
var linkerParam = tracker.get('linkerParam');
});
Hope this helps someone.
Reference
https://ecommerce.shopify.com/c/ecommerce-marketing/t/tracking-true-referrals-in-google-analytics-when-using-paypal-163514
https://developers.google.com/analytics/devguides/collection/analyticsjs/cross-domain
I just wanted to add my experience. I have been having the very same problem, and as you have mentioned the solution is putting paypal.com on the Referral Exclusion List. You must be upgraded to the new Google Universal Analytics in order for to have access to it.
Related
I have been working on the following workflow using Paypal Payments.
My intent is to send the Customer to the Guest-Payment-Website. He should not see paypals login-page at first.
This is because many people do not know that they can pay with Creditcard or Bank-Transfer without registering an Account.
I had my whole process tested within the sandbox and it worked. Then I changed to the live-version and $flowConfig->setLandingPageType("billing"); it is not affecting the landing-page anymore.
Workflow:
I prepare some new Webprofile() which is setting things on paypals payment-approval-site (logo etc., shopname). It is saved once and identified by some string (XX-XXXX-XXXX-XXXX-XXX)
I prepare a transaction and send it to paypal.
Then the Customer is sent to the specific payment-approval-site on paypal.com
the customer should put in his authentication there
the customer is sent back to my website
To preset visual options I predefine some Webprofile.
$flowConfig = new \PayPal\Api\FlowConfig();
$flowConfig->setLandingPageType("billing");
$presentation= new \PayPal\Api\Presentation();
...
$inputFields= new \PayPal\Api\InputFields();
...
$webProfile = new \PayPal\Api\WebProfile();
$webProfile->setName("GuestPaymentProfileNameasdf")
->setFlowConfig($flowConfig)
->setPresentation($presentation)
->setInputFields($inputFields);
$webProfile->create($APIauth)
This create-command is giving back some string (XX-XXXX-XXXX-XXXX-XXX) which is saved within paypal to identify this set of options i put into the system.
...
$payment->setExperienceProfileId('XX-XXXX-XXXX-XXXX-XXX'); //profile ID
...
Does anyone know what I could do wrong here? As written, this is totally working within the Sandbox but when I switch to LIVE the customer always is sent to the normal login-page.
Is there some other method to do this?
Did I miss some hint or depreached sign?
I have been working on this and the cause of this behaviour seems to be the limitation of my Paypal-Account within Germany.
At first I was able to buy as a guest. Then this option vanished - probably with the expiring of my sandbox-infused cookie.
So I called the support of Paypal today and asked some specific questions.
I had other expectations about this guest-buy-functionality, because I got used to the unlimited US-Sandbox-Account. My personal mixup might be caused by a possible internal mixup of options / restrictions / limitations when you change from the unlimited sandbox to your restricted live-account.
The Thing is, that I should not have seen this guest-billing-page within germany - but it worked... once after going live.
We have used DoDirectMethod to credit card payment and recurring payment with CreateRecurringPaymentsProfile Method. But Some how i can not get error "This transaction cannot be processed due to an invalid merchant configuration.".
I found some solution for this :
1)I have problem like : Features that are not enabled for live transactions
2) If for use of REST API ,
I need to change my country then how can i change country or currency.
3) In paypal errorcode i found : Occurs when you have not agreed to the billing agreement.
- Then how can i agreed billing agrrement- need steps for it.
Please help me by providing steps of configuration or any other solution.
PayPal is confusing peoples/developers completely, i am also getting the same issue from one month on one of our client's website, i was used DoDirectPayment, and it works like a charm for test transactions, but as i make it LIVE it is was showing the same issue, i found that too, to performing transactions in LIVE mode we need to 'Enable' this feature for Direct Credit Cards, but many times i requested them (PayPal) to enable that feature, but all time they just received my Application Online and reponsed that it will take about 24 hours. I have also added extra information like SSN, EIN all that but they are so lazy or not active to do that.
At one point they are saying we need Website Payments Pro but i have not found a single link to register that, I found PayPal Payments Pro link at many sites and even in their site, these guys have a huge documentation on that website payments pro and dodirect method but not a single link how to register for that service or how they enable that feature for 'Live' mode.
And today i found they updated their developers site and make things a little different, also provided an extra method "braintreegateway" in order to process, and i tried that too using their sandbox account, its working with only PHP 5.4 and above, so old PHP version servers are unable to get that. And they also need to register your details at their end.
If i have already a PayPal Business account why do i need to register at every single method.
Sucked
When testing some donations on my local machine, I set various key=value pairs to do various things (return to specific thank you page, get POST data from PayPal and not GET data and others) I also built my code around the response from the PayPal sandbox.
BUT, when my code goes to the production server and we switch on live payments and test with real accounts and money, a few strange things happen;
We get a GET response from PayPal - the URL is filled with crap.
We get no transaction details. This is the biggie, no name, no txn_id, no dates, nothing. We get a handful of keys etc, its not totally empty and the payment has gone through, but nowhere near the verbosity of the sandbox.
Curious about why this might be? It doesn't really make sense to have a sandbox (or dev environment) that is substantially different from the production environment. Or, am I missing something?
EDIT: Still no response to my question in the PayPal Developer Forums. I don't even get a donation amount back from PayPal. Is this a setting maybe?
EDIT #2: Two of you have suggested to check PDT and Auto-Return. The data analytics guy for the project only 2 hrs ago suggested the same. I have asked the client to confirm this. I can't see a setting for it in the Sandbox so can assume that it is enabled by default?
Are you sure you have all of the PDT and Auto-Return stuff configured the same on your live account as you do on the Sandbox account? There hasn't been much help from PayPal in the x.com forums. I'd recommend posting a ticket to www.paypal.com/mts, although, they've been a little bit slow there, too. If you login to your account, though, and go into the Contact by Phone section, you'll see a direct phone number for tech support. This is probably your best bet.
I'm designing a database system, which sells courses to students. This is all done within PHP. I want to take Paypal payments on my website and having done some research I need IPN.
I've been reading docs/guides on how to achieve this from www.x.com but its quite confusing to find info I need as there seems to be more than one way of doing something. The IPN stuff looks pretty straight forward, paypal just needs the unique Invoice number, which the notify script uses to retrieve the record and post the appropriate response into a database and if all goes well, redirect page to a thank you.
The thing is which method do I initially send my values across to Paypal, I don't really want to pass on quantity and shipping data as all of these pieces of data are irrelevant I don't want my end user to see. Do I have to start looking at using the paypal api?
Thanks for the advice
Since your question seems to be "where should i start looking for a good paypal integration with php" i'll give you some general "advice". I had the same problem just a couple of months ago.
Yes you've to read paypal docs, and unfortunatly they don't have the gift of clarity.. very complete but i didn't find them very clear.
However this php class has been very helpful for my similar project: https://github.com/Quixotix/PHP-PayPal-IPN hope can help you too.
Also these articles/classes/docs has been helpful (but at the end i'm not using them) to clear my mind about PP integration:
http://drewjoh.com/wiki/code/classes/phppaypal
http://www.geekality.net/2011/05/28/php-tutorial-paypal-instant-payment-notification-ipn/
set up a sandbox account https://developer.paypal.com/
then go through some of the tutorials
you will also need to set up some test accounts, pay attention to the nav on the left (from the developers page). It has everything you need
Been integrating AuthNet's Automated Recurring Billing system alongside its Silent Post feature to create a paid features system inside our team's web app. The silent post feature has slim documentation, but I have come across several helpful threads on SO as well as a few blog posts authored by our members (especially John Conde's "All about Silent Post" ) to help guide the way. I have a few more specialized questions however I was hoping some of you more seasoned folks could help out with.
The Authorize.net documentation includes this notification:
Test environment accounts do not process ARB subscription transactions. If you are using
a test environment account, you will not receive these email notifications in any form. You
will also not be able to receive an ARB subscription transaction Silent Post while using a
test environment account.
I was wondering if anyone knew if this means accounts set to TEST MODE in their control panels, or does this refer to the developer-only accounts available to those working on AuthNet platforms independent of deployments? The account we are using for testing is an actual merchant account set in test mode and we're receiving silent posts for virtual terminal payments done through the AuthNet CP, but even successful ARB's are not showing silent posts.
Also - what kind of parameters can be used to ensure that a silent post originated with AuthNet? I set up an endpoint and printed out the request objects from a silent post as well as the $_SERVER superglobal - it does not seem that they send any identification other than the MD5 hash set in the CP. This is fine, but I was wondering if there would be any advantage to limiting to specific remote addresses - I assume this is unlikely as the posts probably come from a datacenter with tons of IPs allocated for the task of sending silent posts.
Also, the ARB spec only sets a subscription status to SUSPENDED within AuthNet under very specific criteria (only if the failed payment is the first rebill and if not then after two attempts on subsequent days.) Is this a normal practice for suspending subscriptions? If we would like to make one decline trigger suspension, should the logic for revoking the feature also issue an UpdateSubscription API call and set to suspension manually in order to forgo the default spec?
I was wondering if anyone knew if this
means accounts set to TEST MODE in
their control panels, or does this
refer to the developer-only accounts
available to those working on AuthNet
platforms independent of deployments?
This refers to both. Any test ARB transactions will never be processed and not generate Silent Posts. It's probably why their developer forums are riddled with questions about testing ARB. Basically, the best you can do when testing it, besides setting up a live subscription, is to:
Test the API call by using a developer account. If you get a subscription ID back you know your integration is functioning properly.
Test Silent Post by sending a simulated POST submission to it. I can post a sample form for doing this.
Also - what kind of parameters can be
used to ensure that a silent post
originated with AuthNet?
The MD5 hash returned in the silent post is a hash of a string that includes an MD5 hash value (set in security settings) that presumably only Authorize and you know. Thus, you generate a hash on your end using the returned info plus the secret hash string and compare to validate the response. Specifics about the hash can be found here.
Is this a normal practice for
suspending subscriptions?
Normal practice? Honestly I don't know. I'm not sure how other companies handle it. There's a post somewhere in their community forums where an Authnet employee explains how it works but I was unable to find it to link to it here. It made sense to me when I read it.
If we would
like to make one decline trigger
suspension, should the logic for
revoking the feature also issue an
UpdateSubscription API call and set to
suspension manually in order to forgo
the default spec?
If a subscription fails it is automatically suspended by Authorize.Net so you don't have to do anything on your end. But you do need to update your user's account in your system and suspend it (assuming the subscription is for a user account of some kind).