Вы не можете различать два последних случая, так как сама панель управления использует API.
Однако вы можете различать автоматическое и ручное отмена. Просто посмотрите на атрибут request в теле события customer.subscription.deleted.
Если подписка была отменена автоматически после слишком большого количества неудачных платежей, то request будет иметь нулевое значение.
В противном случае, если подписка была отменена через API или приборную панель, request будет иметь ненулевое значение: идентификатор запроса ("req_...") в subscription cancelation request.
EDIT: в Йони Рабинович отметил, это верно, если подписка была отменена с at_period_end=false (или нет at_period_end параметра, так как false значение по умолчанию).
Если подписка была отменена с at_period_end=true, тем customer.subscription.updated события будет уволен немедленно (чтобы отразить тот факт, что атрибут данной подписки cancel_at_period_end теперь является истинным), и что мероприятия request будет иметь идентификатор запроса запроса подписки аннулирования аккаунта.
Однако событие customer.subscription.deleted, которое будет отправлено, когда подписка будет фактически отменена в конце расчетного периода, будет иметь request=null, как автоматическое отмена после слишком большого числа неудачных выплат.
Фантастический! Большое спасибо. Атрибут «запрос» сделает работу для меня. Благодарю. – user3204760
Из того, что я вижу, атрибут запроса в событии customer.subscription.deleted имеет значение NULL, если подписка автоматически отменяется в конце периода, так как cancel_at_period_end был установлен в true для подписки. Поэтому кажется, что проверка атрибута «запрос» недостаточна для определения того, что подписка была отменена из-за неудачных платежей. –
@YoniRabinovitch Ты абсолютно прав. Я отредактировал свой ответ, чтобы указать, что происходит в этом случае. – Ywain