Webサイトのお助け隊

決済をサイトに載せたい、ただしカード番号を自分のサーバーで預かるのは避けたい。この2つを同時に満たそうとすると、Stripeの入れ方は実質2択になります。Stripeが用意した決済ページへ飛ばすCheckoutか、自社ページの中にカード入力欄を埋め込む方式か。どちらもカード番号そのものは自社サーバーを通らないのに、後の運用でできること、不具合が出たときに調べる範囲、初期費用が変わります。ハウスクリーニングの作業メニューを持つ個人事業のサイトに決済を組み込んだときの判断と、公開直後に起こした入金先の事故まで含めて書きます。

決済画面をどこに置くか。分岐はここだけです

最初に決めるのは「カード番号をどの画面で入力してもらうか」です。ここで実装も費用も運用も決まってしまうので、デザインの話より先に片付けます。

ひとつめが Stripe Checkout です。自社サイトのボタンを押すとStripeが用意した決済ページへ移動し、そこでカード番号を入力してもらいます。決済が終わると、こちらが指定した完了ページへ戻ってきます。カード番号は自社のサーバーを一度も通過しません。画面の作り込みは、Stripeの管理画面でロゴと色を設定する程度に限られます。

ふたつめが、自社ページの中にカード入力欄を埋め込む方式です。Stripeが配布するJavaScriptがブラウザ上でカード番号をトークンに変換し、自社サーバーへ渡るのは番号ではなくトークンだけになります。見た目は自由で、注文内容とカード入力を1画面にまとめられます。そのかわり、入力エラーの表示、3Dセキュアの画面遷移、決済失敗後の戻し方まで自分で作ることになります。3Dセキュアの挙動をどこまで自前で持つかは、3Dセキュア対応の決済ゲートウェイを自作したときの設計で扱った論点とほぼ同じです。

みっつめとして、自社のフォームで生のカード番号を受け取ってサーバーからAPIへ送る形もありますが、これは候補に入れません。カード番号が自社のプログラムとログを通過した時点で、PCI DSSで求められる自己問診の範囲がいちばん重いものに変わります。リダイレクト型ならSAQ A、埋め込み型ならSAQ A-EPが目安ですが、生の番号を受け取る構成はそれらと比較になりません。売上規模に関係なく外してください。

効く判断軸は、画面の自由度ではありません

相談の場で最初に出てくるのは「自社サイトから離脱させたくない」という話です。気持ちは分かるのですが、実務で後から効いてくるのは別のところでした。

ひとつは金額の決まり方です。商品ページと決済が1対1で対応していて、金額が固定なら、Checkoutは驚くほど早く終わります。逆に「作業内容の組み合わせで金額が変わる」「オプションの数量で加算する」といった要望が入ると、金額を組み立てる処理をどこかに持つ必要が出てきます。フォーム系プラグインの決済機能は、ほとんどが1フォーム＝1商品＝1決済の構造です。この制約を知らずに要件を膨らませると、見積りが一気に跳ね上がります。

もうひとつは誰が金額を変えるのかです。価格改定のたびに制作側へ連絡して修正費用が発生する形にすると、数年単位では決済の実装費より高くつきます。管理画面から金額を編集できる状態にしておくと、そこが丸ごと不要になります。

三つめは調査範囲です。決済が通らないという問い合わせが来たとき、Checkoutなら見るのはStripeのダッシュボードに残った決済ログと、こちらが送ったセッションの中身の2か所です。埋め込み型は、ブラウザのJavaScriptエラー、トークン生成の可否、サーバー側の決済確定処理、3Dセキュアの戻り、と切り分けが増えます。運用を1人で回す事業者にとって、この差は決して小さくありません。

2つの方式を並べると

実際に組み込んだ案件では、要件のほうが重かった

ハウスクリーニングの作業メニューを持つ個人事業のサイトで、申込フォームからそのまま決済まで進める仕組みを作りました。最初の要望は「フォームの入力内容によって決済金額が変わるようにしたい」というものでした。

調べたうえで、その形をフォームプラグインの標準機能で作るのは無理だと最初に伝えています。前述のとおり1フォーム＝1商品＝1決済が基本で、入力値から金額を組み立てる処理を丸ごと自作すると20〜25万円になる、と数字で示しました。そのうえで代案を2つ出しています。決済機能だけを入れる形が59,000円、管理画面から金額を編集できる状態まで含める形が95,000円。選ばれたのは後者でした。

