#KrisMatrix - Stripe CLI
1 messages · Page 1 of 1 (latest)
Hello! Let's keep everything in this thread:
I want to test my whole system in development environment. I.e. click subscription, have it call my localhost/route, AND then sends the webhooks as well. How would I do this? I can presently only test one thing at a time.
What do you mean by only being able to test one thing at a time?
So...i know how to use the stripe program to test triggers such as 'checkout.session.completed' or 'invoice.paid' independently.
I don't know how to set up a way to test the whole work flow.
Basically, I want to test, click subscribe, user enters dummy credit card, then gets redirected to my success page, then my site also gets webhooks and I need to process all of that for ONE customer.
You can test all of that locally with Stripe CLI. Can you tell me specifically what part of that you're having trouble with?
ok..let's start with just the first step.
I was to 'create checkout session'
my code needs to call /v1/checkout/sessions and pass success/cancel url, price_id, count and a mode=subscription.
I get the URL from stripe, and rediret to that stripe url.
The user enters credit card details. When they hit submit, how do I test that I got to success_url on a local dev env?
You use stripe listen to forward the webhooks to your local environment: https://stripe.com/docs/cli/listen
See the --forward-to parameter: https://stripe.com/docs/cli/listen#listen-forward-to
Yes. I am aware of that. But I am not sure if answers my problem.
Perhaps a better way to phrase my overall question is, when I use stripe listen I use it as follows:
stripe listen --forward-to localhost:3000/webhook
And when I do this stripe always ONLY calls the webhook route. Instead I want to set up stripe to send all response to localhost:3000 and it needs to know which route to go to.
You know what hold on...Let me think this through a bit.
Yeah, I'm not sure what you mean by "all response" there.
How do I tell stripe to in success_url to call localhost:3000/success/session_id="cs_xxxx"
const session = await stripe.checkout.sessions.create({
mode: 'subscription',
line_items: [
{
price: priceId,
// For metered billing, do not pass quantity
quantity: 1,
},
],
// {CHECKOUT_SESSION_ID} is a string literal; do not change it!
// the actual Session ID is returned in the query parameter when your customer
// is redirected to the success page.
success_url: 'localhost:3000/success.html?session_id={CHECKOUT_SESSION_ID}',
cancel_url: 'localhost:3000/canceled.html',
});
This is what I want to do for testing effectively. And for stripe to send it to my laptop's localhost.
So that request is failing right now, correct? Because the URLs aren't valid?
Obviously it would fail. Stripe doesn't know which machine the localhost:3000 is at.
(above was not condescension...just a statement)
The API doesn't like that request because the URLs don't start with http://. Will you try again with that prefix and see if that works? I don't recall if that's allowed in test mode or not.
That won't matter. I can certainly add it...but stripe doesn't know localhost:3000. (I am not using stripe listen here). It may way work If I setup stripe listen...but the question here is...how do I use it.
Maybe another clarification is...can I only run one stripe listen program or multiple? For example:
$ stripe listen --forward-to localhost:3000/success/
and
$ stripe list --forward-to localhost:3000/webhook
And this stripe know where to send things maybe?
I just tested it, it works fine if you add the http:// to the URL to make it a full valid URL.
Without running stripe listen?
I'm not sure what you mean by "stripe doesn't know localhost:3000"?
Yeah, this has absolutely nothing to do with stripe listen.
stripe listen is only for webhooks. The success_url has nothing to do with that at all.
interesting...I will try a quick degenerate script.
brb
You are infact right. Thank you very much. I guess if I want to test also test webhook, I should use stripe listen and have it running then test.
(no idea how or why it works...but ok.)
Yeah, stripe listen can be used to forward webhooks to your URL locally. As far as why setting the success_url on the Checkout session to your localhost URL works I'd be happy to explain why it works if you can provide more details about what you don't understand or ask further questions. 🙂
Well..on a production site, I would be providing a full url like http://example.com/success. So stripe can redirect to the url. I don't know how in development stripe knows that localhost:3000 is my machine. Many computers with development environments have people testing on localhost:3000.
The localhost domain is special in that it always points to the local machine. If I go to http://localhost on my computer here it will try to connect to my own computer, not yours, for example. When you tell Stripe to use the localhost URL for the Checkout Session you're telling Stripe to send the customer to that URL after Checkout. Stripe doesn't care (at least in test mode) that the URL is a special localhost URL, it just tells your web browser to go there after Checkout succeeds.
Does that make sense? Happy to explain differently if not!
Oh...so stripe doesn't actually know which computer it is. It is just telling the browser to go to localhost:3000 of the machine that stripe is displaying it's current page. Got it.
Yep!
Smart. That is extremely useful. And THIS is why the same doesn't work when doing webhooks. Stripe NEEDS to know where to send them to.
Another way to think about it is like a note giving directions to an address. Something like https://stripe.com would equate to an actual specific address, like 354 Oyster Point Blvd South San Francisco, CA, 94080-1912. However, http://localhost isn't a specific real address, it's more like saying go home. To me go home means my home, but to you it means your home.
Quick question here since you closed the previous thread. Does it need to be /success/session_id={CHECKOUT_SESSION_ID} or can I change it to /success/sess_id={CHECKOUT_SESSION_ID} ?
or even just success/{CHECKOUT_SESSION_ID}?
You can name that parameter anything you like, the URL is up to you
but the {CHECKOUT_SESSION_ID} has to be exactly that for us to swap in the ID
any of the 3 URLs you proposed are perfectly fine
ok...thank you.
NP!