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.
Related
I'm trying to complete a transaction on paypal sandbox and my request always return timeout error.
I've look everywhere for this problem that seems to be pretty recurrent but no solutions seems to work for me.
Thanks!
Finally, I've found solutions to my problem.
as pointed out by ppmtscory on the php-Paypal-SKD github forum, you shoud not use credit card number 4111111111111111 because it as been overused and it is flagged as so in the system and cause this type of behavior.
https://github.com/paypal/PayPal-PHP-SDK/issues/519
#artisangang I will be closing this issue as it doesn't have to do with the SDK itself. This is due to the specific testing card number being overused in the system causing a timeout. #pp-randy has already filed the internal ticket to do a DB update to try and correct this for the sandbox environment but it's not something that will likely get very high priority. If you need test credit cards, please visit this page and utilize Step 4.
I wondered if I could request some assistance. We had some code written by an external contractor to allow us to automatically set up billing agreements in paypal (client approves and future requests are automatically paid).
We have a sandbox environment making a call via https://www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=
This works fine.
In production this was changed to https://api.paypal.com/webscr?cmd=_express-checkout&token=
This hangs.
I have updated the username, password and signature to production values, but we still have the same issue.
I also spent a lot of time reading through a lot of developer docs, but found them to be quite difficult to understand.
I also submitted a paypal "App" request for approval (this seemed to be required in the docs), and it has been approved. However it says we should provide the production App ID when making a request, but there is no argument to do it.
Any assistance appreciated.
The first URL you show looks like that would be the redirect to PayPal, not the actual API endpoint.
The endpoint URLs should be...
Sandbox: https://api-3t.sandbox.paypal.com/nvp
Live: https://api-3t.paypal.com/nvp
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.
I'm putting sagepay into a PHP powered site.
So far I've had no trouble integrating the Form into the site, their docs are great compared to paypal (mutter mutter)
However I noticed in the dev guide for form integration, they say you can't rely on sagepay sending the customer back every time as they could close the browser, or navigate somewhere else etc.
At the same time, I don't want to move everything out of the user's cart and into an order before I know it's been confirmed / payed for - otherwise if they cancel or the transaction fails somehow on sagepay's end, their cart will be wiped out when they come back, making retrying the transaction a pain for the user, and I will have a duff order polluting my database.
So what I want to know is if there is a way to get sagepay to send a request to the site when something happens with a payment, similar to paypal's Instant Payment Notifications?
EDIT:
Or are they only saying it's patchy because they can't garuantee it, but it works enough of the time to practically rely on it?
Sagepay (AKA Protx) form integration redirects the user automatically once the transaction has completed.
For small sites, i advise my clients to always check the sagepay transaction logs (on the sagepay site) before sending out any goods.
You should be logging the order before they go to Sagepay. Then changing it's "status" to paid when they get redirected back to your site. This gives you a bit more of a paper trail to pick up any possible issues.
If you want a more robust solution. Try Sagepay direct integration. It has more requirements and is harder to integrate but on bigger projects (where you can't manually check orders) it's usually required. Mainly because users can stay on-site without having to go off to Sagepay to make payments.
I am developing a website in PHP that accepts PayPal payments. It uses the IPN from PayPal and has a custom payment template etc etc. It all works great through the Sandbox server but when it comes to showing my client, I don't want to have to tell them to login to/create a Sandbox account, create a buyer account and make a payment - he hasn't got time for that and probably won't be able to do it.
Therefore, my question is - is there any simple way that I can show my client the PayPal integration in "test mode" without him using the sandbox? I realise that I can set the transaction value to 0.01 and just test on the live PayPal server but that isn't an ideal solution.
Cheers!
Edit: Just to better explain what I mean, this is what my client sees when he first goes to checkout;
alt text http://img3.imageshack.us/img3/2545/67913734.png
As you can see, he has to login to his Sandbox account before then purchasing the item using the buyer email that he sets up. It's just confusing and totally non user-friendly.
Unfortunately there isn't a way around this problem via paypal. Their sandbox will always require you to be logged in to actually demo.
Here are the solutions I have taken especially with remote clients.
Use Skype or similar service so I can share my screen as I demo how it works. This solution seems to work fairly well, and eliminates the need for them to take the extra steps required.
When working on something I want to quick demo for a client and get their take, I have started using http://www.jingproject.com/ It allows me to make a quick video of the process. It uploads it to their server and provides a url I can send the client to watch what I did.
Wish I could provide a more elegant solution.
What I'd do is integrate with the actual PayPal live site and use real money. The great thing is you can refund the transaction (including the fees) so nobody pays anything. I believe the refund timeframe is 30 days, but there's no reason to wait too long and risk it. The added advantage is that you get to prove to your client that the PayPal integration really works.
If there's a concern with littering the seller account with test transactions and refunds then go ahead and set up a separate seller account. It's quick to set up as long as you don't expect your test account to be receiving thousands of dollars.