Stripeを使った決済システム

Date2026/04/24 Last Modified2026/04/24

概要

ECサイトを構築する上で決済システム(決済代行サービス)が必須になる。
システムに至る前に、どういうフローで決済が行われるのかという面から調べていきたい。

Stripeを通じた決済のフロー

そもそも消費者と販売者の間でどうやってお金が移動しているのだろうか。ここから調べていく。

決済方法をクレジットカードと仮定した場合、以下のようなフローになる。

  1. 消費者がECサイトで注文を行う
  2. Stripeがカード情報を受け取り、Stripeがカード会社に認証リクエストを行う
  3. カード会社が承認を返す
  4. Stripeアカウントに売り上げが記録される
  5. Stripeから銀行口座へ振り込まれる

クレジットカードは、カード会社が消費者の支払いを代行することなので、Stripeはカード会社からの振り込みを受ける。
このとき代行手数料が発生し、手数料を除いた額がStripeアカウントに記入される。
Stripeアカウントに記入された売り上げは、システムで自動振り込みもできるし、任意のタイミングで振り込みの設定をすることもできる。

Laravel + Stripeを構築する

まずは実際にアプリの動きを見てみよう。(仕様を理解する前に先にシステムができている時代)

CodexにとりあえずECサイトを作ってもらったので、決済をしてみる。
まずはStripeにアカウントを作成し、テスト用APIキーを取得。システムに登録する。
支払いを行うと、次のような画面へ遷移した。

StripeSandox決済 StripeSandox決済

ここはStripeが持っている画面。
テストの際はテスト用クレジットカード情報を使って決済をする。
テスト用カード番号一覧 テスト用カード番号一覧

決済が成功すると、ECサイトにリダイレクトしていて「決済完了」となっている。
すると、Stripeアカウントに売り上げの記録が！

Stripe画面 Stripe画面

なんだかお金持ちになった気分。実際の売り上げと手数料を引いた分を算出できるという形になっている。
このあとの口座への振り込み設定などは、すべてStripe管理画面で行うためシステムは関与しなくてよい。

それでは、システム側(Laravel)で実装するのはどの部分になるだろうか？

決済フローは色々あるようだが、今回作成した最もシンプルなフローで理解してみる。
まず全体の流れは以下のようになる。

  1. ユーザーがカートに入れて注文を行う
  2. カート情報が正常(空ではない)なら、1件のpending状態の注文を作成してDBに保存する
  3. spriteClientのインスタンスを呼び出し、“success_url"と"cancel_url"を内包したリクエストを送る
  4. sprite側がセッションを作成し、レスポンスとしてCheckout Session IDとCheckout URLを返す
  5. ユーザーはそのCheckout URLにリダイレクトして、指定されたセッションで決済入力を開始する
  6. ユーザーが決済情報を入力し、成功した場合はあらかじめ指定されていた"success_url"に対してリダイレクトさせる。そのとき1件分の決済IDをパラメータで渡す
  7. 再びspriteClientを呼び出して決済セッションidで適合し、そのpayment_status=paidなら決済成功とみなす
  8. 決済成功の場合、DBの注文の状態をcompleteにする

ECサイト側とStripeの処理を混合して並べているが、StripeによってECサイト側は決済について意識することがない。
よってECサイト側のみを実装するだけなら、注文レコードの状態管理とSpriteの成功/失敗だけを管理するだけで良いことになる。

EC側とStripe側をつなぐのは、session_idである。
これは何かというと、ブラウザのセッションとは違って1決済分のフローをセッションとしてまとめたものである。
すなわち注文ごとにStripe側にセッションを作成し、そのセッションURL+IDをユーザーに持たせることによって一意のユーザーとしてサイトを横断させている。

ちなみに気になって調べたのだが、Stripe側がセッションをどうやって保持しているのかは明記されていないらしい。(おそらくDB？)
仮にDBだった場合は、Stripeクライアントでセッションをcreate()したときにStripe側のDBにセッションレコードが追加され、そのレコードのsession_urlがユーザーに渡されるものとなる。ちなみに揮発性なのかもわからないらしい。

まとめ

決済の仕組みについてかなり理解が深まった。
そもそも純粋な疑問として「いろんなサイトにクレジットカード情報を入力しても大丈夫なんだろうか？」と思っていたが、決済代行システムにリダイレクトした場合は、代行システムしか機密情報を持たないので安心だということが分かった。
決済は金銭を扱うので、かなり難しいシステムを組む必要性があると思い込んでいたが、決済の可用性はSprite側が担保してくれるので、代行システムを導入する側のシステムはそこまで完璧な実装を求められていないという点には安心した。返金とかキャンセルとかどうするんだろうと思っていたけれど、“success_urlとcancel_urlだけを意識する"ということなら、こちらは注文の状態だけを管理すればいい。
また他のサービスだと変わってくるのだと思うが、Stripeでの実装なら自信を持って対応したい。

余談ながら、StripeとSpriteを100回くらい打ち間違えた。ややこしい。ってかSpriteの方が身近すぎて手が勝手に入力する……。