Webサイトのお助け隊

WordPressのサイトでカードの支払いを受けたい、という相談は、実装そのものより前後で詰まります。プラグインを入れれば決済画面は出ますが、完了後にどこへ飛ばすか、どんなメールを送るか、金額を後から変えられるようにするか。この3つを詰めないまま進めると、動いてはいるのに運用に乗らない状態になります。そして最も怖いのは、テスト用のキーのまま公開してしまう事故です。実際に、本番への切り替え漏れで入金の事故が起きた現場を見ています。順番としては、入れ方を決める前に、テストと本番をどう分けるかを先に決めてください。

入れ方は3つ

意外に思われるのですが、2番目が現実的な落としどころになる場面はかなり多いです。フォームプラグインで決済ページを組み、金額の設定はそのプラグインのフォームビルダー上で完結させた案件があります。「管理画面から金額を変更できるようにしたい」という要件に対して、独自の管理画面を作るのではなく、既製プラグインの設定画面をそのまま金額設定機能として引き渡しました。作る量が減るだけでなく、公式のドキュメントが使えるぶん、後から触る人にとっても情報が多いという利点があります。

この案件は6日で終わっています。短かった理由は実装が簡単だったからではなく、事前に要件を確定させていたからです。決済まわりの案件が長引くときの原因は、ほぼ実装ではなく要件の未確定にあります。何をいくらで、誰に対して、決済後にどうするのか。この4つが決まっていれば、実装は驚くほど早く終わります。

キーの扱いで事故が起きる

Stripeにはテストモードと本番モードがあり、それぞれに公開可能キーとシークレットキーがあります。開発中はテスト用のキーで進め、公開の直前に本番用へ差し替える——この差し替えが漏れると、決済が成立しているように見えて実際には入金されない、あるいは意図しない側で処理が走ります。実際にこの切り替え漏れによる入金の事故が起きた現場があり、原因は実装の不備ではなく、公開手順にチェックが無かったことでした。

対策は単純で、公開前に確認する項目を紙かファイルに固定してしまうことです。キーがテスト用か本番用か、Webhookの宛先が本番のURLになっているか、決済完了後の遷移先が本番のページか、通知メールの宛先が担当者の実アドレスになっているか。この4点を、実装した本人以外が読める形で残してください。決済を実装したルームと、公開作業をする場面が分かれていると、この確認が誰の担当でもなくなります。

もう1つ、キーの在り処に関する実務的な話があります。既に何らかの決済プラグインを導入している現場では、Stripeのキーがそのプラグインの設定画面に保存されていることがよくあります。依頼者にキーを問い合わせる前に管理画面を確認すると、やり取りが1往復減ります。ただし後から「なぜ知っているのか」と聞かれるので、どこで確認したかを先に伝えておいてください。そもそも、既に決済プラグインや決済代行が導入されていること自体を依頼者が把握していない場合もあります。聞き取りだけで環境を判断せず、管理画面を自分の目で見ることです。

自作に倒す判断

決済プラグインが既に入っている現場でも、自作したほうが早いことがあります。ある案件では、決済完了後のメール文面と遷移先を自由に決めたいという要件でした。プラグインの設定範囲で無理に収めようとすると、テンプレートの制約と格闘することになります。結果として、Stripeのライブラリを使ったPHPを別途書いたほうが短時間で終わりました。プラグインが入っているからプラグインで解決する、という発想を一度外すと工数が減る場面があります。

ただし、この判断には条件が付きます。金額をコードに直接書いた実装は、2つ目の価格が出てきた時点で破綻します。実際に、単一金額で自作した決済処理が、価格の追加を依頼された次の案件で行き詰まりました。自作するなら、最初から金額をパラメータとして受け取る形にしておくか、価格や商品が増える見込みがあるなら既製の決済基盤へ寄せてください。総額としてはそのほうが安く付きます。CheckoutとElementsのどちらで組むかという選択についてはStripe Checkoutと自前の決済フォーム、どちらで作るべきかで整理しています。

メールの文面については、コードの中に書かないという工夫が効きます。本文を mail.txt のような別ファイルに切り出しておけば、エンジニアでない担当者でもFTPでファイルを落として文面だけ直せます。文面の修正のたびに開発を依頼する状態を作らないための、費用のかからない対処です。

PHPは固定ページの本文に貼らない

