#jensen_84691
harsh wyvernBOT
Hello! We'll be with you shortly. 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.
- jensen_84691, 5 hours ago, 18 messages
- jensen_84691, 1 day ago, 40 messages
quiet schooner
Which SDK are you using? Can you share your webhook endpoint code?
How are you triggering and forwarding events to your endpoint? Using the CLI?
keen trail
using AUTHORIZE TEST PAYMENT
$payload = file_get_contents('php://input');
$sig_header = $_SERVER['HTTP_STRIPE_SIGNATURE'];
$endpoint_secret = 'xxxx';
$event = \Stripe\Webhook::constructEvent(
$payload, $sig_header, $endpoint_secret
);
quiet schooner
So you're receiving a payment_intent.succeeded event and the constructEvent method is returning 'No matching signatures found', correct?
Can you share the evt_xxx ID?
quiet schooner
And where did you pull the endpoint_secret value from? Dashboard?
keen trail
this
quiet schooner
Yep, that seems right. Can you log the value in your code and ensure it matches what's in the Dashboard? Should be similar to whsec_xxx
keen trail
I have matched it and it is exactly the same
quiet schooner
Similarly, can you log $sig_header and ensure that has a value
keen trail
I have already recorded it $sig_header
quiet schooner
Right, but does it actually have a value from the HTTP headers of ther request?
keen trail
yes i send you
t=1705398980,v1=ab0c1dd793cd24d39c4c653c443ab691f21b175b607698c59f82ead032b5e33f,v0=0d00547967c43d03360f2601032dc2c6276162c41a9bca057ce3bf5caf6c0352
quiet schooner
Seems fine. Overall, I'm not really sure what the issue is unfortunately. Are you able to process the events correctly if you remove the signature verification?
dusty wagon
can you log the value of $payload and share it here?
keen trail
this is $payload
dusty wagon
ok. Do me a favour, do another test of your Checkout page so that you generate a new event, and this time do not use 谢超 as the name of the Customer, use a name with only latin characters like "John" and see if event handling works in that case. And share the new event ID evt_xxx when you do that.
keen trail
okok
dusty wagon
also your $payload value looks wrong, it should have tabs and newlines in it.
dusty wagon
to clarify, how are you testing this? on our side as far as I can tell, our servers are not even able to connect to your URL to deliver the event.
keen trail
dusty wagon
yep, I know, but on our side we are not even able to connect to that URL (you can see that in the logs for https://dashboard.stripe.com/test/events/evt_3OZBM5JtbMy2qd3L1GlitcKW )
so I'm curious how exactly you're testing this. Are you saving the event to a file or manually sending it your server or something?
keen trail
But when I click on the Authorize TEST PAYment button, you can send the message to my server. I have successfully received it
dusty wagon
hmm ok. Not sure why on our side it says it couldn't connect.
anyway you said you thought you found out what the problem was?
keen trail
Obtaining the IP address you are using is inaccessible, and I don't know why some of my websites are accessible while others are not
dusty wagon
if it helps these are IP addresses we can send webooks from : https://stripe.com/docs/ips#webhook-notifications
keen trail
I retested it and it still doesn't work. Can you help me take a look
{
"id": "evt_3OZBvSJtbMy2qd3L0tWguAJp",
"object": "event",
"api_version": "2023-10-16",
"created": 1705408776,
"data": {
"object": {
"id": "pi_3OZBvSJtbMy2qd3L0LVMFDeU",
"object": "payment_intent",
"amount": 100,
"amount_capturable": 0,
"amount_details": {
"tip": {
}
},
"amount_received": 100,
"application": null,
"application_fee_amount": null,
"automatic_payment_methods": null,
"canceled_at": null,
"cancellation_reason": null,
"capture_method": "automatic",
"client_secret": "pi_3OZBvSJtbMy2qd3L0LVMFDeU_secret_7iswli0uXGsOurv4V0r2cFlAh",
"confirmation_method": "automatic",
"created": 1705408770,
"currency": "usd",
"customer": null,
"description": null,
"invoice": null,
"last_payment_error": null,
"latest_charge": "py_3OZBvSJtbMy2qd3L0wQe3581",
"livemode": false,
"metadata": {
},
"next_action": null,
"on_behalf_of": null,
"payment_method": "pm_1OZBvRJtbMy2qd3LrIjd3umV",
"payment_method_configuration_details": null,
"payment_method_options": {
"alipay": {
}
},
"payment_method_types": [
"alipay"
],
"processing": null,
"receipt_email": null,
"review": null,
"setup_future_usage": null,
"shipping": null,
"source": null,
"statement_descriptor": null,
"statement_descriptor_suffix": null,
"status": "succeeded",
"transfer_data": null,
"transfer_group": null
}
},
"livemode": false,
"pending_webhooks": 1,
"request": {
"id": null,
"idempotency_key": "pi_3OZBvSJtbMy2qd3L0LVMFDeU-src_1OZBvSJtbMy2qd3LBVexDzkk"
},
"type": "payment_intent.succeeded"
}
t=1705408776,v1=d2cb075b768e78259b6839382062844a8e385c7d6e9f2d6b70513fa44e022e0e,v0=4713a47df2e950958e02710653b9dac1eea43d9f191917eedbc3dc87df70131e
dusty wagon
what error are you getting now?
and what does your value for $endpoint_secret look like? I don't need the whole thing, just like whsec_xxxABCD , so I can see the last 4 digits.
keen trail
whsec_MxxxxxxxxxxnltL
keen trail
return false
The problem we are currently facing is that we are unable to pass through here ， return false
dusty wagon
is the clock on your server correct?
part of comparing the signature involves checking a timestamp, so the clock on your server needs to be in sync
keen trail
We haven't reached the timestamp yet, and now we're reporting this error
No signatures found matching the expected signature for payload
dusty wagon
We haven't reached the timestamp yet
can you clarify what you mean by this?
keen trail
I traced the code here and it did not pass validation, returning false
I don't know why the verification here is not equal now
dusty wagon
ah right
I mean all it means is what we've been discussing
either the $payload you pass it not the exact HTTP POST body we sent on the request; or the sig_header is not the exact HTTP headers we sent, or the endpoint_secret is not the exact secret for this endpoint from your dashboard
keen trail
I don't know why it's unequal here now. I can't find the problem. I paid successfully and tested the callback. The signature verification here did not pass
dusty wagon
but is hash_equals doesn't exist that seems weird
are you using some weird old version of PHP ? 🙂
keen trail
php version 7.4