#gecko - CLI

1 messages · Page 1 of 1 (latest)

old tapir
uneven dawn
#

brew install stripe/stripe-cli/stripe

old tapir
#

Hi there! How can we help?

uneven dawn
# 
remote: Enumerating objects: 360, done.
remote: Counting objects: 100% (192/192), done.
remote: Compressing objects: 100% (128/128), done.
remote: Total 360 (delta 63), reused 0 (delta 0), pack-reused 168
Receiving objects: 100% (360/360), 46.10 KiB | 1.84 MiB/s, done.
Resolving deltas: 100% (118/118), done.
Error: Invalid formula: /home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/stripe/homebrew-stripe-cli/stripe.rb
formulae require at least a URL
Error: Cannot tap stripe/stripe-cli: invalid syntax in tap!```
#

hi two-shoes...this is what I get when I try to follow your CLI install steps

old tapir
#

Taking a look now

uneven dawn
#

so I need to get the tarball?

#

never mind I got it via tarball

#

thx for following up on the brew issue

#

Ok webhook question

old tapir
#

Glad you were able to get it working! Let's talk here about your webhook question

#

What's up?

uneven dawn
#

For the session events, there are checkout-session-completed….as well as payment-intent-succeeded

#

As I understand it, if I monitor checkout-session-completed will include payment_intent.succeeded, once this occurs, as well as the async payment events, if they occur

#

So do I need to monitor for the payment_intent.succeeded event, or just sub status of the checkout-session-completed?

old tapir
#

The checkout.session.completed Event will only fire if the payment is successful or if the associated Payment Intent transitions to 'processing' (in the case of payment methods with delayed notification like SEPA), so if you're just monitoring for successful payments, then checkout.session.completed is ideal.

If that's not the case, can you elaborate a bit on what you're monitoring for?

uneven dawn
#

Well, through the docs, there are tutorials that describe testing specifically (simple use case) for payment_intent.succeeded

#

I’m trying to figure out if I have to catch this case separately, or should just test for checkout.session.completed and then sub-status from there to deal with the cases where payment is immediate or deferred?

inner quarry
#

if you use Checkout, use Checkout's events instead

uneven dawn
#

So I’m checking on checkout.session.completed, checkout.session.async_payment_succeeded, as the payment success cases. For the first one (completed), I understand I need to check sub status (event.data.object.payment_status === ‘paid’) to fulfill, otherwise there is awaiting payment, and failed type sub statuses, if I want to address. (Awaiting payment being used for order creation for example)

#

I’m an immediate service fulfillment, so no order creation is needed in my use case. So I think to summarize, I need to handle: checkout.session.completed (and payment_status=paid), and the other case is checkout.session.async_payment_succeeded. Yes?

inner quarry
#

yes

uneven dawn
#

Thanks

inner quarry
#

Of course!

uneven dawn
#

ok next problem....testing my webhook

#

I see all the statuses flow across my console...great

#

pi created, customer created, pi succeeded, charge succeeded, session completed

#

all good

#

i get an error in my response....

#

StripeSignatureVerificationError: No signatures found matching the expected signature for payload. Are you passing the raw request body you received from Stripe? https://github.com/stripe/stripe-node#webhook-signing

#

this is what I think I'm supposed to be doing once fulfillment is done:

inner quarry
#

it can be many things. 99% of the time: you use the wrong secret, the CLI generates its own webhook secret(s)

uneven dawn
# 
        // Return a response to acknowledge receipt of the event
        response.json({received: true});
#

oh....might be CLI then that's what I'm using for the listening

#

ok I have the whsec from the CLI

inner quarry
#

yeah the CLI has its own secret

uneven dawn
#

it really looks like the same secret...

inner quarry
uneven dawn
#

when I run stripe listen on the cli, the secret I get back is literally the same, in multiple calls, and what I think it what I pulled from the dashboard

#

I'm assuming that my constructEvent call is what's bombing since my fulfillment code (with logging) isn't reached.

inner quarry
#

correct, see my answer just above

uneven dawn
#

i thought bodyParser is no longer required, which is what is included in a lot of that issue

#

and agree with all the comments...this is missing from the tutorial that raw is needed and a separate route from everything else in existence is needed....seems really like that could use some improvement in the sample code / docs

inner quarry
#

I can't really give you one solution unfortunately, there are dozens of ways to do this in node and 2 people with similar setups need different use-cases.

#

And it seems to really be node specific, no other language has this much issues that we've found 😦

uneven dawn
#

lol

inner quarry
#

What do you think would help in docs?

uneven dawn
#

so one comment/solution there was to simply pass the request.rawBody (instead of request.body)...which seemed simple enough, but alas this doesn't work?

inner quarry
#

right now our public docs do this app.post('/webhook', express.raw({type: 'application/json'}), (request, response) => { let event = request.body; // Only verify the event if you have an endpoint secret defined. // Otherwise use the basic event deserialized with JSON.parse if (endpointSecret) {

uneven dawn
#

so...in looking through the various sample pages, there are some inconsistencies that tie to this issue I believe:

#

for example, this code block will reference app.post('/webhook', express.json({type: 'application/json'}), (request, response) => { and the response at the bottom as: response.json({received: true});

#

this is going to have issues with the raw version

#

so changing to the raw, and a response.status(200), I can get it to work

inner quarry
#

yeah that's fair, though the main example we have in our docs also causes issues for some devs 😦

uneven dawn
#

sucks

#

well, it's working, that's the good part

#

thanks for all your help

#

really appreciate the super online support yall give, it truly is best in class

inner quarry
#

happy to help 🙂

uneven dawn
#

and maybe one more question before the night is over....for a recurring subscription, I want it to be monthly, on the calendar month, not a rolling 30 days or similar. How do I ensure in the price I create, that this is the case, and the billing date?

inner quarry
#

we do calendar month by default

uneven dawn
#

and when does the payment-intent, or checkout session or whatever initiate? timezone and day of month...please

#

UTC on 1st of every month, 00:00:01? I need to align on timing

#

and lastly, does a subscription just come across webhooks as any other checkout session, this would just be initiated by stripe, and not by the customer? or is there something unique?

inner quarry
#

it's whenever the subscription is created

uneven dawn
#

but if it's calendar month, then it would renew at the first, not when created, which is the crux of my question

inner quarry
#

You have a $100/month Price. It's using the calendar month for the "duration". If you create a Subscription today at 7.40pm US West time, it will renew in a month on May 11th

#

it's all based on when the subscription is created and it's neither "always the 1st of the month" nor "30 days"

uneven dawn
#

i want a first of the calendar month subscription...is there no way to do this?

#

because what you describe is a rolling 30 days model (the monthly anniversary of their enrollment)

inner quarry
#

there's no rolling 30 days in what I described

#

if it was 30 days, it'd change the charge date based on month duration 😅

#

And you can totally do 1st of the month if you want, using billing_cycle_anchor or having a trial period until that specific time. There are many ways to do this but I'd recommend being a bit more explicit with your exact question and what you really want to see: when is it created, when does it renew, who pays what at which date

uneven dawn
#

ok sorry....let me try again

#

I want billing to occur on the 1st day of the calendar month (Gregorian calendar), of each month, and it needs to occur at some specified time of day...say UTC, just after midnight etc.

#

how do I structure this so that my billing will occur this way?

#

the first time a customer orders a subscription will be mid-month at some time...this payment covers the rest of the current calendar month, and then the first of the month billing kicks in

light mauve
#

stepping in on behalf of koopajah, have you tried using the billing_cycle_anchor? Honestly i think the best way for you to understand this is to try it out. You can use test clocks : https://stripe.com/docs/billing/testing/test_clocks to simulate the movement of time

uneven dawn
#

i haven't seen this...I'll check it

#

that simulates time....fine....where's the docs on the cycle-anchor?

light mauve