実装はWordPress上のフォームプラグイン（WPForms）とStripe Checkoutの組み合わせです。決済用のページは問い合わせページとは分けて非公開ページにし、申込の流れに乗った人以外は到達しないようにしました。誤って決済ページだけを踏まれる事故を防ぐためです。組み込みの手順そのものはWordPressにStripe決済を組み込む手順と、つまずく箇所で書いた流れと大きくは変わりません。あわせて、決済を扱う以上は必要になるプライバシーポリシーのページも用意しています。

金額の編集は、独自の管理画面を作らず、フォームビルダーの項目編集をそのまま使える形にしました。作業メニューは5つあり、そのうち1つは画像も差し替えられます。どのメニューをクリックすれば何が変わるのかを項目名レベルで書いて渡しています。これで価格改定のたびの発注がなくなりました。

この案件で重かったのは実装ではありません。要件を固める工程に2か月かかり、固まってからの実装は6日で終わっています。決済まわりで納期が延びるときの原因は、たいてい書くコードの量ではなく決めごとの量です。

公開の直前に、必ず見る5つ

この案件では、公開後に事故を起こしています。テスト用に使っていたStripeアカウントの切り替えが漏れたまま本番公開され、実際に発生した10,500円の決済が、依頼主のものではないアカウントに入金されました。決済フォーム自体は正常に動いていたので、動作確認では見つかりません。以来、決済を本番へ出す前に次の5点を毎回確認しています。

1. 接続先のStripeアカウントが、依頼主本人の名義のアカウントか（テスト用に借りた別アカウントのままになっていないか）
2. APIキーが本番用か。シークレットキーが sk_live_ で始まっているか
3. ダッシュボードのテストモードが解除されているか
4. Webhookの送信先が本番のURLを向いているか。テスト環境のURLが残っていないか
5. 少額で実際に決済し、依頼主のダッシュボードに入金が立つことを見てから返金する

5番目を省くと、1番から4番までを目視で確認しても抜けます。画面の設定ではなく、実際にお金が正しい場所へ着いたことだけが確認になります。

どちらで作るかの目安

金額が固定、または数パターンの選択肢で決まる。運用者が数名以下で、価格改定を自分たちでやりたい。こういう条件ならCheckoutで十分です。決済画面がStripe側に切り替わることを嫌がられるケースもありますが、カード情報を入力する画面が決済事業者のドメインであることは、利用者にとってはむしろ安心材料になります。ロゴと色を設定しておけば、唐突に別サイトへ飛ばされた印象にはなりません。

逆に、購入導線の1画面ごとに離脱率を測って改善していく前提があるなら、埋め込み型を選ぶ理由があります。カート内で決済まで完結させたい、定期課金と単発購入を同じ画面で扱いたい、といった要望もこちら側です。ただし、継続課金は「作って終わり」にならない領域で、解約と決済失敗の扱いを最初に決めておかないと運用で必ず詰まります。この点はStripeで月額課金を回すときの設計と、解約・失敗の扱い方にまとめてあります。

迷ったときは、Checkoutで始めて構いません。決済の記録はStripe側に残るので、後から埋め込み型へ作り替えても、過去の取引データが消えるわけではありません。最初から作り込んで公開が半年遅れるより、売れてから直すほうが損失は小さく済みます。どこまでを自作するかの判断は、開発の対応内容のページにも整理しています。

よくある質問

Checkoutだと自社サイトから離れてしまいます。売上に影響しませんか

影響の方向は事業によって変わるため、断定はできません。ただ、離脱の原因が決済画面のドメインだったと特定できた例は手元にありません。それよりも、フォームの入力項目が多い、送信後に何が起きるか書いていない、スマートフォンでボタンが押しにくい、といった手前の作りのほうが効きます。Checkoutにすると入力項目を決済画面に足せないので、必要な情報を手前のフォームで受ける設計になり、結果的に導線が整理されることもあります。

金額を管理画面から変えられるようにすると、費用は上がりますか

上がります。前述の案件では、決済機能だけの構成と比べて36,000円の差がつきました。ただしこれは実装量の差というより、運用の自走性に対する費用です。既製プラグインの管理画面をそのまま金額設定の窓口として引き渡す形であれば、独自の管理画面を作るより安く、操作方法もプラグイン側の公式ドキュメントで調べられます。価格改定が年に何度もある事業なら、初回で入れておくほうが安く済みます。

テスト環境と本番で、決済まわりは何を分ければいいですか

APIキー、Webhookの宛先、そして接続先アカウントの3つです。キーは wp-config.php や環境変数で切り替え、本番のシークレットキーはテスト環境に置かないでください。加えて、テスト環境からの通知メールが実際の顧客へ飛ばないよう、送信先も確認します。テスト用のアカウントを借りて検証した場合は、本番公開のタイミングでアカウントごと切り替える必要があり、ここが最も抜けやすい箇所です。