#SenorKarlos - Webhooks
1 messages ยท Page 1 of 1 (latest)
It seems pretty straightforward, I just want to understand something better and see if I need a dependency still.
My old integration doesn't use webhook secrets, possibly pre-dating (not sure there), and handles the webhooks with an overly simple block, passing teh request along to another script.
excerpts of the main script
const bodyParser = require("body-parser");
const express = require("express");
server.post("/webhook", bodyParser.raw({
type: "application/json"
}), (webhook, res) => {
res.sendStatus(200);
return stripe.webhookParse(JSON.parse(webhook.body));
});
when I look at the example from https://github.com/stripe-samples/checkout-single-subscription/blob/master/server/node/server.js
- there is no body parser used, just express,
- we arrive at data & eventType two different ways, one through a constructor function (decryption?)
- in my use case I presume I'd need to send data and eventType into my other script for processing instead of a single parsed body variable.
So is the webhook data sent both encrypted and unencrypted, or is the use of a webhook secret the determining factor in what is sent, or am I understanding part of that incorrectly?
(funny observation, the code snippet at https://stripe.com/docs/billing/subscriptions/build-subscriptions that sent me to github has more webhook types indicated lol)
The webhook data is sent encrypted as the POST body of the request. We recommend using the Secret verification to avoid anyone being able to spam your endpoint with a realistic looking request.
that whole else block and the second arrival at the same data makes me wonder? But I guess it doesn't really matter if there's an unencrypted block or not, if our end requires, a spammer won't have an encoded body that passes basically?
and in either case it doesn't seem that the bodyParser requirement is needed right?
๐ sry lol also is sending status 200 like that as soon as I get it (after webhook secret pass now) the proper way in my case? it doesn't look like responding is conditional of anything
I'm not looking at that code directly. However I would recommend you review what we have here for a comparison
https://stripe.com/docs/webhooks/quickstart
Sending an immediate success response is the correct approach IMO
I have my own test integration where I do a lot of local DB synchronizing and other work so I have an async task queue configured. That way I receive the webhook, add the task to the queue and immediately return a 200
nice, that queue is a good idea if my integration gets busier, something to learn about later. It only syncs 4x a day and runs the checkout/portal access at the moment.
and it sounds like i've reasoned out the security part right then? LOL
I've read the docs up down and sideways. Sometimes confirmations are still needed, I literally have 1 semester of classic Java and reading code examples as my knowledge base ๐
I definitely get that. The security part is spot on. Also we've got a separate doc just for the Signatures piece here:
https://stripe.com/docs/webhooks/signatures
oh nice ๐ so many docs, I'll give that a peruse as well ๐
now just to figure out all the events I need to listen to with both subscriptions and one time access purchases being generated (only one per customer at a time thankfully) without doubling up or having conflicting work.
In that regard I assume it's normal that every 'payment' type checkout session created makes a payment intent rather than just a single event if successful? LOL
I'd have envisioned less events for people just looking around ๐
from what I am gathering so far, the payment sessions will make an intent (and send if subscribed), then complete that intent (another potential send) and send a checkout.sessions.completed event as well?
I'll toss in here: with Stripe's many interacting layers, what looks to a user like a "single" transaction (say, using Checkout to start/pay a subscription) involves many underlying parts of Stripe's capabilities (checkout session, subscription, payment intent, invoices), all of which have separate webhooks - BUT you don't HAVE to listen to all of them - most implementations just use the most relevant ones to maintain their data integrity (I most often see checkoutSession webhooks being used)
Sorry for the delay here @misty comet . @mighty flower is right, most users do not listen to all the related webhook events. For records like Subscriptions there are many related webhook events s
I like to use the Stripe CLI and stripe listen to see all the events generated but then refine my webhook endpoint to listen for the ones I want to take action on
yeah I'm being very thorough in my reading to decide what to sub to, being as I've gone 'low code' I'm assuming I really only need specific ones
that CLI I haven't used at all either ๐ probably something I should sink a few mins into working with.
thanks @mighty flower (and no worries @obtuse leaf )
I'm kinda moving away from technical advice/confirmations to 'what should I do' questions, which are ones the developer must pose to himself ๐
kinda moving away from technical advice/confirmations to 'what should I do' questions
Yeah, very often these types of questions get an "it depends...." kind of answer
Well thank you very much ๐ and have a great day!
Happy to help ๐ If you have more questions someone will be here to answer them (or at least share in the confusion ๐ )