Like many others, we were frustrated by PayPal's lack of passing traffic source origination and getting all the conversion credit.
However, after adding PP to the referral exclusions list, now all we have is 100% of the conversions coming from direct/none. (We use PP as the exclusive checkout method)
So now while we have traffic that looks clean, the goal completion data is rendered useless as everything is direct/none.
Has anyone found a solution, other than switching to PayPal Pro?
This problem could not be solved by any PayPal configuration. User sessions are being broken before users get to PayPal. Since you're seeing direct traffic and not self-referrals, that means not only is the session being broken, but user continuity. Somewhere in a session on your site they're getting tracked as a new user (thus also inflating your user count).
My guess is that users arrive to the site on HTTP and then switch over to HTTPS (or switch to another domain) for the checkout process. To solve this, you can setup cross domain tracking (which is necessary even if using a single domain if the site is available on both HTTP and HTTPS). An even better option (but possibly a greater lift) would be to move the entire site to HTTPS.
Related
I have read a few questions on here about e-mail clients prefetching URLs in e-mails. An answer to this seems to be to add a new confirmation page, where the user has to click a button to confirm the desired action.
But, this answer states the following:
As of Feb 2017 Outlook (https://outlook.live.com/) scans emails
arriving in your inbox and it sends all found URLs to Bing, to be
indexed by Bing crawler.
This effectively makes all one-time use links like
login/pass-reset/etc useless.
(Users of my service were complaining that one-time login links don't
work for some of them and it appeared that BingPreview/1.0b is hitting
the URL before the user even opens the inbox)
Drupal seems to be experiencing the same problem:
https://www.drupal.org/node/2828034
My major concern is with this statement:
As of Feb 2017 Outlook (https://outlook.live.com/) scans emails
arriving in your inbox and it sends all found URLs to Bing, to be
indexed by Bing crawler.
If this is the case, any URL in an e-mail meant to confirm an action, e.g. confirming a login, subscription, or unsubscription, can end up searchable in a search engine, if that's whats meant by indexed in the quote above. In this case, it's Bing. Not even a dedicated confirmation page where the user confirms the desired action truly mitigates this.
Scenario #1
If I email the user a login link with a one-time token in the URL, that URL will end up in Bing. This token will have a short lifetime, lets say 5 minutes, so I doubt anyone will manage to search on Bing and find the URL before the user clicks it or it expires.
Scenario #2
The user gets an e-mail with a link to confirm a subscription. This link is perhaps valid for 24 hours. This might(?) be long enough for someone else to stumble over the link on a search engine and accidentally (or on purpose) confirm the subscription on behalf of the user.
Scenario #2 is not uncommon, it's even best practice to use double opt-in as far as I am aware.
Scenario #3
Unsubscribe URLs in the bottom of newsletters. Maybe valid for forever? You don't want this publicly searchable in an search engine.
Assume all the one-time confirmation links land on a confirmation page where the user confirms the desired action.
Is it truly the issue that URLs in e-mails are indexed by search engines, at least Bing? And will they actually end up publicly searchable? If not, what is meant by indexed in the quote above?
I'll add for the sake of completion that I don't think I've had much of a problem with this in my own use of the web, so my gut feeling is that this is unlikely the case.
Is it truly the issue that URLs in e-mails are indexed by search engines, at least Bing?
I can't definitely say if they are being indexed or not, only Bing could answer this question, but they are surely being visited, at least with a simple GET request. I just tested this sending myself a link to a page on my website that logs the requests that are made against it, and indeed I'm seeing a GET coming from 207.46.13.181 (reverse DNS says msnbot-207-46-13-181.search.msn.com), which suggests that an automated program from search.msn.com is crawling the link. This leads me to believe that yes, they are trying to index the link's content somehow, but it's only my opinion really.
And will they actually end up publicly searchable? If not, what is meant by "indexed" in the quote above?
Well, again, impossible to say unless you work for Bing. In any case, "indexing" means exactly what you think it does: parsing the content of a page to potentially include it in search results.
The real question here is: does this somehow represent a security problem or will it compromise my website's functionality?
It surely has the potential to: if your confirmation/reset/subscription/whatever process only relies on a single GET request with the appropriate GET parameter, then you should definitely revisit the strategy, as it obviously allows anyone to perform the action (even maliciously for example enumerating possible IDs for your GET parameters).
If the link you are trying to send contains sensible information or can be used to alter important data for an user of your website, then you should at least put it behind a login page only giving access to the interested user. This way, anyone who wants to access it (including search engines) will be redirected to a login page if not already logged in.
If the link you are trying to send is just some kind of harmless confirmation link (e.g. subscribe/unsubscribe from a newsletter), then at least use a form inside the web page to do the actual confirmation through a POST request (possibly also using a CSRF token), otherwise you will unequivocally end up with false positives.
This is leading me into confusion only. After reading Paypal's documentation for Paypal IPN, I know how to get to the Simulator page and trigger an IPN test. Reading throughout PP's documentation, the page I am lead to is:
https://developer.paypal.com/developer/ipnSimulator/
Now, on my server side, I have used one of PP's Listenter example file in which I've implemented my own class to log everything I need into text files, and, I know that my IPN Listener is up, running and receiving requests from the IPN Simulator because I can see it all beeing logged.
Now the intriguing part is that, as I said before, i'm lead to the aforementioned page, which triggers an INVALID response from Paypal every single time I simulate a payment. Afters dozens of forums read, including SO, I have seen some people using https://developer.paypal.com/webapps/developer/applications/ipn_simulator instead of the former one.
If I use this latter URL, the simulation works without a hitch and I get the "VERIFIED" response, everytime. At this point, the question I cannot answer is "Why?". Why does this only works on the latter URL, and not on the URL that I am redirected to from within my paypal account, which is the one I think it was supposed to work from? And this constitutes by itself another problem. I cannot access this latter URL from anywhere within my paypal account, unless I manually enter it. You may question how did I get to this second URL. Well, I got it from other people's posts, otherwise I didn't even know it existed. So, right now I am completly lost and with this said,
Is there anyone that can explain me the difference from both URLs, and why is the second one not available inside my PP account?
If you can also explain me why the simulation works from the second URL only, that would be a bonus
NOTE: By the way, I've tried it and I know that in Live mode it works also, and I get the VERIFIED response.
My question is simple yet I can't find any SO posts or PayPal documentation to answer it.
In the event of a PayPal user having some error being redirected after completing their checkout (internet goes out, browser crashes, they close their browser before the redirect goes through, random networking issues, etc.) How are we suppose to handle that?
I thought using the following REST API
GET /v1/payments/payment/<Payment-Id>
Would solve my problem but since the state returned from this request does not change from created to approved until the funds have been executed it is useless. In the case of having some redirect error you will not have been able to execute the funds and thus it will simply be in the created state still which does not help you.
Additionally I thought maybe PayPals IPN system used for CLASSIC API would be the answer to my problem but again it fails. The IPN system does not contain relevant information such as transaction ID which is needed to link the two systems together.
Is there no way to do automated error handling using the REST API?
We use the https://financialdatafeed.platform.intuit.com/v1/accounts/account_id_goes_here/transactions endpoint on a recurring basis to fetch transactions for all of the accounts we sync. We've been using this stably for quite awhile now, across a wide variety of accounts spanning 100s of financial institutions. This works great.
However, occasionally we get a report from a user who claims that we're not receiving transactions that they know to exist. Our investigation protocol is as follows:
To ask the user if they see the transactions when they sign into their bank's web site directly
To ask them to confirm that the credentials they used on their bank's web site are precisely the ones that they entered when setting up credit card sync on our site
We then manually inspect the response body from the above mentioned URL, to make sure that the HTTPS response indicates HTTP 200 and has a non-error response body (our app catches these errors correctly, but if debugging mysteriously missing transactions, we inspect the response body visually).
We look to see whether we're successfully syncing transactions for any other user that relies on the same FI. If we are, we become confident that both the bank and Intuit APIs are well-behaved, and that the problem is on our end somehow.
We sometimes ask users to try the same FI in Mint, guessing that if it fails in Mint, that it might be a bank or FI issue.
Investigation steps 1-2-3-4-5 tease out the root cause of at least 99% of the times when a user emails us to say that we're not successfully receiving their transactions. However, the remaining 1% are the tricky ones.
Today I'm faced with a situation where a user sees the txns on their bank website, swears that they are using the same creds when adding the card to our site, the HTTP response from the endpoint is HTTP 200 but contains zero transactions, but yet when the user tries via Mint they successfully see transactions.
However, the particular FI (OnPoint Community Credit Union) is not one where I can do investigation step 4, because we have no other users that currently rely on that FI. Is it possible for someone at Intuit to check to see whether there is evidence that users relying on OnPoint Community Credit Union are currently, successfully, retrieving transactions from that particular FI?
Any other suggestions for how to further deduce whether the zero-transaction response is due to: (a) user error, (b) bank server responding incorrectly, (c) Intuit server responding incorrectly, vs (d) our app behaving incorrectly?
Can you please submit a support ticket to Intuit with the Account_ID that is missing the transactions so that we can diagnose the issue? The first place to start when diagnosing the issue is to look at the Agg_status_code to make sure that reflects a '0'. If we are unable to login due to invalid credentials or MFA might be a cause of the missing transactions. I can help diagnose though once a ticket is submitted.
Simple scenario:
I have a signup form, with user name, password, email address, may be credit card number.
At the bottom of the page, I implement the Google Analytics code.
when user clicks submit, it goes to a page wihtout google analytics.
question is..
can GA get the data (user naem, password..email..etc) in the first form after user input the data?
Do they say anything about it in their TOS or Privacy policy?
Yes. Any <script> you include in the page has complete access to alter the user's interaction with the site due to the Same Origin Policy. Google, if they were feeling Evil today, could certainly rewrite the action of your <form> to point to themselves, or log every keypress, or create an <iframe> containing another page on your site and simulate the user clicking on any action in that page.
Do not include <script> on any page from a party you don't completely trust with the security of everything on your site. Even a single tracking or advertiser script on any page compromises everything on the same hostname (and maybe other subdomains if you are setting window.domain to allow cross-hostname-scripting, or sharing cookies between hostnames).
However, the Analytics script doesn't currently do any of these things and the form submission will not flow to Google as a matter of course; they would have to deliberately act to steal the data. Clearly it would be disastrous for them to be discovered doing it, so they presumably won't. But technically, they could. It always pains me to see third-party ad and tracking scripts on bank sites.
UPDATE: The landscape has changed quite a bit over the years since my original answer below was written: the scripts are now generally served (or at least have the option to be fetched) over HTTPS, so those scripts should be secure against the trivial man-in-the-middle attacks. However, you are still trusting the script source not to do malicious stuff in your page, since they still get to fully control what happens on your web page.
Original answer:
Yes. I recommend against putting any third party script on sensitive pages secured by SSL. It's not likely that Google is going to hijack sensitive data on your page but you should take into account the possibility that a malicious ISP can hijack the request (say, using DNS) to Google Analytics script and do whatever it wants on your page.