PayPal Advanced Issues and Smart Buttons Implementation

  • Posts: 303
  • Thank you received: 18
  • Hikashop Business
3 years 3 months ago #326911

-- HikaShop version -- : 4.4.0
-- Joomla version -- : 3.9.23

I've had several issues concerning Google Analytics not receiving data with the normal Paypal payment gateway (customer redirected to website after 10 seconds and not immediately so no data transferred) and issues with loading time (> 4 seconds to load the iframe) and styling for the iframe display in Paypal Advanced. Is the loading time for PayPal Advanced iframe normal? If i switch the form view, the load time is instantaneous. Additionally, this payment processor takes much longer to submit payment than normal paypal. If normal paypal could be configured to auto redirect immediately, that would be ideal to ensure GA information is passed back to the website.


Are there any plans to upgrade existing paypal payment methods to include the new smart buttons?

Demo:
demo.paypal.com/us/demo/go_platform/pcRe...entV2/paymentOptions

Implementation documentation:
developer.paypal.com/docs/checkout/#integration-options
developer.paypal.com/docs/checkout/integrate/

It seems like the new smart button implementation would bypass the need for redirects and truly utilize a one page checkout for the paypal payment method.

Please Log in or Create an account to join the conversation.

  • Posts: 81361
  • Thank you received: 13037
  • MODERATOR
3 years 3 months ago #326933

Hi,

PayPal pro and PayPal advanced already allow for payment without the need for redirects.

The fact that the loading or submitting of the payment takes a lot of time is related to what PayPal does behind the scenes. HikaShop is not involved with that so we can't do anything about it.

Regarding the auto redirect back to the shop, it seems that PayPal has a setting for that:
stackoverflow.com/questions/11536393/red...-completed-in-paypal
I would recommend to check with PayPal's support.
Also, another comment recommends adding an "rm" parameter to the form for that. The "Return method" setting in the PayPal payment method is actually for that. So you might want to try switching that parameter.

Also, regarding GA, being redirected back after the payment won't trigger the sending of the statistics only if you're using the "javascript" mode of GA. If you use the "direct call" mode, then HikaShop will send a request to GA when the IPN from PayPal is received by the website. That way, regardless of what the customer does at the end of the payment process, GA will be notified.
So your solution might be to review the settings of your GA plugin to activate/force the direct call mode.

You can't upgrade a plugin. It's a completely different API so it requires a completely different plugin to be developed from scratch, like we already did for half a dozen of PayPal APIs throughout the years.
Regarding the development of a "PayPal Checkout" plugin, that's something we could work on in the future. But will all the plugins already available for PayPal, you already have a lot of possibilities so such development wouldn't help that much.
Ideally, it would be great if a third party developer would focus on such a plugin. That way our time would be better spent in improving parts of HikaShop that only us can work on.

Please Log in or Create an account to join the conversation.

  • Posts: 303
  • Thank you received: 18
  • Hikashop Business
3 years 3 months ago #326987

Thanks Nicolas.

1. The auto redirects is already enabled, but there is a 10 second delay before redirect. I also have payment data transfer option enabled. Return URL set in paypal: www.mojooutdoors.com/index.php?option=co...end?utm_nooverride=1

2. In previous correspondence, we added the following function to my hikashopanalytics.php file just after the "onAfterOrderUpdate" function

public function onHikashopOrderTrackingDisplay(&$order) {
		if(isset($order->order_type) && $order->order_type != 'sale')
		return;

		return $this->checkOrder($order, false);
	}

and turned off the direct call method inside the "GoogleProcess" function
if($this->params->get('use_universal', 0)) {
			$call = (int)$this->params->get('universal_always_directcall', 0);
			if($call && $render)
				return true;

			if(!$call && !hikashop_isClient('administrator')) {
				$ctrl = hikaInput::get()->getCmd('ctrl', '');
				$task = hikaInput::get()->getCmd('task', '');
				if($ctrl == 'checkout' && $task == 'notify')
					$call = true;
			}

            /* Holden Addition */
            
			//if($call)
            //return $this->googleDirectCall($accounts, $order, $currencyInfo);
		}

After making these changes, the source/channel/medium info displays properly inside GA. However, i've noticed that not all orders get sent to GA, hence the inquiry about (instant) auto redirect. Under the current implementation, if the user closes their browser before the 10 second redirect, then the GA packet is not sent/received.

Tonight, i tried using the latest hikashopanalytics plugin with the following options enabled (the rest are disabled):

1. Use universal
2. Single Submission
3. Always Use Direct Call

In the paypal plugin, i have the following options enabled (the rest are disabled):

