Google Chrome Update - PayPal Pro and Advanced no longer working
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
About 3 weeks ago a Google Chrome update was released and all of my client eCommerce sites that are using Paypal Payments Pro or Advanced are now experiencing a failure when their customers are submitting their orders for credit card payments. The gateway is using an iframe and cookies and and now as a result of this update to Chrome, the browser session is lost. This appears to be a known issue but I have not yet figured out how to resolve the issue permanently across all versions of Chrome. I am also aware that Firefox, Edge, Internet Explorer and Safari will soon be implement this change.
When using iFrame for displaying the PayPal payment methods, we create a cross-site requests situation. All cookies and sessions were set without "SameSite=None" and "Secure" attributes were blocked by Google Chrome web browser. When PayPal gateway returns to our eCommerce site, because all current cookies and session variables were blocked, Chrome requests a new page and also request new session variables and cookies. The old session variables (Order ID#, Customer ID#, etc. ) are lost as a result of the recent Chrome update.
I assume other people are experiencing this issue. Is there any other method of connecting to PayPal Pro or Advanced without using an iFrame as suggested in the PayPal documentation?
When testing and I view the PayPal pages, I see these problems and Chrome displays warnings:
A cookie associated with a cross-site resource at https://payflowlink.paypal.com/ was set without the `SameSite` attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with `SameSite=None` and `Secure`.
https://www.chromestatus.com/feature/5088147346030592
https://www.chromestatus.com/feature/5633521622188032
Any advice or direction would be much appreciated. For now I have asked all of my clients to tell their customers not to use Google Chrome since all other browsers are currently still working perfectly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I forgot to mention that I did add "SameSite=None" and "Secure" attributes automatically on the pages. I also updated web.config page to Rewrite all cookies to add "SameSite=None" and "Secure" attributes if they don't have them. However, this does not appear to always resolve the issue and customers are not able to 100% of the time successfully submit an order for payment using PayPal Pro or PayPal Advanced. Actually what occurs is the payment is received but the order is not updated with the PayPal transaction details to confirm that payment was received because the session is lost. Therefore the order ends up as an incomplete order with no payment received.
Since customers do not realize their payment was received, they sometimes submit more than one order which results in duplicate payments and therefore my clients have to refund the duplicate payments. The strange thing is that there have been instances of where if a customer is using Google Chrome, the first order submission attempt will fail and the 2nd or 3rd attempt will process successfully, all PayPal transaction id and details are captured successfully.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From Chrome version 80 onwards, the Cookie policy is updated from SameSite=None to SameSite=Lax by default, which means when the browser receives the cookie from the server without SameSite Chrome assumes either SameSite=None (<v80) or SameSite=Lax (v80>) depending on the version.
Sample cookies, part of response header from site:
Actual cookies received from Merchant Site | Chrome default cookie policy before version 80 | Chrome default cookie policy on/after version 80 |
Set Cookie : OrderId=123767; Domain=foo.example.com; | OrderId=123767; Domain=foo.example.com; SameSite=None | OrderId=123767; Domain=foo.example.com; SameSite=Lax |
Set Cookie : UserSessionID=AUXBSEW; Domain=foo.example.com | UserSessionID=AUXBSEW; Domain=foo.example.com; SameSite=None | UserSessionID=AUXBSEW; Domain=foo.example.com; SameSite=Lax |
SameSite=None --> Browsers always sends back cookies to server(foo.example.com) though request is triggered from same domain(foo.example.com) or from different domain(othersite.com)
SameSite=Lax --> Browsers sends back cookies to server(foo.example.com) only when request is triggered from same domain(foo.example.com) else it does not send
In our case : Once transaction is successfully performed, PayflowLink responds back with all transaction details and programmatically submit the form to merchant site; kind of a redirection from a different domain. With Chrome v80+ Chrome does not send back the important cookies to your site; in the example: OrderId and UserSessionID. These cookies are missed in the request back to the website. This is the reason some customers are facing issues when they do the transactions through latest version of the Chrome browser.
Solution: would be to add SameSite=None; Secure attributes as part of your cookies, which helps to track back the transaction.
For example :
- Set Cookie : OrderId=123767; Domain=foo.example.com; SameSite=None; Secure
- Set Cookie : UserSessionID=AUXBSEW; Domain=foo.example.com; SameSite=None; Secure
Note :
By adding “SameSite=None; Secure” attributes in cookies may lead to some other security vulnerabilities, so you will need to decide to include this attribute or not.
You tube reference for SameSite Cookie Attribute can be found at: https://www.youtube.com/watch?v=aUF2QCEudPo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I already had made all of the modifications you suggested and but it does not always work and occasionally still fails. The session data and cookies are "lost" therefore the payment details are not passed back to the shopping cart program. The order ends up as incomplete and not paid.
I just switched one of my clients to PayPal PayFlow Pro and since it does not use an iframe, I no longer encounter any failures, i.e. no lost session and lost cookies. So all of my clients who are using PayPal Advanced and PayPay Payments Pro will now be using PayPal PayFlow.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you clarify this?
So from what I've read and been told by PP: We are using Paypal Payments Pro and that includes payflow pro gateway. The rep said that this is based on the way "the money flows" in our account - we have a PP business account and they are our merchant. Obvs there is no setting to check other than the service summary in PP Manager? Very strange.
My web dev says the opposite. She says we are not using Paypal Payments Pro. Very confusing: On your live site you use PayPal PayFlow Hosted
I thought Payflow was the gateway and Payments Pro is the processor. I'm confused.
So my questions is - Where did you change this setting and setup? Is it only in the URL for the API? Or is it something else entirely.
Haven't Found your Answer?
It happens. Hit the "Login to Ask the community" button to create a question for the PayPal community.
- Paypal Advanced Payment : 3d error in live in Sandbox Environment
- Advanced Credit and Debit Card Payments are disabled, Apple Pay not working in PayPal Payments Standard
- Prevent changing shipping address via SET_PROVIDED_ADDRESS not working. Orders V2 Advanced Checkout in REST APIs
- composer issues: I see paypal/rest-api-sdk-php is no longer supported but paypal/paypalhttp is. in REST APIs
- Unable to set up a subscription package longer than 1 year in Payflow