#haletothewood-webhook-signature-signing
full elm
To clarify, are you seeing issues with the CLI or this endpoint: https://discord.com/channels/841573134531821608/938399415318753310
honest breach
Not CLI, in our webhook that's triggered by the stripe event
We have a lambda triggered via API Gateway -> SQS -> Lambda
full elm
Got it, an just see that that specific event was also triggered in the CLI
honest breach
I'm not sure what you mean?
Ah
Right I triggered it via the stripe console using test authorization
honest breach
According to the stripe developer console the event fired successfully
full elm
It has yes, and your endpoint has responded with a 2xx status code indicating success
honest breach
Yeah that's a bit of a red herring at the moment
We failed to process it regards to our business logic although it was successfully triggered
full elm
And you're using the signing secret from the Dashboard for that webhook (we_1K6dqSHBmNTLCfPLdUGMNflH)? It ends with weu2.
honest breach
Yes
full elm
We failed to process it regards to our business logic although it was successful...
If you signing secret verification is failing, I'd not recommend returning a 2xx response. You should throw an exception at this point
honest breach
Nothing has changed except the event we listen to
full elm
Hmm, the signature verification wouldn't suddenly break depending on what events the webhook was subscribed to
honest breach
That's what I thought
I can give you an example in production too, one sec I'll get the event id
evt_1KOgfaQjqwmkmLtpYhrSUvDd
This is a real authorization, that led to the same error message
full elm
Those events are not really any help here, as they're showing as successful (as you're returning 2xx despite the verification failure)
honest breach
Urgh, yeah, fair
full elm
The issue is likely to be either:
• Mixup in signing secret variables somewhere (they're unique per endpoint, this includes live/test).
• A recent change in your code (can you share part of the handler where you handle the signature verification).
honest breach
That helps direct my debugging efforts, thank you.
try {
stripeEvent = stripe.webhooks.constructEvent(
stripeEventPayload,
stripeEventSignature,
process.env.STRIPE_WEBHOOK_KEY
);
} catch (err) {
throw new Error(
Stripe webhook error message: ${err.message}, cannot process Stripe event
);
}
stripeEventSignature looks correct. I'll check the value of STRIPE_WEBHOOK_KEY matches the webhook secret.
full elm
Can you share the stripeEvenrPayload?
constructEvent can often be difficult with Node as it expects the raw body from the HTTP request (not the JSON or whatever)
honest breach
From our test
stripeEvent: {
id: 'ipi_1KOhjEQaFntjgR7RAfSwgMlY',
object: 'issuing.transaction',
amount: -1000,
amount_details: { atm_fee: null },
authorization: 'iauth_1KOhjDQaFntjgR7RovembjVR',
balance_transaction: 'txn_1KOhjEQaFntjgR7RwEjRGG7h',
card: 'ic_1KOIKzQaFntjgR7RYtISZ4he',
cardholder: 'ich_1KOIKyQaFntjgR7RF3AnM9lX',
created: 1643804068,
currency: 'gbp',
dispute: null,
livemode: false,
merchant_amount: -1000,
merchant_currency: 'gbp',
merchant_data: {
category: 'boat_rentals_and_leases',
category_code: '4457',
city: 'San Francisco',
country: 'US',
name: 'Geoffs Gifts',
network_id: '1234567890',
postal_code: '94103',
state: 'CA'
},
metadata: {},
type: 'capture',
wallet: null
}
}
Ah wait this is not the raw payload, I'll have to add a console log and redeploy
full elm
Sorry, not stripeEvent, but the stripeEventPayload argument that you're passing to webhooks.constructPayload
honest breach
Also I realise I switched back to transaction not authorization to see if it made a difference
full elm
I know AWS has some oddities regarding this, where they often parse the incoming payload (unbeknownst to you)
honest breach
Yeah, we encountered that and wrote some config to parse the Stripe_Signature and pass it through as part of the event.record.body
This was working until today
full elm
We have some internal notes on AWS stuff related to this, let me check
There's also various issues on the stripe-node repo relating to this, this is the 'canonical' one: https://github.com/stripe/stripe-node/issues/356
honest breach
The weird thing is we solved that and it was working 🤷
full elm
You said you're using API Gateway right?
honest breach
Yes our flow is API Gateway -> SQS -> Lambda
And we have a mapping template to ensure the strip signature is passed through
Action=SendMessage&MessageBody=$input.body&MessageAttribute.1.Name=stripe_signature&MessageAttribute.1.Value.DataType=String&MessageAttribute.1.Value.StringValue=$input.params().header.get("Stripe-Signature")
Which is still working as we are able to see that signature in the lambda
full elm
It's not the Stripe-Signature header that AWS is likely manipulating, but the payload body
honest breach
So I just tried again in dev and it seemed to be verified
Which is nice. I'm now going to change the event again to issuing_authorization.created and try again
However, another thing to note. Whenever we fire a test authorization we seem to receive events for all past test authorizations too. We see a tonne of logs of old events and the timestamp is out of range so they all fail.
full elm
My guess is that's related to this: https://stripe.com/docs/issuing/controls/real-time-authorizations
i.e. you need to make an API call to approve/decline the request before responding
I'm not sure really, I haven't used Issuing much!
Did you manage to make any progress with signing verification?
honest breach
Thanks for that. I'm redploying serverless and terraform so just waiting on that then I'll run another test.
full elm
Can you not emulate the AWS environment locally with Docker? Wondering if there's an easier flow to test this with the CLI forwarding events
honest breach
Oh man, dont get me started
I'll cry at my desk
It worked 🎉
Thanks for your help I think it was the webhook secret. 👎
Oops meant 👍
full elm
The secret was wrong?
honest breach
Yes. I didn't realise it changed if you re-provision it via terraform.