#geoffrey-s_unexpected

1 messages ยท Page 1 of 1 (latest)

tulip boneBOT
#

๐Ÿ‘‹ 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/1354097122504347728

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

scarlet juniper
#

The API Call on the 22 jan :

zinc dragon
#

Hello, thanks for the example. Looking in to this

scarlet juniper
#

The one on the 18 feb after an update :

#

We can see the difference in the canceled_at

zinc dragon
#

Can you paste the text of those? Easier for me to search with the info from there

scarlet juniper
#

Yes i'll do it

#

POST Query on the 22 jan :
{
"cancel_at_period_end": "true",
"expand": {
"0": "items.data.price",
"1": "latest_invoice.payment_intent",
"2": "pending_setup_intent",
"3": "discounts"
}
}

#

POST Query on the 18feb :
{
"payment_settings": {
"payment_method_types": {
"0": "card",
"1": "paypal",
"2": "sepa_debit"
}
}
}

zinc dragon
#

Yep, so to untangle one date from this cancel_at_period_end was set on Jan 18, at that point the period end was Feb 21. I am still unclear how the sub cancelled on Feb 18th. That request doesn't have anything that I would expect to cancel the subscription

#

I will consult my colleagues on this and get back with what we can find

scarlet juniper
#

Just to be clear, the cancellation was asked on the 22 jan

#

and the second update was made on the 18 feb

#

and the subscription cancel date is on 22 feb (that's correct)

#

The invalid date is canceled_at where it should be 22 jan instead of 18 feb

zinc dragon
#

It looks like this is a known bug with the canceled_at timestamp though one thing to note is that that is separate from cancel_at and the subscription still will cancel on the correct date.
Unfortunately I don't have an ETA on the fix, so I think the best workaround would be to check the subscription's status before checking canceled_at to determine if a subscription has been cancelled.

scarlet juniper
#

Thanks for the help! Basically I have an history with all changes so it's fine !