Stripe から Mollie への移行で本当に壊れるもの

決済プロバイダーの切り替えは、APIを差し替えるだけでは終わらない。あるフィンランドの開発者がStripeから突然アカウントを停止され、Mollieへ移行した記録が公開されている。その記録が示しているのは、決済処理そのものより、その周辺に積み重なった「プラットフォームの機能」を再実装するコストが本質的な問題だという点だ。

Stripe はチャージ API ではなくビリングプラットフォームだった

Stripeを長期間使ってきたシステムが依存するのは、単純な「カードを課金する」処理だけではない。Subscriptions（定期課金の管理）、Customer Portal（顧客が自分のプランを変更・解約できるWebUI）、Stripe Tax（消費税・VATの自動計算と申告支援）、Invoicing（請求書の発行）、Smart Retries（支払い失敗時の自動再試行）、Proration（プランの途中変更時の日割り計算）——これらはすべてStripeの機能として動いている。利用しているという意識が薄くなるほど自然に組み込まれているため、切り替えの際に初めてその存在に気づくケースが多い。

MollieはEU拠点の決済サービスで、iDEALやBancontact、SEPAといった欧州の地域決済手段をサポートする。ただしアーキテクチャの思想が根本的に異なる。Mollieは「薄い決済レイヤー」として設計されており、Stripeが内包する請求管理の仕組みをそのままでは持っていない。

サブスクリプションの再実装に二週間かかった理由

StripeのSubscriptionオブジェクトは、プランの状態・請求サイクル・失敗時の挙動・顧客の支払い方法をまとめて管理する単一のリソースだ。対してMollieには同等のオブジェクトが存在しない。代わりに「Customer（顧客）」と「Mandate（顧客がカードへの引き落としを許可する同意）」を組み合わせて定期課金を自前で構築する設計になっている。

具体的には、顧客がチェックアウトを完了した時点でMandateを取得し、以降はそのMandateを使って自分のバックエンドから定期的に課金リクエストを送る実装が必要になる。請求サイクルの管理、失敗時のリトライ、解約フラグの管理はすべてアプリケーション側の責務になる。

Webhookの仕様も異なる点として注意が必要だ。StripeのWebhookはイベントタイプ（`payment_intent.succeeded`など）とペイロード、署名検証のためのシークレットをセットで送る。Mollieが送るのは決済の `id` だけで、イベントタイプも本文も含まれない。受け取ったシステムはそのIDを使ってMollie APIに問い合わせ、最新の状態を自分で取得する設計だ。署名ベースの検証もないため、リクエストの送信元が正規のMollieサーバーかどうかをIPアドレスなどで別途検証する実装が求められる。

// Mollie Webhook の受け取りイメージ (Next.js API Route)
export async function POST(req: Request) {
  const body = await req.formData();
  const id = body.get('id') as string;
  // id しか来ないので自分で取得しに行く
  const payment = await mollieClient.payments.get(id);
  if (payment.status === 'paid') {
    // DB 更新・サービス有効化など
  }
}

既存サブスクライバーの移行はできない

移行で最も見落とされやすい制約が、既存の定期購読者を自動移行できないという点だ。Stripeに登録されたカードのMandateはStripeのインフラ上に紐づいており、Mollieに転送する手段はない。つまり移行時点で有効なサブスクライバー全員に再度チェックアウトを踏んでもらう必要がある。一定数の離脱は避けられない。

これはStripe固有の問題ではなく、PCIDSSという国際カードブランドのセキュリティ基準上、生のカード番号を他社へ渡すことが原則禁止されているためだ。同様の制約はほぼすべての決済プロバイダー間の移行で発生する。

移行前に確認すべき設計上のポイント

今回の事例から整理すると、決済プロバイダーを切り替える際に事前に棚卸しすべき項目は次のとおりだ。

サブスクリプション管理: プロバイダー依存か、自前のDBで状態管理しているか
税務処理: 自動計算に依存しているか、税率テーブルを自前で保持しているか
Customer Portal: プロバイダー提供のUIを使っているか、独自実装か
Webhook: イベント型か、IDポーリング型か、署名検証の有無
請求書: プロバイダーが発行するか、自前のテンプレートがあるか
既存サブスクライバーへの再認証フロー: 告知・猶予期間・離脱見込み

日本のシステムでStripeを使っている場合、Stripe Taxや消費税の処理をStripe側に依存しているケースでは、移行後に軽減税率の扱いや適格請求書（インボイス）番号の記載をアプリケーション層で実装し直す必要が生じる可能性がある。

Mollie以外の選択肢として、同じEU圏ではAdyen（エンタープライズ向けで最小取扱高の条件が厳しい）やSumUp（中小向け）がある。日本ではPAY.JPやGMOペイメントゲートウェイが類似のポジションに位置し、それぞれStripe同様のサブスクリプション機能の実装範囲が異なる。

今回の移行が示しているのは、決済プロバイダーは「差し替え可能な外部API」ではなく「ビジネスロジックを委譲したプラットフォーム」として機能しているという事実だ。依存の深さを把握しないまま移行を計画すると、一日で終わるはずの作業が数週間になる。