この記事でわかること
- 稼働中のシステムで決済代行を乗り換える際の注意点
- Squareからサブスクペイ（ロボットペイメント）へ移行した背景と理由
- サブスクリプション決済の実装で直面した課題と対処法
- 移行時に見落としがちな入金・消し込み・カード情報の引き継ぎ
Squareからサブスクペイへ乗り換えた背景と理由
なぜSquareからの移行が必要になったか
今回の案件では、もともとSquare（スクエア）を決済代行として利用していました。Squareはシンプルで導入しやすい反面、サブスクリプション（継続課金）への対応や、柔軟なAPI連携という点では制約がある場面がありました。
事業の成長に伴い、以下のようなニーズが出てきたことが移行のきっかけです。
- 月額課金（サブスクリプション）の仕組みを本格導入したい
- 決済サイクルの自動化・柔軟な課金周期に対応したい
- 許可証の承認制など、業務フローに合わせた決済管理がしたい
サブスクペイ（ロボペイ）を選定した理由
移行先としてロボットペイメント（現：サブスクペイ）を選定しました。選定の決め手は主に以下の点です。
| 比較項目 | Square | サブスクペイ（ロボペイ） |
|---|---|---|
| 継続課金の柔軟性 | 定期請求・サブスク機能はあるが設定の自由度に制約 | 毎週〜毎年まで柔軟な課金周期に対応 |
| 決済失敗時のリトライ | 手動対応が必要な場面あり | 7日ごとに自動リトライ（最大2回） |
| API連携 | シンプルだが拡張性に限界 | Gateway方式のAPI連携で柔軟にカスタマイズ可能 |
| サブスク管理機能 | 基本的な機能のみ | プラン切り替え・課金額変更がAPI/管理画面の両方から可能 |
特にサブスク決済の自動化・リトライ機能が充実している点が、今回の案件の要件にマッチしていました。
決済代行を乗り換える時の注意点5選
稼働中のシステムで決済代行を乗り換える際、以下の5つのポイントを事前に押さえておくことが重要です。
1. 現行システム・DBとの整合性チェック
まず取り組んだのが、現在のデータベースやシステム構成を踏まえて、移行が実現可能かどうかの検討です。
決済代行会社によって、連携できるAPIの仕様やデータの持ち方は異なります。たとえば、Squareで管理していた決済トランザクションIDの体系と、サブスクペイ側のIDの体系が異なるため、既存のDBスキーマにどう紐づけるかを設計し直す必要がありました。
既存の構成をそのまま活かせるのか、改修が必要なのかを一つずつ精査していくことが、移行プロジェクトの最初のステップです。
2. API仕様の差異と改修範囲の特定
SquareのAPIとサブスクペイのAPIでは、リクエスト/レスポンスの形式やエンドポイントの設計思想が異なります。
サブスクペイはGateway方式のAPI接続を採用しており、開発者向けのドキュメントも整備されていたため、連携自体はスムーズに進められました。ただし、既存のSquare連携コードを全面的に書き換える必要があったため、改修範囲の洗い出しには時間をかけました。
3. 入金サイクル・消し込み運用の再設計
移行で意外と見落としがちなのが、入金処理や消し込み（入金確認・突き合わせ）の運用です。
決済代行会社が変わると入金サイクルも変わります。ここで注意すべきなのが、旧会社（Square）の最終入金と、新会社（サブスクペイ）の初回入金のタイミングにギャップが生じる可能性がある点です。
このキャッシュフローの空白期間を事前にシミュレーションし、資金繰りに影響が出ないよう対策を講じました。また、経理チームとも連携し、消し込みのフローを新しい入金サイクルに合わせて再設計しました。
4. 既存顧客のカード情報移行と案内
決済代行の乗り換えで最も慎重な対応が求められるのが、クレジットカード情報の取り扱いです。
PCI DSS（カード情報のセキュリティ基準）の制約により、カード情報を事業者側で直接保持・移行することは原則できません。そのため、以下のいずれかの対応が必要になります。
- 旧決済代行会社と新会社間でのカード情報移行手続き（両社の協力が必要）
- 顧客にカード情報を再登録してもらう（離脱リスクがある）
今回は、既存顧客に対して事前に案内を行い、カード情報の再登録をお願いする形で対応しました。顧客への説明文やFAQの準備、移行スケジュールの事前告知など、技術面だけでなくコミュニケーション面の準備も重要でした。
5. 並行稼働期間の確保とテスト
新しい決済システムが完全に稼働するまで、旧・新の決済代行を一時的に並行稼働させる期間を設けました。
この期間中に行ったことは以下の通りです。
- 少額でのテスト決済（課金〜返金までの一連のフロー検証）
- 管理画面への売上データ反映の確認
- 旧システムでの未処理の受注・返金処理の完了
本番切替前にテスト決済を複数回行い、決済処理だけでなくキャンセル・返金フローまで検証することで、切替後のトラブルを防ぐことができました。
サブスク決済の実装で直面した課題と解決策
今回の移行では、サブスクリプション決済の新規実装も行いました。サブスク化特有の難しさとして、以下のような課題がありました。
プラン切り替え時の処理設計
顧客がプランを変更する際、課金額の変更タイミングと日割り計算をどう扱うかが大きな検討ポイントでした。
サブスクペイでは、課金額変更がAPI/管理画面の両方から可能なため、システム側で柔軟に対応できました。ただし、プランのアップグレード・ダウングレードそれぞれで課金ロジックが変わるため、パターンごとの設計が必要でした。
決済サイクル設計のポイント
サブスクペイは毎週・隔週・毎月・隔月・3ヶ月毎・半年毎・毎年に対応しています。今回は月次課金を採用しました。
ここで重要なのは、決済サイクルの設計は後から変更しづらいという点です。顧客への案内や経理処理にも影響するため、実装前の段階でクライアントと十分にすり合わせました。
既存顧客のサブスク移行フロー
すでにいる顧客をサブスクリプションへ移行する際、以下の流れで対応しました。
| ステップ | 内容 |
|---|---|
| 1. 事前告知 | メール等で移行スケジュールと変更内容を案内 |
| 2. カード再登録 | 新しい決済フォームからカード情報を再入力してもらう |
| 3. サブスク開始 | 初回課金を実行し、以降は自動継続課金 |
| 4. 旧決済の停止 | Square側の課金を停止・契約解除 |
実装にあたっては、クライアントと決済代行会社（サブスクペイ）の担当者様との打ち合わせを重ねながら、問題点を一つずつクリアにしていきました。
サブスク化で得られたメリットと事前に考えておきたいこと
サブスク化のメリット
サブスクリプション型に移行することで、以下のようなメリットが見込めます。
- 安定した収益基盤の構築 – 毎月の売上予測が立てやすくなる
- 決済サイクルの自動化 – 手動での請求・入金確認作業が大幅に削減される
- 顧客管理の効率化 – 契約状況・課金履歴を一元管理できる
- 解約率（チャーンレート）の可視化 – 事業改善のための指標が取れるようになる
一方で検討が必要なこと
ただし、サブスク化は導入すれば終わりではありません。初期顧客をどう集めるかという点は、別途しっかり検討する必要があります。
そのための仕組みとして、たとえば以下のような施策が考えられます。
- 無料プランの用意（まず使ってもらうための入り口）
- 早期割引・初月無料（初期段階の顧客獲得を促進する仕組み）
- 既存の都度課金ユーザーへのサブスク移行キャンペーン
収益の安定というメリットを活かすためにも、入口となる顧客獲得の設計はセットで考えておきたいところです。
決済代行の乗り換えを成功させるためのチェックリスト
最後に、決済代行の移行を検討している方向けに、事前チェックリストをまとめました。
移行前の調査・準備
- [ ] 現行システムのDB構成・API連携箇所の洗い出し
- [ ] 新しい決済代行会社のAPI仕様書の確認
- [ ] カード情報の移行方法の確認（データ移行 or 顧客再登録）
- [ ] 入金サイクルの比較とキャッシュフローのシミュレーション
- [ ] 既存顧客への告知スケジュールの策定
実装・テスト
- [ ] 改修範囲の特定とスケジュール策定
- [ ] テスト環境での決済・返金フローの検証
- [ ] 並行稼働期間の確保
- [ ] 少額テスト決済の実施（本番環境）
切替・運用開始
- [ ] 旧決済代行での未処理の受注・返金の完了確認
- [ ] 経理チームへの消し込みフロー変更の共有
- [ ] 既存顧客へのカード再登録案内・フォローアップ
- [ ] 旧契約の解約手続き
決済代行の乗り換えやサブスク化は、技術的な実装だけでなく、既存システムとの整合性、カード情報の移行、入金・消し込みの運用、既存顧客への対応、そして新規顧客の獲得設計まで、幅広い視点での検討が求められます。
今回のSquareからサブスクペイへの移行では、関係者との打ち合わせを重ねながら一つずつ問題点をクリアにすることで、スムーズな移行を実現できました。決済代行の移行やサブスク化を検討されている方は、ぜひ事前の調査・設計を丁寧に行ったうえで進めることをおすすめします。
