結論
Payment Links は URL を共有して決済まで完結させる低コードの入口 です。
一方、B2B での稟議・支払条件・再請求が絡むと、Invoice や Billing の方が自然なことが多く、「誰がいつ何に同意したか」 の証跡設計が重要になります。
Payment Links / Checkout / Invoicing の境界
| 手段 | 向いているケース | 先に知っておくこと |
|---|---|---|
| Payment Links | 商品数が少なく、まず売りたい | サーバーなしで始めやすいが、動的カートや複雑な顧客紐付けは弱い |
| Checkout | 価格や顧客情報をサーバーで組み立てたい | Checkout Sessions API を使うと税・割引・配送も扱いやすい |
| Invoicing | B2B 請求、支払条件、PDF、督促が重要 | 決済画面というより請求業務の設計が中心になる |
このテーマで判断すべき軸
- 販売チャネル（個人向け一括販売か、法人の請求書払いか）
- 税 の責任分界（自動計算か、税理士確認か）→ Stripe Tax
- カスタマイズ（ブランド、文言、追加フォーム）の要否
- Webhook での取り込み（決済完了を自社の契約・ライセンスと同期するか）
実装の基本フロー
- まずは Link 生成→共有→支払いという最短導線を決める
- 成功通知は Webhook を正にし、内部の「契約ステータス」を更新する
- 請求書が絡むなら、承認メール・PDF・入金確認のどこをソースオブトゥルースにするか決める
- 税コード・顧客所在地の入力品質を上げないと、自動税もブレる
失敗しやすい点
- Link を社内にばらまき、どのキャンペーン由来か がトラッキングできなくなる
- 請求書の「未払い」とサービス提供の開始条件が曖昧で、CS と実装が食い違う
- Customer を作らずに運用し、後からサブスクやポータルに移行しづらくなる
- Payment Links で動的カートや細かな顧客制御までやろうとして、結局 Checkout Sessions API を作り直す
運用で見る指標
- Link 別のコンバージョンと離脱理由（アンケートやログ）
- 請求書の平均回収日数と督促回数
- 税設定変更時の差分（返金・再計算の発生）
次に読む記事
用語: Payment Links、Invoice、Stripe Tax。全体索引は 用語集一覧 です。
よくある質問
Payment Links はサブスクにも使えますか？
用途によっては向きますが、プラン変更や顧客セルフサービスまで含めるなら Billing 側の設計を先に固める方が安全なことが多いです。
税計算は Stripe に任せきりでよいですか？
Stripe Tax は強力ですが、業種・国・特例によっては専門家の確認が必要です。設定値と例外ルールを社内で持てるようにしてください。