Funny that you mention Stripe, because it was definitely the canonical backwards compatibility API for me.
... Until just recently in mid Nov they changed some behavior that caused us to double/triple/quadruple charge customers unintentionally in some not-so-uncommon edge cases... I’m still trying to square this one with their support, so details are a bit thin. But definitely a big surprise for me to see this happening when previously I never imagined something like this can happen given the API versioning stability.
You know, you just jogged my memory here. We did have an issue with Stripe changing the order / timing of payment_failed webhooks, which caused them to be sent before the next payment attempt was known.
We used the payment failed hook to send an email to our customers and let them know when we'd be retrying the charge, which was no longer possible because the next_payment_attempt field was null. Before the change, a next_payment_attempt=null meant the charge would not be retried.
I reported the issue and the webhook changes were rolled back a month later. Really threw a wrench into our flow.
I will say that generally speaking, Stripe is the canonical backwards compatibility API in my mind. With a few edge cases.
... Until just recently in mid Nov they changed some behavior that caused us to double/triple/quadruple charge customers unintentionally in some not-so-uncommon edge cases... I’m still trying to square this one with their support, so details are a bit thin. But definitely a big surprise for me to see this happening when previously I never imagined something like this can happen given the API versioning stability.