#HacheEV
restive gate
ember mantle
hi! seems strange, do you have the request ID req_xxx of the request where you created the PortalSession?
oblique sable
Not i haven't, let me check in local development
ember mantle
I just tried it and I get a URL like
https://billing.stripe.com/p/session/test_YWNjdF8xQ0N2Y2RKb1VpdnoxODJELF9NbzFrNUs3NEdib2tYb3VtOU9UOEIwd2FPOUZVV1VZ0100PUzZozL3
and it works fine really and I can visit that in my browser with no issue
do you have more detail on what specifically seems to be going awry?
oblique sable
I have the same url or similar but I get that problem
"message": "Unrecognized request URL (POST: /p/session/test_YWNjdF8xTHdSYlpETjE0WTBrVmR0LF9NbzFuT1cxWWVBdDNtc0R0a1J2TDRoR01hS2tqUU1X0100DnqTyJX6). Please see https://stripe.com/docs or we can help at https://support.stripe.com/.",
ember mantle
yeah the problem is you're POSTing to it
oblique sable
I'm using node in a serverless function in next.js
ember mantle
yep but how does the frontend look? how is the backend URL called? probably from a <form action>?
ember mantle
yep and then your server probably does a 307 redirect to our URL, which will also be a POST, which won't work
if you inspect the network tab in your browser when viewing your page you'll see it doing that
oblique sable
okey so, therefore, how i proceed?
ember mantle
not sure yet, but you want to have your server not do that, it should do a 302 redirect really
next.js doesn't though, it uses 307, they have a note about it on https://nextjs.org/docs/api-reference/next.config.js/redirects
or you can change the function on your server to be a GET, and then call it from a fetch on the frontend and just assign to window.location in Javascript, that works too
oblique sable
okey, im checking in local dev with a 302 redirect
ember mantle
I imagine that would work
oblique sable
okey, if not, i will reopen aquestoin
ember mantle
but yeah our docs assume/depend on the behaviour that next.js seeks to explicitly prevent so I can see the confusion(our docs are written with Express.js in mind which works differently).
many browsers changed the request method of the redirect to GET, regardless of the original method. For example, if the browser made a request to POST /v1/users which returned status code 302 with location /v2/users, the subsequent request might be GET /v2/users
(we want that, since our docs have you POST to /create-customer-portal-session and want you to redirect to a GET to our hosted page).