Kryptronic Software Support Forum

Edit the file {private}/apps/ecom/ECOM/includes/coshipinfo.php.  At the bottom of the file you will see all the links being printed for shipping address changes starting with a return statement for backend displays:

// +--
// | Don't print links for BackEnd requests.
// +--

if (!(empty($isbackend))) {return 1;}

Right below that, add:

if ($cosess['gateway_select'] == 'paypalproe') {return 1;}

That should suppress the links on the checkout page when PayPal Website Payments Pro Express (express checkout) is selected.

sdn wrote:

Great, that works but the "Update Billing Information" link is still there. Is there any way to also remove that one?

In {private}/apps/ecom/ECOM/includes/cobillinfo.php, right below:

if (!(empty($isbackend))) {return 1;}

Add:

$cosess = $this->globals('ecom.checkout_cosess');
if ($cosess['gateway_select'] == 'paypalproe') {return 1;}

And that would suppress the billing info change links in checkout for PayPal Website Payments Pro Express Checkout orders.

The second piece of code did not remove the "Update Billing Information" link. It removes the "Deliver to a Different Address" link only. The problem with "Update Billing Information" link is that you can also change the delivery address when doing a guest checkout. If you are logged into an account it only shows the billing address fields.

However, it highlights a problem outlined in post #12 onwards at https://forum.kryptronic.com/viewtopic.php?id=33881
My test account populated the delivery address with a one-time address and the new code stopped me from changing it so I have removed the new code. One problem solved and a new worse one created.

Still, plenty of time to think about it now we are all in COVID-19 lockdown in the UK. Pray that it does not take hold in the US…

Can the cart be made to use the information provided by PayPal to populate the Billing and Delivery address fields for Express checkouts rather than reverting back to previous session data? Is there a reason it does not do that anyway?

Last edited by sdn (03-24-2020 09:17:08)

When logged into an account and doing a PayPal Express checkout, the debug output shows that the delivery address is being pulled from "CORE_Session::sessupdate: BULK session update:" and not the SOAP address information provided by PayPal in "ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/". The delivery address was not the one last used though.

When logged out of the account, the billing and delivery address match the PayPal SOAP data.

I have also noticed that if you update the delivery address, you break out of the Express checkout process and revert to a conventional checkout with PayPal standard and card payment radio buttons and a "Continue" button rather than the "Process Payment" button to complete the Express checkout which is going to confuse people.

Last edited by sdn (03-25-2020 07:08:49)

Could the code be amended so that it populates both the billing and delivery address fields with the same information? I assume this code does just the billing address fields?

$addbook = $this->globals('core_session.addbook'); if ((empty($addbook)) || (!(is_array($addbook)))) {$addbook = array();}
$hash           = md5(serialize($addy));
$addbook[$hash] = $addy;
$sessiondata['addbook']         = $addbook;
$sessiondata['addbook_billing'] = $hash;

Last edited by sdn (04-03-2020 07:41:22)

Yes, paypalproe.php

We are having this issue as well

OK, good. Is there a release date for this update.

On a similar issue, we see the occasional card payment failures where SagePay reports error "4002 : An active transaction with this VendorTxCode has been found but the Amount is different.".

We think this happens when a customer backs out of SagePay screen using the browser back button rather than the onscreen "Cancel" link.

Does K9 recognise this has happened and then generates a new VendorTxCode?

OK, good again :-)

The SagePay issue looks to have been caused by the following events:

Customer enters SagePay Form page.
Customers backs out of the form and back to our site.
Customer changes the delivery method and the order value changes.
Customer goes back into SagePay but gets an error because K9 reuses the original VendorTX code but the order value is different.

Is that also your take on the what needs to be addressed?

It appears to be changing the Amount requested that upsets SagePay rather than backing in and out with the Amount unchanged. I have done a bit of testing and found that to be the case so maybe that is an easier solution for you to work on.

I tried testing on three different browsers on the same PC with different baskets (logging into the same user account) and got an error on two as the amounts were different to the first. Once I made the other baskets the same as the first, I could back in and out of SagePay without any problem.

Last edited by sdn (04-16-2020 04:01:16)

NIck

Have you got a temporary fix for the sagepay order number issue? so a new order number is generated if user backs out of payment page and changes order value?

Thanks
Rob

Hello,

Are you still planing a solution in the 9.1.0 update for SagePay and PayPal express?

Thanks, Richard