前書き サブスクリプション型のSaaSサービスを利用するとき、多くの場合はアカウントを作成し、何らかのサブスクリプションを購入します。1つだけ購入する場合もあれば、複数のサブスクリプションを購入したり、組織単位で購入するケースでは、部署単位でアカウントがあり、各部署で複数のサブスクリプションを購入している、ということも考えられます。当然のことながら、そのサブスクリプションには、購入したサービスに関連するリソースが紐づいています。多くの場合、サブスクリプションをキャンセルすると、そのリソースは使用できなくなります。リソースを別のアカウントに移す場合は、別のアカウントを作成し、そちらにリソースのバックアップなどからデータを復元する作業が必要です。 解決する課題 現行利用しているサービスの状態をそのままに、サブスクリプションの対象となるアカウントを変更する。 Stripeを利用したサブスクリプションの一般的な構造 多くの場合、Stripeを利用したサブスクリプションでは、サービスを購入すると、Stripe上にサブスクリプションを作成し、そのIDをサービスのリソースと関連付けます。この記事では、上のようなSaaSの構造を前提として説明を進めます。 期待する結果 Stripeのサブスクリプションを更新するAPI Update Subscription API は、 そのサブスクリプションに関連づいた カスタマー(Customer) を変更することはできません。そのため、サブスクリプションの譲渡は、新しいサブスクリプションを譲渡先のカスタマーに作成し、譲渡の対象となるサービスのリソースを新しいサブスクリプションに関連づけます。 サブスクリプションの譲渡方法 前述したように、サブスクリプションを譲渡するには、サブスクリプションのキャンセルと作成の操作が必要です。 引き継ぎ元のサブスクリプションをキャンセル (Cancel Subscription API / Delete subscription item […]