1. Send Details of the Order
2. Allow Notifications
3. Address Override
4. Return Method

I do not have anything for the "return url" field as that is handled on the paypal account portal side.

I attempted to place several orders after clearing all cookies from my browser (to prevent any residuals). For all orders with stock hikashopanalytics.php and direct call option turned on, i'm showing orders logged in GA, but every orders shows up as channel = (other) and source/medium = (not set)/(not set). Without this additional information, GA is pretty much useless for tracking orders.

For the GA code on my side, i am loading it via index.php file:
<!-- Google Analytics -->
<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-XXXXXXXXX-X', 'auto');
ga('send', 'pageview');
</script>
<script async src='https://www.google-analytics.com/analytics.js'></script>
<!-- End Google Analytics -->

Throughout checkout on my test purchases, i can track my progress through GA and see the source/medium is being logged properly, but it seems to break somewhere between leaving the site to go to paypal and returning back to the website. I'm not entirely sure why the direct call method doesn't seem to work for my website. I've even stripped our test server down to stock template and played with the options which gave the same results.

Am i missing something? This has been an odd problem we've been troubleshooting for over a year now. Usually, the GA order tracking just works out of the box, so i'm not sure what's special about our setup.

I can provide super user and/or FTP access if that helps to poke around the backend.

Last edit: 3 years 3 months ago by mojooutdoors-holden. Reason: Typo

Please Log in or Create an account to join the conversation.

  • Posts: 303
  • Thank you received: 18
  • Hikashop Business
3 years 3 months ago #327348

Any updates on this issue? I know you guys get tons of requests per week, but I wanted to make sure this one didn't get lost.

After additional testing, it seems like the GA tracking values are changing when using the direct call method with the original hikashopanalytics.php plugin. I don't have a good handle on what's going on, but something breaks between leaving the website and sending the payment notification back to the website. The customer session info has the correct info before leaving to go to paypal, and i can track it successfully up to that point. When the payment is received or customer returns to website, the session info has changed the source/medium to (not set) / (not set).

This does not occur if direct call is turned off and other changes mentioned in previous reply have been applied to the plugin. However, only about half of the orders are logged in GA since it requires customer to successfully return to website.

Last edit: 3 years 3 months ago by mojooutdoors-holden.

Please Log in or Create an account to join the conversation.

  • Posts: 303
  • Thank you received: 18
  • Hikashop Business
3 years 3 months ago #327508

I think I've just about isolated the issue. I performed tons of test purchases, watching the cookie contents change before redirection to paypal and after redirection back to the website.

With direct call disabled and commented out in function "googleProcess":

//if($call)
            //return $this->googleDirectCall($accounts, $order, $currencyInfo);

everything works properly. Either the session info is pulled properly from the UTM parameters or pulled from the __utmz cookie. However, one of two things happen:

1. Customer successfully redirects to website after payment on paypal (auto redirect takes a little over 10 seconds) and all session info is logged properly with the transaction.
2. Customer does not redirect and not transaction data is logged in Google analytics (makes sense).

However, with direct call turned on and the above code is uncommented, the transaction data in google analytics lacks all session info. Since customer doesn't need to redirect back to website, transaction data is sent automatically when payment notification is sent from paypal to website. Two weird things happen:

1. If UTM parameters are specified, everything is logged properly.
2. If UTM parameters are not specified, the session info from the __utmz cookie is not sent properly with the transaction. I'm not sure why this would not break, but it seems to be related to using the __utmz cookie info in the direct call. Perhaps the __utmz cookie parameters aren't being used properly in the googleDirectCall function?

If the __utmz cookie hypothesis doesn't explain the issue, I'm all out of ideas... Is there a way to see the full array sent to Google Analytics when transaction is complete? If the result is empty fields for the case where UTM parameters are not specified in the URL, that would confirm that the __utmz params are not being pulled into the direct call method?

Please Log in or Create an account to join the conversation.

  • Posts: 303
  • Thank you received: 18
  • Hikashop Business
3 years 3 months ago #327564

I believe i have solved the issue. Universal analytics does not create any cookies:

stackoverflow.com/questions/18604715/goo...-missing-utmz-cookie

In hikashopanalytics.php, the campaign name, source, medium, etc. is being pulled in via the __utmz cookie which apparently was how ga.js (old google analytics) stored session/campaign info. In the googledirectcall function, the session/campaign info is being scraped from the __utmz cookie or utm tracking parameters and sent along with the transaction info. In the case of UTM tracking parameters in the link, everything is fine since you can override session info just like you have it currently set up:

$data = array(
			'v' => 1,
			'tid' => $account,
			'uip' => $order->order_ip,
			'cid' => @$params['uuid'], // clientId
			'ua' => @$params['ua'], // user-agent from browser : navigator.userAgent
            'cn' => @$params['cn'], // campaignName
			'cs' => @$params['cs'], // campaignSource
			'cm' => @$params['cm'], // campaignMedium
			'ck' => @$params['ck'], // campaignKeyword
			'cc' => @$params['cc'], // campaignContent
			'ci' => @$params['ci'], // campaignId
			'ul' => @$params['ul'], // language

However, in the case of no UTM tracking parameters in the URL, a packet with empty values for session info was being sent to google analytics:



Therefore, if I comment out the campaign specific information, all tracking in google analytics works perfectly (since nothing is overwritten) and all transaction show up now since the customer does not have to redirect back to the website. I kept wondering why everything looked fine before and after payment, but the transaction itself had the wrong campaign/session info. I will continue to monitor over the next 24 hours to make sure everything is logging correctly before closing this issue on my end.

It seems analytics.js is a lot smarter than ga.js. However, Google tag manager (gtag.js) is a lot smarter than both of these, and might be a viable path forward since analytics.js can be loaded through tag manager.

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 81361
  • Thank you received: 13037
  • MODERATOR
3 years 3 months ago #327598

Hi,

Thanks for your research on the subject.
I must say that I'm not familiar with GA and its API, and it seems that they changed stuff over the years with different ways of going things so it's starting to be a big mess.

If I understand correctly, you mean that you removed the lines:

'cn' => @$params['cn'], // campaignName
			'cs' => @$params['cs'], // campaignSource
			'cm' => @$params['cm'], // campaignMedium
			'ck' => @$params['ck'], // campaignKeyword
			'cc' => @$params['cc'], // campaignContent
			'ci' => @$params['ci'], // campaignId
from the googleDirectCall function and then it worked fine because the values in $params were empty and adding these variables meant that GA would override the value it already had on its end by an empty value ?
In that case, I suppose that the best would be to add a check to only add them to the $data array if they are not empty.

The following user(s) said Thank You: mojooutdoors-holden

Please Log in or Create an account to join the conversation.

  • Posts: 303
  • Thank you received: 18
  • Hikashop Business
3 years 3 months ago #327615

That is correct. However, a much more elegant method would be to check if empty as you mentioned.

The API for ga.js and analytics.js is highly confusing. With gtag.js, everything is supposed to be more simplified. I plan on trying to make a hikashopanalytics.php implementation using gtag since most of the configuration is done through the google tag manager and little has to be managed on the website itself.

At any rate, i would at least check if the @$params is empty or not before setting the campaign specific info in the transaction packet sent to GA. I would imagine this particular issue affects anyone who upgraded to analytics.js (universal analytics). Very annoying problem that's taken a long time to wrap my head around.

Wouldn't have been possible without your previous changes with implementing the __utmz cookie check. Ultimately, this is what led me to the solution. Thanks again!

Please Log in or Create an account to join the conversation.

  • Posts: 81361
  • Thank you received: 13037
  • MODERATOR
3 years 3 months ago #327659

Hi,

Great.
Thanks for working with us on this issue.
Here is the code we'll have in there starting next version:

		$data = array(
			'v' => 1,
			'tid' => $account,
			'uip' => $order->order_ip,
			'cid' => @$params['uuid'], // clientId

			't' => 'transaction',
			'ti' => $order->order_id, // order_id
			'ta' => $siteName,
			'tr' => round($this->convertPrices($order->order_full_price, $currencyInfo->currency_code, $to_currency), 2),
			'tt' => round($this->convertPrices(($order->order_subtotal - $order->order_subtotal_no_vat) + $order->order_shipping_tax + $order->order_discount_tax, $currencyInfo->currency_code, $to_currency), 2),
			'ts' => round($this->convertPrices($order->order_shipping_price, $currencyInfo->currency_code, $to_currency), 2),
			'cu' => $to_currency
		);

		// adding variables only if not empty to avoid overwriting them on GA's side
		$variables = array(
			'ua', // user-agent from browser : navigator.userAgent
			'cn', // campaignName
			'cs', // campaignSource
			'cm', // campaignMedium
			'ck', // campaignKeyword
			'cc', // campaignContent
			'ci', // campaignId
			'ul', // language
		);
		foreach($variables as $variable) {
			if(!empty($params[$variable])) {
				$data[$variable] = $params[$variable];
			}
		}

Please Log in or Create an account to join the conversation.

Time to create page: 0.067 seconds
Powered by Kunena Forum