自作の処理を渡すときに、必ず一度は起きるのがこれです。PHPのコードを渡すと、依頼者はそれをWordPressの固定ページの本文に貼り付けます。当然ながら実行されず、コードがそのまま画面に表示されます。PHPのファイルはサーバー上に独立したファイルとして置き、フォームの action からそのURLを呼ぶ——この構造を、最初に図の粒度で説明しておくとやり取りが1往復減ります。

テストで確認するのは3点

決済を通したあとに「メールが届かない」という報告が来たとき、闇雲に実装を疑わないでください。切り分けは3つに分解します。決済完了後のサンキューページが表示されたか、Stripeの管理画面に決済が記録されているか、管理者宛のメールが届いたか。どこまで通っているかが確定すれば、原因がPHP側なのか送信側なのかメールボックス側なのかを一発で絞り込めます。

特に多いのが「自分宛にだけ届かない」というパターンです。送信元と宛先が同じドメイン、あるいは同じアドレスの場合、サーバーの設定によって配送されないことがあります。この症状が出たら、まず別ドメインのアドレスで再テストしてもらってください。それだけで大半は切り分けが終わります。実際にこの現象に当たった案件では、自己送信のブロックかSPFの設定かまでは特定できず、運用で回避する形になりました。同じことを繰り返さないために、mb_send_mail のようなPHPの送信関数を使う実装は、納品の時点で必ず外部ドメイン宛のテストを済ませておいてください。

実装がソースに残らない構成に注意する

フォームプラグインで決済を組んだ場合、実装の実体はプラグインの管理画面上のデータです。テーマにもプラグインのソースにも変更が残らないため、後から「何をどう設定したのか」を追跡できません。フォームの定義をJSONでエクスポートして保管しておくのが唯一の対策です。ローカルにファイルとして何も残らない構成は、担当が替わった瞬間にブラックボックスになります。

納品時には、どこをクリックすれば何が変えられるかを、メニュー名の粒度で書き出して渡してください。ある案件では変更できるメニューを5つ列挙し、画像まで差し替えられる項目についても明記しました。この一手間があるかどうかで、その後の細かい依頼の量が変わります。

手数料と、決済のあとに起きること

決済手数料は決済事業者が定めるもので、実装側で下げられるものではありません。確認しておくべきなのは料率そのものより、返金したときに手数料がどう扱われるか、入金のサイクルがいつか、少額の決済で手数料の比率がどうなるかです。単価の低い商品を大量に売る構成なら、この比率が事業計画に直接効いてきます。導入前に事業者の料金ページで最新の条件を確認してください。

継続課金を扱う場合は、設計の難易度が一段上がります。決済の失敗、カードの有効期限切れ、解約のタイミングをどう扱うかが実装の本体になるためで、単発の決済とは別物として見積もる必要があります。この点はStripeで月額課金を回すときの設計と、解約・失敗の扱い方にまとめました。本人認証への対応が必要な場合の考え方は3Dセキュア対応の決済ゲートウェイを自作したときの設計で扱っています。

よくある質問

プラグインと自作、どちらが安く済みますか

初期費用はプラグインが圧倒的に安く、要件が定型なら比較になりません。自作を検討する価値があるのは、決済完了後の処理を既存の業務フローに組み込む必要がある場合と、メールや遷移先の自由度が要件そのものである場合です。金額や商品の種類が増えていく見込みがあるなら、自作よりも既製の決済基盤に寄せたほうが総額は下がります。

すでに別の決済プラグインが入っています。共存できますか

技術的には可能ですが、まず現状を確認してください。導入済みのプラグインにキーが保存されていることがありますし、そもそも入っていること自体を把握していないケースもあります。共存させると、決済の記録がプラグインごとに分かれて後から集計しづらくなります。片方に寄せられないかを先に検討することをお勧めします。

テスト決済はどこまでやれば安心ですか

テストカードでの成功パターンだけでは足りません。失敗するカード番号での挙動、決済後にブラウザを閉じた場合、二重に送信した場合を通してください。そのうえで、本番のキーに差し替えた後に、実際のカードで最小金額の決済を1件通して返金する、という確認まで行うのが確実です。

公開後に金額を自分たちで変えられますか

その要件は最初に伝えてください。フォームプラグインで組む構成なら、金額はプラグインの管理画面で変更できます。自作の実装でも、金額を設定値として外に出しておけば管理画面から変えられます。逆に、コードに直接書いてしまった後で「変えられるようにしたい」となると、作り直しに近い改修になります。