#suppyben-checkout

1 messages · Page 1 of 1 (latest)

tall bison
#

Hello! DO you mind sharing an example live checkout URL that you are getting?

green hatch
#

yes!

here is the one that the res.redirect is resolving to browser side: https://checkout.stripe.com/pay/cs_live_a1der92464edFNTQDWiR1vDKFRRj7KjUj7mUWRl7czjBPIsWSQWqYVJJft#fidkdWxOYHwnPyd1blppbHNgWmNQd2twSE5qYVRIM1BIXVVfa0NmS1Q2SzU1N2xmazBXMEEnKSd1aWxrbkB9dWp2YGFMYSc%2FJ2RAUDN2NDBwUTF0dTZIRDZmZicpJ3dgY2B3d2B3Jz8nbXFxdT8qKmlqZmRpbWp2cT82NTU1Kid4JSUl

here is the one that is logged server side, and the very url that res.redirect is called with.
https://checkout.stripe.com/pay/cs_test_a12jmS4I2DwMIEYwAVYGdWvohrejzhjcVSkv08vOdE9C71bzXo2fbwf4P5#fidkdWxOYHwnPyd1blpxYHZxWnQzPVdAPFdqTHFDNkQ2ZjxUfTw1NkQ1XDU1MVNgcHJzUm8nKSdjd2poVmB3c2B3Jz9xd3BgKSdpZHxqcHFRfHVgJz8ndmxrYmlgWmxxYGgnKSdga2RnaWBVaWRmYG1qaWFgd3YnP3F3cGB4JSUl

#

And I only have a test api key defined in the environment, there is 0 chance it is using any prod keys

tall bison
#

Hmm... that's strange - what does your server-side code that is creating the Checkout Session look like?

green hatch
#

Upon further investigation, I am getting a 403 cors errors on the preflight request, on the cs_test url. Do I need to be on localhost:4242?

# 
    billing_address_collection: 'auto',
    line_items: [
      {
        price: priceId,
        quantity: 1
      }
    ],
    client_reference_id: orgUid,
    metadata: {
      orgName,
      orgUid,
      userUid
    },
    mode: 'subscription',
    success_url: `${dashboardBaseUrl}/orgs/${orgName}/?success=true&session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${dashboardBaseUrl}/orgs/${orgName}/?canceled=true`
  })
// in route
    return res.redirect(303, session.url)
tall bison
#

No, you shouldn't need to be on localhost:4242, but how are you making the request? Are you doing fetch? Or a form submission?

green hatch
#

Just a fetch

tall bison
#

If you're doing just a fetch then I don't think res.redirect will work (which is why you're gettin ght cors errors). You either need to do the redirect client-side, or switch to a form submit

tall bison
#

@green hatch Does this make sense? Just wanted to check on how things were going

green hatch
#

Thanks for the info, @tall bison . I have since removed the redirect, and just returning a response with the url and navigating manually. Something peculiar though, is that somehow it is still opening a new tab to a live checkout session. Even on a fresh browser, cleared history/local storage, it is still opening. But my test checkout session is now being navigated to. I thought perhaps it was something to do with axios, but this still happens just using fetch

For context, my new response in my route, no redirects anywhere.
res.json({ url: redirUrl })

Response from network

:status: 200
ETag: W/"119-fgWHgB1OqkB5+egKl9g/ujqR6sQ"
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: http://localhost:3000
Date: Wed, 13 Apr 2022 18:39:18 GMT
Content-Length: 281
Cache-Control: no-cache
Vary: Origin
x-powered-by: Express
apigw-requestid: QiDRaiqToAMESOA=

Logged in browser
{url: "https://checkout.stripe.com/pay/cs_test_a1dVfzq2zC…gWmxxYGgnKSdga2RnaWBVaWRmYG1qaWFgd3YnP3F3cGB4JSUl"}

but a new tab still opens, no CORS error this time though. How is this possible?

#

Thought maybe it was caching the redirect, but even on Safari, which has never opened this page, exhibits same behavior.

#

I will try a form request too, and see if it persists. This is so strange. After triple checking, there is no where that a redirect response is coming in anywhere.

tall bison
#

That really is odd - do you have anywhere at all in your code that you may be redirecting to a payment link?

green hatch
#

No, not anywhere, we are behind AWS' API Gateway though, so I am wondering if it is somehow keeping ahold of the redirect and still sending it back, but I highly doubt that.

Here is all the code that is running on this request, for context:

 * Start Org Subscription Flow
 */
api.post('/orgs/:orgName/billing/subscription', async (req, res) => {
  const { orgName } = req.params
  const { selectedPlan } = req.body
  if (!selectedPlan) {
    return res.status(400).send({ message: 'selectedPlan is required' })
  }
  const accessKey = req.get('Authorization')
  const org = new Org({ accessKey, orgName })
  await org.authorize()
  const { orgUid, userUid } = org
  try {
    const redir = await StripeAdapter.createCheckoutSession({
      orgUid: orgUid!,
      orgName,
      userUid: userUid!,
      selectedPlan
    })
    res.set('Cache-control', 'no-cache')
    res.json({ url: redir })
  } catch (e) {
    logger.error({ err: e }, 'error creating checkout session')
    return res.sendStatus(500)
  }
})

// Stripe Adapter
const createCheckoutSession = async (opts) => {
  const { orgUid, orgName, userUid, selectedPlan } = opts

  const priceId = PlanToPrice[selectedPlan]

  if (!priceId) {
    throw new StripeError(`No priceId found for ${selectedPlan}`)
  }

  const session = await stripe.checkout.sessions.create({
    billing_address_collection: 'auto',
    line_items: [
      {
        price: priceId,
        quantity: 1
      }
    ],
    client_reference_id: orgUid,
    metadata: {
      orgName,
      orgUid,
      userUid
    },
    mode: 'subscription',
    success_url: `${dashboardBaseUrl}/orgs/${orgName}/?success=true&session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${dashboardBaseUrl}/orgs/${orgName}/?canceled=true`
  })
  console.log(session)
  if (!session.url) {
    throw new Error('Failed to create checkout session')
  }
  return session.url
}
#

At this point, though, I think it has to be something on our end whether it be caching or something. Thanks for your help, it much appreciated 🤘

tall bison
#

Sorry we weren't able to really get ot the bottom of it - it really is strange. If it helps, that live checkout session is being generated from a payment link, but not sure what else could be causing this

green hatch
#

ha - so turns out our front end dev was a bit ahead of me and had live payment links being navigated to as a side effect to this api call. so that is what this was, this entire time. remote is hard sometimes, haha. thank you for your attention anyway, though.

tall bison
#

phew! glad you figured it out