#hoffemberg_webhooks

1 messages · Page 1 of 1 (latest)

pallid ploverBOT
#

👋 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/1290734459267579984

📝 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.

radiant rune
#

Can you share the steps you follow and what you do see?

somber pond
#

Here's an example of an http request that hits the endpoint and logs a "Webhook error while validating signature":
curl --location 'https://test.fundycentral.com/client-payment/stripe-webhook'
--header 'accept: application/xml'
--header 'cache-control: no-cache'
--header 'content-type: application/xml'
--header 'pragma: no-cache'
--header 'priority: u=1, i'
--header 'sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129"'
--header 'sec-ch-ua-mobile: ?0'
--header 'sec-ch-ua-platform: "Linux"'
--header 'sec-fetch-dest: empty'
--header 'sec-fetch-mode: cors'
--header 'sec-fetch-site: same-site'
--header 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36'
--header 'Stripe-Signature: tantest'
--data '{
"value": "test"
}'

radiant rune
#

Ok, so thats a manual request to your endpoint, cool

#

and you observe it hitting & logging an expected error due to a junk request

somber pond
#

But using the stripe cli to trigger an event like this: stripe trigger invoice.voided logs nothing

radiant rune
#

So what happens with the CLI?

#

How are you running listen and trigger exactly?

somber pond
#

$stripe trigger invoice.voided
Setting up fixture for: customer
Running fixture for: customer
Setting up fixture for: invoiceitem
Running fixture for: invoiceitem
Setting up fixture for: invoice
Running fixture for: invoice
Setting up fixture for: invoice_finalize
Running fixture for: invoice_finalize
Setting up fixture for: invoice_void
Running fixture for: invoice_void
Trigger succeeded! Check dashboard for event details.

radiant rune
#

ok, so that's trigger -- and listen is running in another terminal/shell?

#

if you've got a configured public endpoint, correct, listen is not required

#

Can you share an example event ID from those trigger tests?

somber pond
#

evt_1Q59yTIzJqdgXYvPFttUDz3U

radiant rune
#

thanks

#

just a sec

#

eg: stripe trigger invoice.voided --stripe_account acct_123

#

depending on what you're trying to test

#

Right now you're creating an event on your own account, but only listening to connected account events

#

So these don't line up

somber pond
#

Hmmm, okay. So the manual request that went to the endpoint at least logged something. But it sounds like the trigger from the Stripe cli is not actually triggering a request to the endpoint because I set the endpoint up only to listen for connected account events?

#

Okay, that actually logged something, so that must be the key.

radiant rune
#

Yep, exactly

#

event context matters

#

you had a mismatch originally on the source of the event and the type of endpoint

#

are you trying to test connected account events?

somber pond
#

Yes, our implementation is entirely for connected accounts, so those should be the only events we're looking at.

#

Now I wonder if you can guide me on the next thing. I have a deserialization error because of an API version mismatch:
2024-10-01T18:11:42.798Z INFO 173869 --- [http-nio-8080-exec-3] c.f.m.c.ClientPaymentController : Error: Deserialization failed
2024-10-01T18:11:42.798Z INFO 173869 --- [http-nio-8080-exec-3] c.f.m.c.ClientPaymentController : API Version Event: 2024-06-20
2024-10-01T18:11:42.798Z INFO 173869 --- [http-nio-8080-exec-3] c.f.m.c.ClientPaymentController : API Version Stripe: 2024-04-10

radiant rune
#

👀

somber pond
#

Presumably it's best to bring it up to the newest version. I believe I set up the endpoint to use the newest version, and I upgraded my cli using Homebrew. Is it in pom.xml that I need to change the Stripe API version?

radiant rune
#

Looking at your request logs, it appears you using stripe-java which is version pinned, and highly sensitive to version mismatches

somber pond
#

I have this dependency in pom.xml:
<dependency>
<groupId>com.stripe</groupId>
<artifactId>stripe-java</artifactId>
<version>25.13.0</version>
</dependency>

radiant rune
#

Specifically it appears you're using stripe-java 25.13.0 which is version-pinned to 2024-04-10
https://github.com/stripe/stripe-java/blob/master/CHANGELOG.md#2500---2024-04-10
Your endpoint is set for API version 2024-06-20
https://dashboard.stripe.com/test/webhooks/we_1Q58wSIzJqdgXYvP1ZDAMzdx

You need to re-create the endpoint. While you could allow it to use your account default version (since that is 2024-04-10 matches), I would recommend you set the version explicitly instead, due to the java dependency.
Specify this via the API: https://docs.stripe.com/api/webhook_endpoints/create#create_webhook_endpoint-api_version

#

You can create it for the same URL then delete the existing one (that wont work)

somber pond
#

Okay, let me try it...

#

Now I got a signature error:
: ⚠️ Webhook error while validating signature. : No signatures found matching the expected signature for payload

radiant rune
#

SUre, that's pretty common. I recommend reading through this doc for common issues around this:
https://docs.stripe.com/webhooks/signature

Most likely it is your raw request body. Though since you just recreated the endpoint, make sure you updated the signing secret to be the one for the new endpoint.

somber pond
#

Ah, that is likely it. Let me fix the service file with the new secret...

#

Whew, okay, that seemed to do it. There's something about dueDateLong being null but that's something I can work on. Thanks so much!

radiant rune
#

NP!

#

There's something about dueDateLong being null
Pointing you in the right direction on this, its likely because the test invoice automatically created for those events is using collection_method: "charge_automatically", and such invoices do not have due dates

#

Only send_invoice invoices have due dates

somber pond
#

Fantastic, that probably saved me an hour of work!

#

I really appreciate your help and I love that this resource exists.

#

Have an awesome day!

radiant rune
#

Quite welcome, glad to have saved you the time!

radiant rune