Paypal-checkout-components: Timeout hard-coded to 10 seconds

[dasx199]

Description

Hi,

I've got two merchants (using checkout.js via BTSDK) who’s saying that when testing on slow connections, they’re getting a timeout. It happens when the XHR call to create_payment_resource takes longer than 10 seconds. I reckon raising the timeout is the best option for them, but it seems to be hard-coded.

This is pretty damaging in terms of customer experience, as there is no way for merchants to easily handle this error, and there is no way for the customer to recover from this scenario (a second press of the checkout button does nothing.

The error message from the console is:
checkout.js error Error: Error: Timed out waiting 10000ms for payment
    at ParentComponent.<anonymous> (https://www.paypalobjects.com/api/checkout.js:8769:152)
    at Object.value (https://www.paypalobjects.com/api/checkout.js:6091:41)
    at https://www.paypalobjects.com/api/checkout.js:3405:40
    at Function.ZalgoPromise.try (https://www.paypalobjects.com/api/checkout.js:8176:37)
    at Object.handler (https://www.paypalobjects.com/api/checkout.js:3404:77)
    at https://www.paypalobjects.com/api/checkout.js:2830:32
    at Function.ZalgoPromise.try (https://www.paypalobjects.com/api/checkout.js:8176:37)
    at Object._RECEIVE_MESSAGE_TYPE.(anonymous function) [as postrobot_message_request] (https://www.paypalobjects.com/api/checkout.js:2826:70)
    at receiveMessage (https://www.paypalobjects.com/api/checkout.js:2759:77)
    at messageListener (https://www.paypalobjects.com/api/checkout.js:2780:13)
    at Object._RECEIVE_MESSAGE_TYPE.(anonymous function) [as postrobot_message_response] (https://www.paypalobjects.com/api/checkout.js:2857:118)
    at receiveMessage (https://www.paypalobjects.com/api/checkout.js:2759:77)
    at messageListener (https://www.paypalobjects.com/api/checkout.js:2780:13)
    at ParentComponent.<anonymous> (https://www.paypalobjects.com/api/checkout.js:8769:152)
    at Object.value (https://www.paypalobjects.com/api/checkout.js:6091:41)
    at https://www.paypalobjects.com/api/checkout.js:3405:40
    at Function.ZalgoPromise.try (https://www.paypalobjects.com/api/checkout.js:8176:37)
    at Object.handler (https://www.paypalobjects.com/api/checkout.js:3404:77)
    at https://www.paypalobjects.com/api/checkout.js:2830:32
    at Function.ZalgoPromise.try (https://www.paypalobjects.com/api/checkout.js:8176:37)
    at Object._RECEIVE_MESSAGE_TYPE.(anonymous function) [as postrobot_message_request] (https://www.paypalobjects.com/api/checkout.js:2826:70)
    at receiveMessage (https://www.paypalobjects.com/api/checkout.js:2759:77)
    at messageListener (https://www.paypalobjects.com/api/checkout.js:2780:13)
    at Object._RECEIVE_MESSAGE_TYPE.(anonymous function) [as postrobot_message_response] (https://www.paypalobjects.com/api/checkout.js:2857:118)
    at receiveMessage (https://www.paypalobjects.com/api/checkout.js:2759:77)
    at messageListener (https://www.paypalobjects.com/api/checkout.js:2780:13)
    at deserializeError (https://www.paypalobjects.com/api/checkout.js:3360:20)
    at https://www.paypalobjects.com/api/checkout.js:3379:322
    at https://www.paypalobjects.com/api/checkout.js:3466:30
    at eachArray (https://www.paypalobjects.com/api/checkout.js:3449:51)
    at each (https://www.paypalobjects.com/api/checkout.js:3455:35)
    at replaceObject (https://www.paypalobjects.com/api/checkout.js:3465:13)
    at https://www.paypalobjects.com/api/checkout.js:3467:169
    at eachObject (https://www.paypalobjects.com/api/checkout.js:3452:65)
    at each (https://www.paypalobjects.com/api/checkout.js:3455:144)
    at replaceObject (https://www.paypalobjects.com/api/checkout.js:3465:13)

Steps to reproduce

1. Force a really slow connection using developer tools, using checkout.js via BT SDK.
2. Observe that after 10 seconds, the in-context window closes, and an error is logged in the console.

Affected browsers

• [X] Chrome
• [X] Safari
• [X] Firefox
• [X] Edge
• [X] IE
• [X] Chrome Mobile/Tablet
• [X] Safari Mobile/Tablet
• [X] Web View / Safari ViewController
• [X] Other

The issue is not browser-specific.

[voltairebiton]

I have the same issue. It happens both on sandbox and live. Most of the time in my php rest sdk, it took more than 10 seconds to finish the create_payment. I tried changing the timeout parameter to 30 seconds with no avail. Pls fix. This is really an important issue. I will lose more customer if this keeps up. Thanks to thoae who could respond and fix

[JarvisHome]

same problem here - i can't see the advantages of cutting the process on 10 seconds.

[OMSmolina]

I have to create with REST API a plan + activate plan + create agreement to return EC Token... this takes longer than 10 seconds... I can't see the advantages of cutting the process on 10 seconds either.

[bluepnume]

Thanks for the feedback. The rationale is this: the SLA for calling the PayPal REST API to create a payment id is <1 second.

Any additional time spent, the buyer is sitting looking at a spinner, and after 10 seconds has elapsed we see a lot of buyers giving up and closing the popup window out of frustration.

The idea behind the 10 second timeout is to discourage integrations that do a lot of work/processing before returning the payment ID and cause these drop-offs. Ideally any other work should be done concurrently so the PayPal popup is not blocked for this long.

[JarvisHome]

In my case the problem is the PayPal Sandbox. Our System is very fast -that is not the problem. But the request of the payment id from the sandbox took a lot of times over 10 sec. So i am frustrated integrating and testing PayPal in our shop. So maybe you can disable the timeout in the sandbox environment - or buy new Servers for the sandbox ;-)

I hope this problem does not continue in the live-environment.

[dasx199]

Makes sense, but to doesn't seem to allow for users on slow internet connections (I'm thinking dodgy 3G or GPRS/2G) where the XHR can easily take longer than 10 seconds. And it also doesn't factor in that the sandbox can be slower than live.

Completely get that a lot of buyers will give up; but it does feel that we need to enable people to handle the timeout better. Currently via BTSDK there is no way for the merchant to know the timeout has happened (that I could find anyway), so they can't recover from this error at all.

[bluepnume]

My thinking for this is to disable the timeout when:

1. It's a sandbox request
2. It's a direct client->api call (client-side REST and braintree)
3. We detect the network speed is slow

[verysimplenick]

Faced the same problem. The sandbox responds very slowly.

[verysimplenick]

@bluepnume
Any news?

[fcassin]

A workaround we used while working with the sandbox environment was to :

• Download the script locally
• Modify all 5 instances of "1e4" (10000, the timeouts in ms) to "1e5"
• Use the locally modified script for your sandbox request
  Your sandbox requests should now work, albeit slowly. Do not do this in production though !

[bluepnume]

In the next release, at least, we're disabling that timeout for sandbox env. It'll go out either today or tomorrow.

[n-belokopytov]

@bluepnume I am now having issues with 20 seconds sandbox timeout, here is what I see in Console. I am using a custom Webview to open Paypal checkout

webscr?cmd=_express-…T&&force_web=true:1 The certificate used to load https://www.sandbox.paypal.com/de/cgi-bin/dni/webscr?cmd=_express-checkout&useraction=commit&token=EC-47S754446N039072T&&force_web=true uses an SSL certificate that will be distrusted in the future. Once distrusted, users will be prevented from loading this resource. See https://g.co/chrome/symantecpkicerts for more information.
webscr?cmd=_express-…force_web=true:3362 windowload_timeout_setting
{timeout: 20000, throttle: 50, event: "windowload_timeout_setting", state: "pre_bootstrap", level: "info", …}
client_elapsed
:
118
event
:
"windowload_timeout_setting"
level
:
"info"
pageID
:
"1931e01b"
req_elapsed
:
5386
state
:
"pre_bootstrap"
throttle
:
50
timeout
:
20000
timestamp
:
"Tue Nov 14 2017 14:51:20 GMT+0100 (CET)"
token
:
"EC-47S754446N039072T"

[blacksoulgem95]

I'm having this problem both in prod and test. I've integrated the Paypal Button (client-side REST) in my AngularJS application through an angular directive. there is an example of payload I send to PayPal (the API does not return any error)
The following gist contains both the example JSON we send to PayPal and the Directive I built to do the integration in AngularJS

https://gist.github.com/ITGuy9401/33cc2d4e5e381552bbde74e95ffb0a66

[gety9]

@bluepnume what is timeout for live?

for us capture is working on sandbox, but not on live.
So assume it might be one of the reasons.

[OMSmolina]

@gety9 10 seconds :)

[Baziliq]

same issue here, in some clients the latency due to network between the client and my server takes some time, getting this error! is there a way to override the timeout?

what other option is there to resolve this? referring to prod env

@bluepnume I understand your claim on the 10secs is too long but looks like it's not! in my case, I don't do anything on the server, simply set the price and redirect the call to PayPal. My server endpoint is in US and clients from other parts of the world hit this timeout, need to open the PayPal window several times (for the cache to take in) for it to work

Need to have some option to config this timeout, otherwise, this integration is useless!

request.post(
    `${PAYPAL_API}/v1/payments/payment`,
    {
      auth: {
        user: CLIENT,
        pass: SECRET
      },
      body: {
        intent: "sale",
        payer: {
          payment_method: "paypal"
        },
        transactions: [transaction],
        redirect_urls: { ... }
      },
      json: true
    },
    (err, response) => {
      if (err) {
        return res.sendStatus(500);
      }
      res.json({
        id: response.body.id
      });
    }
  );

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.