Had a user whose card started refusing payments, eventually causing the subscription to self-cancel. The cancellation was reflected on both Stripe and Splits.io correctly. However when they tried to re-subscribe using a different card, they say "it does the processing and tells [them] it's paid", but they don't receive Gold at all.
Digging into Stripe, for this new attempt no payment was ever charged, and no customer was ever successfully created or updated. I worked around the issue by deleting the old Subscription on our end (the one that had been successfully marked as canceled) and asking the user to try subscribing again with the new card. That worked.
When a user hits Pay on Stripe's checkout flow, the button becomes a spinner while Stripe tries to send us a webhook. If we're too slow to respond or error, the button will be a spinner for longer than usual but will still eventually tell the customer the flow succeeded. I think this is intentional behavior for Stripe, who assumes the error is transient and that we'll process the failed webhook later (we don't). So this would explain why the person believed the payment succeeded even though it didn't.
First place to look for debugging this is probably to find out if the Stripe webhook fails when there is an existing (but canceled) Subscription for that user ID or Stripe customer ID.
Had a user whose card started refusing payments, eventually causing the subscription to self-cancel. The cancellation was reflected on both Stripe and Splits.io correctly. However when they tried to re-subscribe using a different card, they say "it does the processing and tells [them] it's paid", but they don't receive Gold at all.
Digging into Stripe, for this new attempt no payment was ever charged, and no customer was ever successfully created or updated. I worked around the issue by deleting the old
Subscriptionon our end (the one that had been successfully marked as canceled) and asking the user to try subscribing again with the new card. That worked.When a user hits Pay on Stripe's checkout flow, the button becomes a spinner while Stripe tries to send us a webhook. If we're too slow to respond or error, the button will be a spinner for longer than usual but will still eventually tell the customer the flow succeeded. I think this is intentional behavior for Stripe, who assumes the error is transient and that we'll process the failed webhook later (we don't). So this would explain why the person believed the payment succeeded even though it didn't.
First place to look for debugging this is probably to find out if the Stripe webhook fails when there is an existing (but canceled)
Subscriptionfor that user ID or Stripe customer ID.