PayPal Advanced Issues and Smart Buttons Implementation

-- 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.

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);
	}

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);
		}

<!-- 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 -->

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.

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);

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

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!