#crawl_webhooks

1 messages · Page 1 of 1 (latest)

celest briarBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1260271985259315343

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

eager beacon
#

hello! you use the same event except the "subscription upgrade/downgrade" case will have previous_attributes hash showing you the old price that was changed and the Event body's items.data[0].price field will have the new price

there's also the Subscription's Invoice's billing_reason field which you can look at to tell what it was for: https://docs.stripe.com/api/invoices/object#invoice_object-billing_reason

safe sphinx
#

okok got it

#

also is it normal if a checkout session is being created with a trial days, even though we specify no days ?

eager beacon
#

trial would only be there if you've set up something about a trial, either on the Checkout Session creation or coming from the Price/Plan

safe sphinx
#

seems like we have customer that exploit this,
they cancel there trial before the end and purchase a trial back

we handle this by creating the checkout sessions dynamically based on that

but it's still there

eager beacon
#

not expected to have a trial if you don't want it to 😅

#

but it's still there
share the Checkout Session ID and I can tell you why it is happening

safe sphinx
#

My assumption is that we make it empty in the code, but on the plan/price dashboard we have something up

eager beacon
#

but on the plan/price dashboard we have something up
yep could be

safe sphinx
#

prod_P4iOaJOXU25PJt
price_1OGYy5LM4GHVXwuAzcovj0eZ

eager beacon
#

can you share the Checkout Session ID too? can have a look

safe sphinx
#

this customer is exploiting
cus_OaHG4bZMKiHKi7

#

basically start a trial on a card with insuficient fund, that fail once we try to fallback cancel on them

eager beacon
#

do you have the CheckoutSession ID? Looks like cs_123

safe sphinx
#

but payment will succeed, because he's having a trial he's not suppose to have in the first place

#

just a sec

#

cs_live_a12KuDFHCmk0gIuZlfAyOS3Gqt5JArxKfPkSFWqj9L4Ks2fRg1hvgxlTm6

#

first one session was this one

cs_live_a1Q4Tsu2OzDGlRgOQ3CvNd8yyv7XngCJy9Q7zJVtM9sRZrTgYRdCSbMFhG

#

basically the same customer

eager beacon
#

looking at your Checkout creation requests for those two

safe sphinx
#

yeah

eager beacon
#

even though we specify no days ?
so that part seems incorrect to me based on what your code is passing to Stripe

safe sphinx
#

checking out our prod logs

eager beacon
#

yep you can open those requests in Stripe Dashboard, that is what your code passes to Stripe

safe sphinx
#

we have

user.paidUser:"false"
user.hadTrial:"true"
....

so we know he already had a trial before creating the checkout session

#

oh wait

#

i think i got it

#

seems like he's doing a edge case tricks, to bypass our checks ahahah

#

just need to confirm, but if it's the case, then he's really smart

eager beacon
#

yeah you'd need to check if they have/had a trial in the past say within the last n months so they don't exploit it this way

safe sphinx
#

we do have this, but we forgot about an case

#

checking the month seems to solve this issue

#

thanks for the help on those 2, i appreciate that

#

will go test the solution and come back

eager beacon
#

glad to collaborate! 🤝