「カード情報を自社サーバーに保存するなら、PCI DSSという国際基準に準拠していただく必要があります。費用は最低でも数百万円、期間は半年から一年はみておいてください」
自社ECサイトにクレジットカード決済機能を独自で実装しようと開発会社に相談したある製造業の担当者は、そう告げられて言葉を失ったという。見積もりの段階では決済機能の追加は「よくある機能追加のひとつ」程度に見積もっていた。ところが実際に動き出してみると、要件定義の途中で突然、聞き慣れない基準の名前とともに計画が振り出しに戻ってしまう。予算は数十万円のつもりが数百万円に膨れ上がり、リリース予定は半年先送りになった。
これは特別な話ではない。自社の受発注システムやサービスサイトに決済機能を足そうとした担当者の多くが、同じ壁にぶつかっている。決済という機能は、顧客の利便性を大きく引き上げる一方で、情報システムの世界でもっとも重い責任を背負う領域のひとつだからだ。
この記事では、なぜPCI DSSという基準がそれほど重いのか、そしてその重さを現実的に引き受けずに済ませる方法があるのかを、非エンジニアの経営者・システム担当者にもわかる言葉で解説する。最終的には、自社で決済機能を作り込むべきか、外部サービスに任せるべきかを判断するための軸まで踏み込みたい。決済に挑もうとしているあなたの努力は、正しい情報さえあれば、もっと軽い足取りで前に進められる。
PCI DSSとは何か、なぜこれほど重い基準なのか
PCI DSS(Payment Card Industry Data Security Standard)とは、Visa、Mastercard、JCB、American Express、Discoverという世界の主要国際ブランドが共同で策定した、クレジットカード情報を扱う事業者向けのセキュリティ基準だ。カード情報を「保存」「処理」「伝送」するすべての事業者が対象になる。つまり、法律ではなく業界標準でありながら、実質的にはクレジットカード決済に関わるなら避けて通れないルールになっている。
要求事項は12項目、細目まで含めると数百項目に及ぶ。ネットワークのファイアウォール構成、カード会員データの暗号化、アクセス権限の厳格な管理、定期的な脆弱性診断、ログの監視体制、そして年に一度以上の外部監査。これを自社のサーバーでカード情報を保持したまま満たそうとすると、専任のセキュリティ担当者、外部監査機関との契約、継続的なペネトレーションテストの費用がすべて必要になる。中小企業が単発のシステム改修の一環として抱えるには、あまりに重い。
なぜここまで厳格なのか。それはクレジットカード情報漏洩が起きたときの被害が、他の情報漏洩とは桁違いだからだ。カード番号、有効期限、セキュリティコードが流出すれば、被害者は不正利用の恐怖に直面し、カード会社は再発行コストを負い、漏洩元の企業は損害賠償、行政への報告、取引停止、そして何より顧客からの信頼喪失という形で長期にわたる代償を払うことになる。実際に日本国内でも、中小規模のECサイトからのカード情報流出が毎年のように報告されており、その多くは「まさか自社が狙われるとは思っていなかった」事業者だ。決済機能を持つということは、それだけの重い責任を引き受けるということでもある。
「カード情報の非保持化」という現実的な解決策
ここで多くの中小企業を救っているのが、「非保持化」という考え方だ。日本のクレジットカード業界では、経済産業省の指導のもと「実行計画」という形でこの方針が強く推奨されてきた経緯がある。
非保持化とは、自社のサーバーやシステムに一切カード情報を「保存」「処理」「通過」させない設計にすることを指す。もう少し具体的に言えば、決済画面自体を外部の決済事業者のシステム上で完結させ、自社のサーバーはカード番号そのものに触れないようにする。顧客がカード番号を入力する画面が、見た目は自社サイトの一部に見えても、実際の通信は決済代行会社のサーバーと直接やり取りされ、自社のシステムには「決済が成功したかどうか」という結果だけが届く、という仕組みだ。
この設計にすれば、PCI DSSの準拠義務そのものがなくなるわけではないが、求められる要件が劇的に軽くなる。カード情報を保持する事業者向けの厳格な要件ではなく、非保持事業者向けの簡易な自己問診票(SAQ)で済むケースがほとんどになる。専任のセキュリティ担当者を新たに雇う必要もなく、年間数百万円規模だった監査費用が、大幅に圧縮される。
つまり、決済機能を持つこと自体は避けられなくても、カード情報という「一番重い荷物」を自社で背負わない選択肢は十分にある。この一手を知っているかどうかで、担当者が背負うプレッシャーはまったく変わってくる。
決済代行サービス・決済リンク型を使うという選択肢
非保持化を実現する具体的な手段として広く使われているのが、決済代行サービスだ。国内であればGMOペイメントゲートウェイ、SBペイメントサービス、後払い・請求書決済ならNP後払いやPaidなど、業種や取引規模に応じて選択肢は幅広い。海外事業者ではStripeも国内の中小企業で急速に採用が進んでいる。
これらのサービスを使う場合、大きく分けて二つの実装パターンがある。
- 決済リンク型:自社システムから注文情報だけを決済代行会社に渡し、顧客には決済専用のページや請求書リンクへ遷移してもらう。開発の手間が最も少なく、カード情報には一切触れない。
- トークン型・iframe埋め込み型:見た目は自社サイトの決済画面のまま、実際の入力フィールドだけを決済代行会社が提供する部品に置き換える。ブランドの統一感を保ちながら非保持化を実現できる。
どちらを選んでも、自社に残る作業は「注文データを渡す」「決済結果を受け取って自社の受発注システムに反映する」という部分だけになる。カード情報の保管、暗号化、不正利用の監視、国際ブランドとの契約管理といった重い部分はすべて決済代行会社に委ねられる。
一方で、委ねられない部分もある。決済代行サービスの手数料は取引額の3パーセント前後が一般的で、取引量が大きくなるほど固定費として重くのしかかる。また、決済画面のデザインの自由度や、自社独自の分割払い条件、複数の決済手段をまたいだポイント連携といった凝った要件は、決済代行会社の標準機能の範囲を超えると実現が難しくなる場合がある。何を手放し、何が自社の裁量に残るのかを、発注前に正確に把握しておく必要がある。
自社で作り込むべきか、外部に任せるべきかの判断軸
ここまで読むと、「非保持化した外部サービス一択」に思えるかもしれない。実際、大半の中小企業にとってはその通りだ。ただし、判断を誤らないために、次の三つの軸で自社の状況を確かめてほしい。
取引金額と取引件数の規模
月間の決済取引額が数千万円を超え、決済代行会社への手数料そのものが経営を圧迫する規模になっているなら、自社で決済インフラを持つコストと比較検討する価値が出てくる。逆に、月商が数百万円から数千万円程度の中小企業であれば、手数料を払ってでも非保持化の外部サービスに任せた方が、総コストでも安全性でも上回ることがほとんどだ。
独自の決済フローが事業の核心かどうか
サブスクリプションの複雑な従量課金、複数店舗をまたいだポイント精算、独自の与信審査ロジックなど、決済フローそのものが競争優位の源泉になっている事業もある。この場合は決済代行会社の標準機能では対応しきれず、自社開発やより柔軟なAPI型のサービスとの組み合わせが必要になる。一方、「クレジットカードで支払える」というだけであれば、独自性を追求する意味は薄い。決済は差別化のポイントではなく、顧客が離脱しないための最低限の要件だと割り切った方が良い場合がほとんどだ。
社内にセキュリティ体制があるかどうか
情報システム部門に専任の担当者がいて、脆弱性診断や監査対応を継続的に回せる体制がすでにあるなら、自社でカード情報を扱う選択肢も現実味を帯びる。しかし、システム担当が一人か兼任で、日々の運用だけで手一杯という会社が、新たにPCI DSSの完全準拠を維持し続けるのは、現実的ではない。むしろその体制を非保持化とセットで外部に委ね、社内のリソースは顧客対応やサービスの磨き込みに使う方が、事業全体としては前に進む。
この三つの軸に照らして、多くの中小企業は「非保持化した決済代行サービスの利用」という答えにたどり着く。それは妥協ではなく、限られたリソースを最も価値のあるところに振り向けるための、まっとうな経営判断だ。
発注時に確認すべきポイント
決済代行サービスを使う方針が決まったら、開発会社やベンダーに発注する際、次の点を必ず確認してほしい。
- 自社のシステムがカード情報を一切保持・処理・通過しない設計になっているか、図で説明してもらう。
- 採用する決済代行サービスが、自社の非保持化を前提としたSAQ(自己問診票)のどの区分に該当するのか、明確な回答が得られるか。
- 決済結果の通知(コールバック)が失敗した場合のリトライ設計や、二重決済を防ぐ仕組みが組み込まれているか。
- 返金・キャンセル処理のフローと、それに伴う手数料の扱いが契約上どうなっているか。
- 決済代行会社が万が一サービス終了・障害を起こした場合の切り替えのしやすさ(特定のベンダーに強く依存しすぎていないか)。
- 月間取引額が伸びた場合の手数料率の見直し交渉余地があるか。
これらを曖昧にしたまま契約すると、リリース後にトラブルが起きたときに「誰の責任範囲か」が定まらず、対応が後手に回る。発注段階で言葉にして確認しておくことが、後の安心につながる。
よくある失敗パターン
実際の現場でよく見かける失敗も共有しておきたい。
ひとつは、要件定義の初期段階で決済機能の重さを見積もりに織り込まず、開発の後半になってPCI DSSの話が浮上し、スケジュールと予算が総崩れになるケース。冒頭の製造業の担当者もこのパターンだった。決済機能は企画の最初の段階で、非保持化を前提にするかどうかをまず決めてから設計を進めるべきだ。
もうひとつは、決済画面のデザインにこだわりすぎて、iframe埋め込み型では実現できない独自レイアウトを要求し、結果的にコストが跳ね上がるケース。決済画面はブランド体験の一部ではあるが、最優先すべきは安全性と信頼感であり、凝ったデザインではない。シンプルで見慣れた決済画面の方が、かえって顧客の安心感につながることも多い。
そして最も見過ごされがちなのが、決済代行会社を選ぶ際に手数料の安さだけで比較し、サポート体制や障害時の対応速度を確認しないケース。決済は一度止まると売上に直結する。日々の運用でどれだけ迅速に相談に乗ってもらえるかは、契約前に必ず確かめておきたい。
まとめ
業務システムに決済機能を持たせようとするとき、多くの担当者が最初にぶつかる壁はPCI DSSという重い基準だ。しかし、カード情報を自社で保持しない「非保持化」という設計を選べば、その重さは大幅に軽くなる。決済代行サービスや決済リンク型の仕組みを活用すれば、カード情報という一番重い荷物は専門の事業者に委ね、自社は顧客に価値を届けることに集中できる。
判断に迷ったときは、取引規模、独自フローの必要性、社内のセキュリティ体制という三つの軸に立ち返ってほしい。多くの中小企業にとって、答えはすでに用意されている。決済という重責を正しく手放すことは、逃げではなく、限られた時間とリソースを本当に注ぐべき場所に振り向けるための、賢明な一歩だ。壁を越えて顧客のために動こうとする担当者の努力は、正しい設計判断によって、もっと軽やかに前へ進めるはずだ。