Paypal-checkout-components: [Bug] Initial patch of shipping methods does not result in methods being visible

[paymentplugins]

🐞 Describe the Bug

When a user first logs into the PayPal pop-up, the onShippingChange callback can be used to patch the order with shipping options relevant to the buyer's default shipping address. However, when the screen fully loads, and the patch responds with a 200 HTTP success, the shipping options are not visible.

If the buyer then selects a different address, the screen refreshes and the options from the initial patch are visible. It appears that the initial patch is not resulting in an update of the PayPal pop-up html elements.

🔬 Minimal Reproduction

1. https://testing.paymentplugins.com/product/pullover/
2. Add pullover item to cart then click Checkout link in navigation bar
3. Click PayPal button on top of checkout page.
4. Sign in to a sandbox account that has multiple shipping addresses.
5. Pop-up will load and show default shipping address and available payment methods. onShippingChange is called which you can observe in the browser dev console.
6. Change the shipping address and then you will see shipping options which were patched in the initial onShippingChange.

😕 Actual Behavior

Although the patch request responds with a 200 HTTP status code, the PayPal screen does not refresh with the shipping options that were provided in the patch.

First Patch: note - the add operation is being used because no shippingOptions were provided when the order was first created. Behavior is same for replace operation.
Console log: Patch data: [{"op":"add","path":"/purchase_units/@reference_id=='default'/shipping/options","value":[{"id":"0:test_method","label":"Shipping Method 1","type":"SHIPPING","selected":true,"amount":{"value":2.5,"currency_code":"USD"}},{"id":"0:test_method_2","label":"Shipping Method 2","type":"SHIPPING","selected":false,"amount":{"value":5,"currency_code":"USD"}}]}]

Patch response: {"ack":"success","data":{},"meta":{"calc":"f9ef54e6e3e65","rlog":"rZJvnqaaQhLn%2FnmWT8cSUueWscmrtUHe5Y1Bd%2FeqyvyOTq66rSXAcoHt23K4aX7rB2KTFdlMGLdO9t5%2BqNuHiYpGhdoim2Om20NmWtKTAoI_1731d1a4b13"},"server":"2OaGEAxRmW9YVPK79aOvjPVPEBAdh6oPXauvTxG_sdX9lYkHKFkLkrqmBuPZ-fqA6zNStpYzCfowntH7AHN4BzF3EEevrsP0ZB9z22Bz7JK5ElOGNrEInqUOf_mTYp0APS8JuSlmIL8RFP_q40DiYw4iDQjX28cx0XIo9RnvT9P1voV7enTtdqPKa6t4nxTCJVepiAqiQCLG5AUce7TjFHLpyjzVudEOUM59cKUG0Q5e_9ApwaJ0LFmiLcXVSIxTl0wMCnwpEFIMnIOopu5j20"}

🤔 Expected Behavior

PayPal provides the buyer's default shipping address via the initial onShippingChange callback. The integration then responds with a patch operation that provides a list of shipping options relevant to the default address. PayPal should then display the shipping options to the buyer.

Subsequent changes to the buyer's shipping address result in calls to onShippingChange where the integration can respond with shipping options relevant to the most recently selected shipping address. PayPal should always update the screen to show the shipping options provided in the patch.

It is very common for eCommerce shops to provide different shipping options across countries, states, or zip codes. The shipping options displayed within PayPal should always reflect the options relevant to the current shipping address.

🌍 Environment

• Browser version: - Version 83.0.4103.116
• OS version: -
• SDK version (window.paypal.version): - 5.0.136

Affected browsers

What browser(s) are affected?
Tested on Chrome

➕ Additional Context

paypal1.png - PayPal screen after user logs in and onShippingChange has resulted in a successful patch of shipping options. Shipping options are not shown though, despite successful patch.

paypal2.png - The patch object with two shipping options which are not visible in the PayPal screen

paypal3.png - Buyer selects another shipping address and the two shipping options provided previously now appear.

[bluepnume]

@amaclean2 can you take a look please? Thanks!

[amaclean2]

I think we've resolved this

[amaclean2]

If this is part on #1355. I'm working on a fix. It will be out shortly.

[paymentplugins]

@amaclean2 after reading through issue #1355 I believe this to be a separate problem. #1355 has to do with the pay now button not being responsive whereas this issue is related to shipping options not appearing when the PayPal pop up first renders. If you read through all the details I provided in the issue and the screenshots I believe you will see it is a separate problem.

Kind regards,

[paymentplugins]

Hi @bluepnume / @amaclean2,

I reviewed the changelog but don't see any activity sine 7/1/20. Do you need any additional information from me to troubleshoot this issue?

Kind Regards,

[amaclean2]

Yeah, I'm working on it. It'll be done soon, sorry for the delay

[paymentplugins]

Hi @amaclean2,

Thanks for the update. Do you think the fix will be part of today's Wednesday release?

Kind Regards,

[amaclean2]

It's probably going to be next week

[paymentplugins]

@amaclean2 Got it, thanks for the update. Through my partnership with PayPal I support a quite a few very high volume merchants and they are directly affected by this issue. If there's any chance you can get it out before then it's much appreciated.

Kind Regards,

[paymentplugins]

@amaclean2 Do you have an estimated timeline for this issue?

[amaclean2]

@paymentplugins this fix went out yesterday. Let me know if you see any more problems with this issue.

[paymentplugins]

Hi @amaclean2,

The issue is still present, shipping options are not visible after the initial patch using the buyer's default address. Here is an explanation and GIF showing the issue:

1. PayPal button is clicked and pop-up loads
2. onShippingChange is called with default address 1 Main St and patch is called with shipping options resulting in 200 response code
3. Shipping Options are not present after patch
4. Address is changed to 123 Test St resulting in onShippingChange being called multiple times, finally resulting in shipping options being visible. Previously, onShippingChange was called once, now after your fix it's called twice, resulting in an even slower user experience.

[amaclean2]

I'm confused. It appears in your video that the shippingOptions did patch and you can see it in the window.

[paymentplugins]

@amaclean2 The shipping options only showed up after the default address was changed. The shipping options should display when the PayPal pop up first renders, not after a customer changes their address. Most buyers will not change their address, but will instead rely on the default address.

If you re-watch the gif you will see that no shipping options are visible after the first patch. That is why I also showed the developer console so you could see the different requests that are going back-and-forth.

Make sure you are watching the video from the very beginning. You will know it’s the start of the video because you will see the PayPal button being clicked.

[paymentplugins]

@amaclean2 Did you watch it from the beginning and see what I’m talking about?

[amaclean2]

Here's the Jira ticket. I'm keeping track of the issue there.
(https://engineering.paypalcorp.com/jira/browse/PPPLMER-86634)

Thanks for hanging on

[paymentplugins]

@amaclean2 cool thanks for the update.

[paymentplugins]

@amaclean2 The link you provided appears to be internal to PayPal and so I can't view the status. Do you have any updates on this bug? It's been outstanding for quite a while now.

Kind Regards,

[719media]

Hello, is there any update on this bug? It's pretty much a roadblock to one-step paypal, honestly I'm surprised this hasn't gotten more activity given that it will be such a huge optimization for ecommerce paypal

[amaclean2]

This should be fixed. If you confirm on your side I’ll close this ticket.

[paymentplugins]

@amaclean2 This issue is not fixed. I have demoed the problem to Nate Sanders @ppnsanders and he asked me to update this issue with further details.

As you can see in the GIF, when the popup loads, the shipping options are not present, even though the order has been patched with the shipping options. Upon changing the shipping address the shipping options are briefly visible but they're for the old shipping address, not the newly selected one. It then errors out.

https://gfycat.com/amusedcheerydogwoodclubgall.gif

[TonyWoo]

@amaclean2 We also encountered the same problem. Can you help fix it? We need to use this feature in our production sites. Thanks.

[SeriaWei]

I also encountered this issue. I patch the shipping options on onShippingChange event. But the new shipping option does not appear in the dropdown until change the shipping address.

onShippingChange: function (data, actions) {
    return actions.order.patch([
        {
            op: "replace",
            path: "/purchase_units/@reference_id=='default'/amount",
            value: {
                currency_code: 'USD',
                value: "120",
                breakdown: {
                    item_total: {
                        currency_code: 'USD',
                        value: "100"
                    },
                    shipping: {
                        currency_code: 'USD',
                        value: "20"
                    }
                }
            }
        },
        {
            op: "replace",
            path: "/purchase_units/@reference_id=='default'/shipping/options",
            value: [{
                id: 'UPS10',
                label: 'UPS Label 100',
                selected: false,
                amount: {
                    value: '10.00',
                    currency_code: 'USD',
                },
            }, 
            {
                id: 'UPS20',
                label: 'UPS Label 200',
                selected: true,
                amount: {
                    value: '20.00',
                    currency_code: 'USD',
                },
            }, 
            {
                id: 'UPS30',
                label: 'UPS Label 300',
                selected: false,
                amount: {
                    value: '30.00',
                    currency_code: 'USD',
                }
            }]
        }
    ]); 
}

I have tried to patch shipping options on server side, it was the same.
And it seams that selected: true does not work with patching.

Is there a plan to fix this issue?

[719media]

@amaclean2 I know you must be incredibly busy with a lot going on at PayPal. It's difficult that this issue, which is causing a fairly critical issue that has been explained, isn't getting more communication. If you could please communicate a little more on this issue and what's happening to resolve it, it would be greatly appreciated.
Thank you.

[amaclean2]

There was another release that went out yesterday to address this issue. Can you verify that it works/doesn't work in sandbox or production

[paymentplugins]

@amaclean2 I just tested this in sandbox version 5.0.168 @ 6:30PT and the issue is still not resolved.

[amaclean2]

@paymentplugins I resolved this issue with a few other merchants and I haven't been able to reproduce the specific situation you're having. Can we schedule some time to try to reproduce this and get this cleared up once and for all. It'd be great to end this circle.

Thanks

[paymentplugins]

@amaclean2 Happy to schedule a time to reproduce the issue. I'll email you with some suggested times.

[amaclean2]

@paymentplugins I found a couple inconsistencies between what the patch call sends and what we're getting internally. I'm looking at what's causing this. I'll let you know when I find something. Also, it doesn't appear that the patch gets called everytime the PayPal site gets loaded. I don't know what's causing that. I just wanted to let you know.

[amaclean2]

@paymentplugins I think there might be an issue with the asychronicity of how you're calling the patch call in onShippingChange. Can you share with me the code snippet you showed me one more time?

[paymentplugins]

@amaclean2 Just sent you an email regarding your request.

[amaclean2]

So, the issue @paymentplugins was facing, I don't know about others, was that there was a break in the promise chain of onShippingChange. Anyone calling onShippingChange needs to make sure that the patch call is in a contiguous promise because our code is checking the response from that promise chain for a patch call. When a patch call is outside of the promise, it's not going to be seen.