Update your PayPal buttons before 29th March 2017.......

[Lakshmana]

================================

Updating thread title to reflect the new date of March 29th.

Please note that we have extended the go live date for this until March 29th. Any questions related to updating the buttons and HTML basics related to this upgrade please post here.

================================

HI,

I received this email from PayPal..

Update your PayPal buttons before 18 January 2017

In January, we'll be upgrading the PayPal integration you're using, Website Payments Standard, to:

• Let your customers check out in a click with One Touch™
• Ensure your checkout is always mobile-optimised
• Deliver a simpler checkout design that’s consistent across desktop and mobile

To ensure you can continue to process payments once these upgrades have taken place, please update your PayPal buttons by 18 January 2017.

What do you need to do?

We’ve identified problems with at least one of your PayPal buttons so please check all your existing buttons for invalid or incorrect data.


--

I've been testing my buttons to see if theres a problem, so far all working (still many to go)
If PayPal has identified a problem cant they also mention where and what it is since they discovered it?

I see the PayPal documentation but so far I cant see my mistake..

Any help or advice on this most welcome.. i.e further info on this email and how to troubleshoot this..

Anthony

[MTS_Nacho]

I'm having some issues with PMs as well, I'll send you a quick email from our CRM.

[sbilodeau]

Hello,

I don't have a correlationID, but I do have a prop40 and the value is 657f9f34d2f0

Here is the full set of values:

s.prop1="xpt\x2fCheckout\x2fwps\x2fLogin";
s.prop20="1487873568";
s.prop25="main\x3awps\x3aux\x3a3pcart\x3astart\x3amember\x3a\x3a";
s.prop35="out";
s.prop37="wps";
s.prop40="657f9f34d2f0";
s.prop50="en_US";
s.prop64="7e0b775c48661";
s.prop74="aWFlZ2U\x253d";
s.eVar25="main\x3awps\x3aux\x3a3pcart\x3astart\x3amember\x3a\x3a";
s.eVar28="tnc\x2d0\x2dwps\x2dgroupzero";
s.eVar31="main\x3awps\x3aux\x3a3pcart\x3astart";
s.eVar36="CA";
s.eVar50="\x252bQjICRzVSbnJxHaeQ9JbslKKn0i0MRzhlZ\x252bYwtl6SuAhjvUHRR8KIQGDcNozt9yrLZDxrPN2yZg\x253d\x5f15a6c2ceeb8";
s.channel="ux";
s.server="main";
s.pageName="main\x3awps\x3aux\x3a3pcart\x3astart";
s.prop56="yes";
s.prop21="770acef9f35c";
s.prop5="6LN00842XB482352N";

Thanks!

[MTS_Nacho]

@sbilodeau: I was able to find the logs for this attempt, and it seems our system doesn't like the fact we are receiving the Optional Name/Optional Selection pair (onX/osX) but some of the optional selection are empty, for example:

on3_1=Dedication :

os3_1=

on5_1=Salutation :

os5_1=

on8_1=Giver Name :

os8_1=

on9_1=Date Given :

os9_1=

I have opened an internal request for our developers to check if this is an intended behaviour for legacy fallback, just in case.

[sbilodeau]

@MTS_Nacho, there is definitely some fuzzy logic going on. See, I just did "Back" in my browser, changed the quantity from 100 to 10, and checked out again. My optional name and selection pairs are exactly the same, yet the checkout succeeds and I get a correlationId with value 2cbfc48ee9702

I extracted the form data:

on0_1:Babys Full Name :
os0_1:Test Tester
on1_1:Child First Name/Nickname :
os1_1:Test
on2_1:Birthdate :
os2_1:Born January 1, 2001
on3_1:Dedication :
os3_1:
on4_1:Cadence 1 :
os4_1:sweet Test, like this blanket here
on5_1:Salutation :
os5_1:
on6_1:Cadence 2 :
os6_1:Test, know that does not change
on7_1:Cadence 3 :
os7_1:My Test dear, whatever comes,
on8_1:Giver Name :
os8_1:
on9_1:Date Given :
os9_1:
on10_1:Cover Name :
os10_1:Test's

