#mink4501_webhooks

1 messages · Page 1 of 1 (latest)

humble riverBOT
#

👋 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. Thank you for your patience!

⏱️ We automatically close idle threads, which makes them read-only. Make sure you stick around to chat in realtime! If this thread is closed and you have another question you'll need to start a new thread.

🔗 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/1214107214206476288

📝 Have more to share? You can add more detail below, including code, screenshots, videos, etc.

dim smeltBOT
#

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.

plush arrow
uncut phoenix
#

Disable behavior
In live and test mode, Stripe attempts to notify you of a misconfigured endpoint by email if the endpoint hasn’t responded with a 2xx HTTP status code for multiple days in a row. The email also states when the endpoint will be automatically disabled.

#

Too abstract.

I'd like to see a clear disable condition, like the error rate must remain at 100% for 7 days or more.

plush arrow
#

There's all the information I can share. The important thing here is to make sure your endpoints respond 200 to webhook events immediately.

uncut phoenix
#

Okay thank you!

#

I have a few more questions.

I'm using the Checkout Session API to create subscriptions.

Q1. How can I get the client_reference_id inside the Checkout Session when the invoice.paid events are sent?

Q2. How can I get the client_reference_id inside the Checkout Session when the charge.refunded events are sent?

Q3. How can I get the client_reference_id inside the Checkout Session when the customer.subscription.updated events are sent?

plush arrow
#

None of them are checkout session events, so they aren't directly related to a checkout session objects. Why don't you listen to checkout.session.completed instead? Or can you tell me the business objctive that you want to achieve so that I can help you come up with a solution?

uncut phoenix
#

checkout.session.completed is only sent when the subscription is first started.

Then, when the subscription reaches its next cycle and a payment is made, invoice.paid is sent. Therefore, the value of the client_reference_id at the time of checkout.session.completed is required when events such as invoice.paid, charge.refunded, and customer.subscription.updated are sent.

# 
Or can you tell me the business objctive that you want to achieve so that I can help you come up with a solution?

Good point! Wait a minute please

#

We need to inject the identifier that our system generates at the point of subscription, and we want to use it. We can put it in client_reference_id, we can put it in metadata.

If we put it in the metadata, it could cause a system failure because anyone can change it in the Stripe Console. So, we wanted to put the identifier that our system issues in the client_reference_id and use it to look up when other events happen.

plush arrow
#

"anyone can change it in the Stripe Console" -> only if the person has access to your API secret key, or restricted key.

#

You should keep your API key safe, so that only authorized person can make API requests on behalf of you.

uncut phoenix
#

No

plush arrow
#

Can you tell me why you think otherwise?

uncut phoenix
#

I did a test yesterday.

I was able to change the metadata in the Stripe Console, even though I had given analyst permissions to my email.

plush arrow
uncut phoenix
#

The following permissions were enabled to edit Stripe Subscription metadata in the Stripe Console

  1. Administrator
  2. Developer
  3. analyst

Additionally, there were other permissions that could be modified, but I don't remember exactly.

First of all, the most important thing is not which permissions can be modified.

It's that it's very dangerous to rely on this meta information because it can be arbitrarily modified. Therefore, you can't use metadata.

plush arrow
#

Please share with me the ID of the request so that I can investigate further.

uncut phoenix
#

Enables buttons that can be edited in the Dashboard, rather than requests. I'll capture it and show you in a second.

#

Please see this

#

Since most permissions are all metadata modifiable, putting an identifier in there is very dangerous because anyone can modify it.

plush arrow
#

What's the request ID?

#

Or share with me the subscription ID

uncut phoenix
#

sub_1OW8n2H7t32LLKQxxLos7TUw

#

This is a console, so there is no request ID.

plush arrow
#

And when did you update the metadata ?

uncut phoenix
#

I've never updated it.

If we want to put our issued identifier in the metadata, it shouldn't be updateable. But it can be updateable, which is why I can't put the identifier in the metadata.

plush arrow
#

I don't understand you, and I don't see any request to update the metadata of the said subscription.

uncut phoenix
#

If you look at the screen I captured, I'm an analyst and the Edit metadata button is enabled to allow me to make updates in the console.

plush arrow
#

Can you press the save button so that I can view the request?

uncut phoenix
#

Ok

#

Let's add a new key

plush arrow
#

Change the metadata and press the save button

uncut phoenix
plush arrow
#

Let me know when you are done

uncut phoenix
#

request_id
req_Ka66rF5bS5keZf

#

"metadata": {
"subscriptionId": "1eeadcf7-92f7-6904-8f55-1df58a28f9fa",
"jack_stripe": "please help me"
},

#

You have analyst permissions and the metadata addition succeeded.

If someone removes or modifies the subscriptionId field, my system will crash. The metadata field should not be modifiable, even if you have developer or administrator privileges.

plush arrow
#

Payment Analyst do have permission to create payments, so they can modify the metadata. THis is expected behaviour.

#

If it's not what you expect, you should choose a different role.

uncut phoenix
#

So... there has to be a way to read the client_reference_id field, which can't be changed as a result. The metadata can't be used.

plush arrow
#

No. If you don't want your team member to change payments, you should give them an appropriate role.