#whimsy_api
wild havenBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1306701758545920000
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- whimsy_portal-differences, 32 minutes ago, 11 messages
- whimsy_customer-list, 6 days ago, 65 messages
- whimsy_subscription-event, 6 days ago, 68 messages
fervent nebulaBOT
ashen plume
Hi 👋 no, there is no function or endpoint for verifying webhook signing secrets, as they are secret values and should not be shared or transmitted.
If an invalid secret is provided, signature verification for the Event will fail. You can try to use that as an indication that the provided secret is incorrect, but it will be hard to differentiate that from other causes that prevent signature verification from succeeding.
Can you tell me more about what you're building? Is this a Connect Platform?
somber granite
uh, its not connect platform, its just kind of abstract way of how i handle subscriptions, like nothing more than few classes to create/delete subscriptions and a webhook handler
and like this ofc, but yeah its tricky to check for secret of webhook because if it is invalid, user wouldn't know until they get event, which then ruins instant processing or such
ashen plume
Taking a step back though, you're trying to build a service where you're offering a prebuilt Stripe integration for others to use?
somber granite
its for myself for multiple projects for plug and use
ashen plume
Hm, I'm not sure I'm following then, as you would know the secret of your own webhook endpoints.
somber granite
yes but its different across apps and sub-accounts on stripe
ashen plume
Webhook signing secrets are unique from one webhook endpoint to the next, even within the same Stripe account.
somber granite
not sure how that even matters, what if i maybe accidently pass in wrong one, or smth happens in my code when using a package that makes the secret malformed
would just generally love to have a way to check that or avoid it
like i kinda said above, my other idea would be to let package take care of webhooks by creating and identifying them by some unique metadata
ashen plume
There isn't an endpoint or function that we offer for verifying the validity of a signing secret, nor would we build one as secret values like that shouldn't really be transmitted.
somber granite
yes i know as you stated that above, now im trying to find some alternative that doesnt have to deal with that issue
ashen plume
I guess if you can't trust that your code is using the correct value for your endpoint, then yeah, creating new endpoints sounds like a possible solution.
somber granite
hm
small other question, what's the difference between charge.dispute.xyz events and issuing_dispute.xyz, they seem to be the same or?
ashen plume
charge.dispute.* is for when you're processing payments and a customer initiates a dispute with their issuer/bank.
https://docs.stripe.com/disputes
issuing_dispute.* is for when you're using Stripe Issuing to be the credit provider, and need to handle your cardholder wanting to dispute an issuing transaction.
https://docs.stripe.com/issuing/purchases/disputes
somber granite
so if im just using normal subscriptions api, i should be looking out for 1st ones?
ashen plume
Yup
somber granite
from dispute event, how can i construct valid url for user to go to? or is there some way to test out disputes
ashen plume
A URL for a user to go to in order to do what?
somber granite
to view/manage a dispute from stripe dashboard
ashen plume
So in this case a user is one of your team members?
The test cards in the Disputes section of our test card list can be used to simulate various dispute flows:
https://docs.stripe.com/testing#disputes
somber granite
So in this case a user is one of your team members?
The test cards in the Dispu...
yep, the person using the package, aka someone with access to stripe dashboard
ashen plume
I'm less familiar with the dashboard side of these flows. I'd recommend creating a Dispute in testmode and see how it is represented in your dashboard. You can likely look at how the URLs are constructed and work to build that based off of the object IDs involved.
somber granite
yep thanks
are those all test card numbers there are or
or is there a place where all of them are listed
ashen plume
They're more or less all there.
somber granite
oh i see below