And here are some other values, from the PayPal checkout page, in case it can help. Thanks for looking into this!

"token": "4R025916FB097601L",
"correlationId": "2cbfc48ee9702",
"corp": false,
"requestTime": 1487967310980,
"pageID": "1032e77b",
"geolocation": "CA",
"userGuid": "a1f884401420abee9d33d6b3febd6c10",
"configUrl": "/webapps/hermes/static",
"enable_early_flush": true,
"ipcountry": "CA",
"az": "slcb",
"dc": "slc",

[MTS_Nacho]

@sbilodeau Thanks! I have passed the logs from your latest example onto our back-end developers so that they can compare both and determine why one of them is falling back while the other isn't.

[MThayer]

A client of mine whose site I did many years ago contacted me when she got the message about their integration passing either invalid or incorrect data to PayPal.  I went through all of the buttons, and I couldn’t find any problems with the code.  All of them go to the new checkout, although they do not immediately go to the checkout page, going first to a simple “cart” page that looks very different from the old cart page.  Below is a screen capture.

Clicking the Continue button takes you to the new PayPal checkout screen.  None of the buttons go to the old checkout.

Now, there is one thing that I discovered.  Using Chrome’s Developer tools, I saw that, when the Continue button is pressed, I get the following timeout error:

windowload_timeout_setting Object {timeout: 20000, throttle: 10, event: "windowload_timeout_setting", state: "pre_bootstrap", level: "info"…}

I have no idea why that is happening. Could that be what the problem is? I’ve tested in three different browsers, and the continue button does always proceed to the new checkout.

Can you please check the buttons yourself and see if you can locate the problem? The Web page''s URL is:

http://www.kigerhorse.org/pay_with_paypal.php

[MTS_Nacho]

The code looks fine, and the intermediate page is triggered by the "undefined_quantity=1" variable, as explained in this thread:

/t5/PayPal-HTML-Buttons/PayPal-button-redirects-to-a-page-that-is-neither-old-nor-new/m-p/1174448

But the rest of the variables look fine.

Checking our logs for this account, I can only find one instance of a fallback to the old checkout due to incorrect variables, and it was caused because the amount passed contained the $ symbol:

amount=$20.00

So please double check that none of the buttons (or any other website integration for this account) is sending the dollar symbol.

[MThayer]

The incident with the amount having a $ was deliberate. While testing, I purposefully added the $ to one of the buttons on a test page to see what would happen. As expected, it took me to the old checkout.

As for the undefined_quantity=1" variable, the client needed an option for members to pay custom amounts. They added that button themselves a while ago.

To be perfectly honest, I prefer having the intermediate page. Unlike the login page, which only has the amount of the purchase, the intermediate page gives the name of the product. This enables the purchaser to confirm that they are buying the right product before they proceed.

So, if there aren't going to be any problems with these buttons, I'll let the client know that they're good to go. Thank you so much for your quick reply.

[Joshua66]

I have similar problem. I received email from paypal asked changing. However, I tested all my buttons/webpages I can find, all opened as new UI. It first opens a confirm page like below, then opens the new checkout UI. Can you see which button in my account has problem? If you need account information of mine, use Unique Transaction ID #5B690492BW547081A to get my account.

[MTS_Nacho]

@Joshua66 As per my previous post, the intermediate page appears because you are passing “undefined_quantity=1” variable, or selected the option to allow buyers to change the quantities of your Buy Now button.

This is not a problem per se, as long as the buyer just clicks on Continue or enters a valid quantity.

For your account, I can see only a couple of instances of fallback to the old checkout caused by buyers using a large quantity.

For example, on the 14^th of February I can see an instance where a buyer tried to use quantity=01090884031.

These kind of occurrences may be the ones that triggered the automatic email from PayPal.