Since Friday of last week, users have been reporting that after editing an order the payment links provided by Shopify on their customer accounts page on the button “PAY NOW” are broken. When clicking on them, users are redirected to the home page.
After extensively debugging if this is an issue with subdomains, we found that urls that are broken to customers have “&ss=silent” appended to the urls provided by Shopify. This query sends customers back to the shop’s home page when showing intent to pay an invoice link.
Hi @keiraarts
We’re looking into this now - is this happening with all users and orders? Can you share a redacted example of the broken URL? Specifically the path before &ss=silent? Also does the link work if you manually remove &ss=silent from the URL?
Also - are you seeing &ss=silent or &sso=silent ?
Hi Liam, we’ve gotten several reports about it now. Seems to be widespread across our Plus merchants using different tools, new customer accounts or old customer accounts, customzied checkouts or non-customized checkouts.
Here’s a checkout link that does not work and redirects to the homepage.
https://****.com/5408784458/order_payment/7014312313001?secret=fe6cef0827d0dea3a97f2f933ae1fc67&sso=silent
Here’s a checkout link that does work.
https://****.com/5408784458/order_payment/7014312313001?secret=fe6cef0827d0dea3a97f2f933ae1fc67
Across all merchants the second generation of a payment link appends sso query paramter and breaks checkout. It happens on sending the email invoices to the merchants too because sso is appended on email invoices from Shopify.
Had this happen on an onboard again today. On second post purchase payment. Hoping we can get a fix soon 
Hey @keiraarts and @paulygoldston - do you have request-ids you can share from impacted merchants/ orders?
We don’t have request_ids because this would be Shopify’s order status page (without any apps installed!) displaying a “Pay now” button when orders have outstanding balances but it appends the sso paramter that breaks redirects.
If you tell me the query you’d like me to run though, I’m happy to send it over the resulting GraphQL response and all of it’s metadata.
1 Like
Hey @Liam-Shopify
We’ve been investigating this further and found a separate pattern beyond the sso=silent parameter (which we’ve since stripped on our end). I might be wrong on this, but just trying to understand what’s happening.
What we’re seeing: paymentCollectionDetails.additionalPaymentCollectionUrl works the first time a customer visits it to pay an outstanding balance after an order edit. But if the order is edited again (creating a new outstanding balance), the API returns the same URL with the same secret and this time it redirects the customer to the store homepage instead of the payment page.
In our logs:
- The secret query parameter is identical across both edit cycles
- The URL is well-formed, no
sso=silent present
- It only breaks after the URL has already been used once for a successful payment
What I think might be happening (but I could be wrong): The secret may now be single-use, or the payment session is invalidated after the first collection, while the Admin API continues returning the same stale value on subsequent orderEditBegin calls. But it doesn’t seem to affect every multi-edit checkout only a subset of sequential edits show this behaviour.
This wasn’t an issue before sequential order edits with payment collection between each edit have been working fine for months. Has anything changed on the /order_payment endpoint recently? or do we need to have another approach?
Any word @Liam-Shopify ?
This one is blocking a few onboards right now