2025年7月02日·2 分
ウェブサイトにオンライン決済を追加する：Stripe と PayPal
ウェブサイトにオンライン決済を導入する基本と、Stripe と PayPal がセットアップ、チェックアウト体験、手数料、利用ケースでどう異なるかを分かりやすく解説します。
ウェブサイトにオンライン決済を導入する基本と、Stripe と PayPal がセットアップ、チェックアウト体験、手数料、利用ケースでどう異なるかを分かりやすく解説します。
「ウェブサイトに『オンライン決済を追加したい』」と言うとき、多くの場合はいくつかの構成要素から成る小さなシステムを指します。これらを理解すると、専門用語に迷わず Stripe と PayPal を比較できます。
実務ではプロバイダがこれらの役割を組み合わせていることが多く、実際に「設定する」ことは主にアカウント、チェックアウト方式、そしてサイトとプロバイダの接続方法を決める作業です。
ほとんどのサイトはクレジット／デビットカードから始めます。国やプロバイダの設定によっては次も追加できます：
どの組み合わせが使えるかは、販売する地域、顧客の居場所、アカウントでサポートされる機能に依存します。
典型的なカード支払いは次の流れをたどります：
要点：単に「ボタンを置く」以上の作業です。顧客の支払い方法、承認の流れ、資金の流れ、そしてチェックアウト体験にどれだけのコントロールが欲しいかを選ぶ必要があります。
Stripe と PayPal を比較する前に、あなたのサイトが不格好な回避策を使わずに支払いを受けられる準備ができているか確認しましょう。この“事前確認”は、間違ったチェックアウト方式を選んだり、後で商品の性質や価格設定が購入フローに合わないことに気づく事態を避けます。
異なる支払いセットアップは異なるビジネスタイプに向きます。自分がどのバケットに入るかを明確にしてください：
なぜ重要か：サブスクリプションツール、出金機能、紛争処理はモデルによって大きく異なります—両者が「カードを受け取れる」だけでも、必要な機能は違うことが多いです。
2つの数字を書き出してください：平均注文額（AOV）と主要な顧客国。
近いうちに海外販売をする予定があるなら、後でチェックアウトを全面的に作り直す必要がないアプローチを選んでください。
オンサイトでシームレスなチェックアウトがどれほど重要かを決めてください。
この選択はコンバージョン、ブランディング、信頼に影響します。ある顧客層はウォレット型（例：PayPal）を好み、別の層は標準的なカードフォームを期待することがあります。
スピードとカスタマイズのトレードオフに正直になってください：
実用的なヒント：更新を誰が担当するか（あなた、開発者、サイトビルダー／プラグイン）を決めておくと、長期的な保守の容易さが変わります。
これら4点をそれぞれ一文で答えられれば、推測なしで Stripe と PayPal を比較する準備が整います。
Stripe と PayPal はどちらもオンライン決済を受けられますが、日常的な使い勝手は異なります。Stripe はサイトに溶け込む柔軟なプラットフォーム、PayPal は顧客にとって馴染みのあるウォレットブランド、という感覚です。
Stripe は、チェックアウトを細かくカスタマイズしたい、今後の成長の余地を残したいビジネスに人気です。ブランドに合わせた支払い体験、複数の支払い方法、サブスクリプションや請求書・レポーティングなど他ツールとの連携を想定する場合に強みを発揮します。
PayPal は立ち上げの速さとウォレットベースのチェックアウトで知られ、多くの購入者が PayPal 残高や連携カードで再入力なしに支払えます。PayPal ボタン自体が認知性と信頼感を高め、特定の顧客層ではコンバージョン向上につながることがあります。
実務では、Stripe は「自社のチェックアウト」、PayPal は「顧客が選べる馴染みある選択肢」として機能することが多いです。
多くのサイトはカードは Stripe、そして PayPal は追加のボタンとして提供します。これによりチェックアウトの摩擦を減らし、一つに絞らないことで異なる年齢層や国際的な支払い習慣に対応できます。
Stripe や PayPal の設定は単なる「アカウント作成」ではありません。金融サービス関係の関係を開き、誰が何を売っているか、どこに支払いを出すかを確認するために詳細を求められます。
アカウント作成は速いですが、確認作業で時間がかかることが多いです。基本的な事業情報（法的名、住所、税情報）や出金先の銀行口座を準備してください。
Stripe ダッシュボードでよく使うのは：
確認では所有者の本人確認や、一部事業では追加書類を求められることがあります。
PayPal は通常 PayPal Business アカウントで始めます。制限を解除してスムーズに処理するには次を確認してください：
PayPal は紛争処理と売り手保護のルールを重視するため、サインアップ後にアカウント制限や通知を確認する時間を取りましょう。
多くの事業は初回の支払いを同日中に受けられます—特に PayPal は早いです。Stripe も速いことが多いですが、初回入金までの時間は事業の種類、国、取引量、提出した確認書類の速さにより変動します。
よくある遅延要因は、入力情報と書類の不一致、銀行口座の確認の問題、身分証明書の不足、販売が制限される商品カテゴリです。書類を先に揃え、名前／住所を正確に入力することで数日分の往復を節約できます。
チェックアウトは訪問者が支払うかどうかを決める場所です。Stripe と PayPal はどちらも「カードが受け取れる」状態にできますが、支払いをどのように提示し、どこで決済が行われるかは信頼性、速度、コンバージョンに大きく影響します—特にモバイルで。
ホスト型チェックアウトは顧客を Stripe や PayPal が管理する支払いページに送ります（ブランド化されたページあるいはポップアップ）。通常はセットアップが早く、保守も少なめです。
埋め込み／オンサイトは顧客が自サイト上で決済情報を入力します。よりシームレスに感じられますが、実装作業が増え、検証、エラー処理、アップデートなど自分で管理する項目が増えます。
簡単に言うと：
Stripe Checkout は Stripe のホスト型チェックアウトページです。ロゴやカラーである程度スタイル調整でき、住所の自動補完や保存された支払い方法などモバイルでの利便性を備えています。モダンなチェックアウトを素早く導入したいときの一般的な選択です。
Stripe Payment Links は共有可能な URL でホスト型チェックアウトを開きます。単一商品やサービス、請求書、SNS 経由での販売など、フルのカートフローを構築したくないシンプルな販売に便利です。
PayPal Smart Buttons は商品ページやカートページに表示され、顧客は PayPal アカウント（場合によってはカードも）で支払えます。認知性が高く、購入者の信頼を得やすいのが利点です。
PayPal Checkout は PayPal ブランドのフローで、顧客が PayPal で認証して支払いを確定します。カード情報の入力が不要になり、入力の手間を減らせます。
モバイルでは小さな摩擦が大きな離脱につながります。迅速で読みやすく、余分なアカウント作成を強いないチェックアウトは通常コンバージョンが高くなります。
注目点：
不確かな場合はまずホスト型（Stripe Checkout または PayPal Checkout）で素早くローンチし、顧客の挙動が分かってからオンサイト化するのが安全です。
もしサイト、チェックアウト、バックエンドの配送処理を同時に構築するなら、Koder.ai のようなビルド支援プラットフォームで開発速度を上げるのも一案です。チャットでフローを記述して、React フロントエンドと Go + PostgreSQL のバックエンドを生成し、Webhook、注文ステート、確認メールを手戻りなく反復できます。
手数料は支払いを開始した後の最大の“驚き”要素になりがちです。隠されているからではなく、実際のコストは顧客の支払い行動によって変わるためです。
Stripe と PayPal を比較するときは同じカテゴリを並べて比較してください：
即時出金、先進的な不正対策、マイクロペイメント用の価格などの“追加コスト”にも注意してください。
料金は国、カードの種類（デビット／クレジット、特典付きカード）、支払い手段（カード／ウォレット／銀行振替）で変わります。米国内のデビット中心の店舗と、国際販売かつ高額注文を扱う事業とでは実効コストが大きく異なります。
平均注文額（AOV）と支払いのミックスを使って試算します。\n 例：AOV が $50、プロバイダの料金が 2.9% + $0.30 の場合、取引あたりの基準コストは：
さらに現実を反映させる：注文の 20% が国際で +1% かかるなら、平均で $0.10 を追加（20% × $50 × 1%）。返金やチャージバック、通貨変換も同様に見積もってください。
オンラインで支払いを受けるということはカードデータを安全に扱う責任が発生します—たとえあなたがカード番号を直接見ない設定にしていても。良いニュースは、Stripe と PayPal は特にホスト型チェックアウトを使うとその重荷を大きく肩代わりしてくれることです。
PCI DSS はカードネットワークが定めたセキュリティルールのセットです。要は「カード情報を安全でない方法で保存・公開していないことを証明する」ための要件群です。あなたの義務はカード情報をどう収集するかで変わります。
顧客が Stripe Checkout や PayPal Checkout（それらがホスト）上でカード情報を入力する場合、機密カードデータはプロバイダのシステムで処理されます。これによりあなた側の PCI 範囲はしばしば簡素な自己評価に縮小されます（カード番号を保存しておらず、セキュアな運用をしていることの確認など）。
サイト上にカスタムのカードフォームを作ると、コンプライアンス負担は増えます。なぜなら支払いフローの多くがあなたのサーバやページに触れるためです。
両プロバイダとも不正を防ぎ、失敗支払いを減らすツールを提供しています：
ホスト型でも次はあなたの責任です：
返金と紛争は決済運用の一部です。何が普通で、何に費用がかかり、どのように防げるかを理解しておくと手間とコストを減らせます。
全額返金は購入金額全額を戻すこと、部分返金は一部だけ返すこと（返品や価格調整、割引の代わりに使う）。\n\n一般的なタイムライン：ダッシュボードから即時に返金を発行できても、顧客の銀行が反映するまで 通常5～10営業日 かかることがあります。
重要な点：プロセッサによっては返金時に元の処理手数料を返さない場合があります。見積もりを作るときは「返金が発生すること」を織り込んでください。
チャージバックは顧客がカード発行会社に請求の取り消しを求めることです。一般的な原因：
チャージバックに対抗するには通常次のような証拠が必要になります：
Stripe と PayPal はどちらも紛争ワークフローを提供しますが、使い勝手は異なります。比較時に見るべき点：
PayPal ウォレットが多い顧客層だと PayPal の Resolution Center を使う場面が増えることがあります。カード決済（多くは Stripe 経由）だとカードネットワークのルールに従うケースが一般的です。
/support ページ）\n- サブスクリプションでは更新通知や解約のしやすさを提供する適切に対応すれば、返金は単なる顧客対応です。紛争はコストと時間がかかるので、予防が最も効果的な対策です。
定期課金は単なる「サイトにボタンを置く」以上の仕組みになります。更新、プラン変更、失敗支払いの再試行、顧客の期待管理を含むシステムが必要です。
Stripe Subscriptions は Products と Prices（プラン） を中心に設計されています。月額・年額の請求、従量課金の追加、請求書や領収書の自動送付/ホスティングを設定できます。
重要な概念は 按分（proration） です：サイクル途中でアップグレードがあった場合、差額を自動請求／クレジットする機能があり、階層型会員や SaaS のアップグレードに便利です。
Stripe はまた、カード失敗時のリトライ、ダニングメール、税設定、カスタマーセルフサービス用のポータルなど、定期課金に必要な基本機能を備えています。
PayPal はサブスクリプション機能とボタンベースの定期請求をサポートします。PayPal 残高から支払う顧客が多い場合に適しています。
ただし地域やアカウント種別で挙動が異なることがあるため、プラン変更の扱い、按分のサポート状況、顧客の更新／解約フローが期待通りかを事前に確認してください。
無料トライアル、クーポン／割引、請求書発行（特に B2B 向け）などの要件がある場合は早めに整理してください。ダウンロード可能な VAT／税欄付き請求書や発注番号、銀行振込での手動請求などを求める企業もあります。
複数の階層、頻繁なアップグレード／ダウングレード、請求書や按分を細かく制御したいなら Stripe の方が滑らかなことが多いです。顧客が PayPal を強く好み、プランが単純であれば PayPal の定期課金で足りることもあります—ただし端のケースは事前に検証してください。
海外販売では実務的に重要なのは次の三点：顧客がどの通貨で支払えるか、あなたが何通貨で受け取るか（決済通貨）、資金が銀行に着金する速さです。
両者とも広範な通貨をサポートしますが、驚かれるのは**決済（settlement）**の仕組みです。
Stripe では多くの通貨で価格表示でき、事業所在地に応じて一つ（または複数）の銀行通貨に決済されます。決済通貨と異なる通貨で課金すると、Stripe が変換し変換手数料がかかります。
PayPal は顧客が多通貨で支払いでき、PayPal 残高として複数通貨を保持することがあります。出金時や取引完了時に PayPal が変換を行う場合があります。
実用的なコツ：主要通貨を1～2つに絞り、その他は余裕があれば対応する方針が管理しやすいです。
Stripe の出金は通常スケジュールに従って自動で（多くは日次／週次）、国やリスク履歴により遅延が変わります。資金は直接リンクした銀行口座に送られます。
PayPal は残高にすぐ反映されるため「見た目上は早い」印象を受けますが、銀行へ引き出す際の標準振込はさらに時間がかかることがあります（即時出金は手数料がかかる場合があります）。
「今すぐ見えるお金（PayPal 残高）」と「予測可能に銀行へ振り込まれる（Stripe のスケジュール）」のどちらを重視するかで選択が変わります。
どちらのツールも税務処理を完全に代替するわけではありません。会計士と調整して：
ローンチ前に会計の仕組みを決めておくと後が楽です：
最初の確定申告や紛争対応時に少しの準備が大きな時間節約になります。
最適解はブランド名よりも、チェックアウトの望ましい体験、販売物、必要なコントロール量によります。以下は判断を簡単にする一般的なシナリオです。
成長やカスタマイズ性を重視するなら Stripe：
顧客が PayPal を好む、またはすぐに導入したいなら PayPal：
可能なら Stripe（カード・ウォレット）＋ PayPal の併用はコンバージョン改善に寄与します。顧客が慣れた方法を選べることで離脱が減るからです。
見出し上の手数料だけで決めるのは危険です。実際のコストはカード種別、国、返金、チャージバック、通貨変換で変わります。表面的に最安に見える選択が現実には高くつくことがあります。
また見逃しがちなのは「使い勝手のコスト」です：不格好なチェックアウトはコンバージョンを下げ、限定的なサブスクリプションツールは手動作業を増やします。不安なら今日のニーズに合う選択をまず行い、6か月後にブロッキングされないものを選んでください。
「カードを受け付けます」と告知する前に、素早く確認できる項目を一通りチェックしましょう。小さなミス（欠けた webhook、分かりにくいエラーメッセージ、送られないメール）で導入は失敗します。
Stripe と PayPal はテスト環境（sandbox / test mode）を提供します。実際にお金を動かさずに次を確認してください：
Webhook を使う場合（Stripe Checkout や多くの PayPal 統合で一般的）、イベントが確実に受信・処理されるかをテストしてください。ここで多くの導入が静かに壊れます。
ライブモードに切り替えたら、エンドツーエンドで再確認を：
問題箇所を見つけるために基本的な計測を設定しましょう：
セットアップ（アカウント情報、鍵、webhook、返金手順）をドキュメント化しておき、将来の変更で支払いが壊れないようにします。ローンチから30日後に見直しを行い、手数料、コンバージョン率、チェックアウトの摩擦を確認して価格や UX を調整しましょう。
ローンチ後に反復を速く回したければ、支払いフローをバージョン管理・ロールバックしやすく作るのが有効です。例えば Koder.ai はスナップショットやロールバック、ソースコードのエクスポートをサポートしており、チェックアウト UX や webhook 処理、サブスクリプションロジックを安全に調整できます。
一般に次の3つを整えます。
単に「ボタンを置く」以上に、顧客の支払い方法、承認の流れ、および資金があなたの銀行口座に届く方法を決める作業です。
ざっくり言うと：
現代の多くのプロバイダはプロセッサとゲートウェイをまとめて提供するため、実務上はどの「チェックアウト体験」を提供するかが重要になります。
Stripe は一般的にカード処理＋ゲートウェイの役割を果たし、ホスト型や埋め込みなど柔軟なチェックアウトを提供します。
PayPal は**ウォレット支払い（PayPal ボタン／フロー）**としてよく知られており、地域やプロダクトによってはカード処理もサポートします。
実際には、Stripe は「自社のチェックアウト」のように感じられ、PayPal は顧客が選ぶ追加の馴染みある選択肢に見えることが多いです。
まずは次を提供するのが基本です：
最適な組み合わせは、顧客の居場所、利用デバイス（モバイル vs デスクトップ）、およびアカウントで利用可能な機能に依存します。
一般に、すばやく始めるならホスト型チェックアウトがおすすめです。準備や保守の手間が少なく、PCI 範囲も小さくなります。\n\nホスト型が向いているとき：
埋め込み（オンサイト）が向いているとき：
多くの場合は両方用意すると良いです。よくある構成は：
顧客に選択肢を与えることでコンバージョンが上がることが多く、特に国際顧客や年齢層が混在する場合に有効です。
両プロバイダとも一般に次を求めます：
遅延の主な原因は、名前／住所の不一致、書類不足、または販売が制限されているカテゴリです。書類を揃え、情報を正確に入力するとやり取りの時間を短縮できます。
見出しのレートだけで判断せず、次を比較してください：
実践的には、AOV（平均注文額）と国内外の比率を使って試算するのが現実的です。
顧客がホスト型の Stripe Checkout や PayPal Checkout 上でカード情報を入力する場合、機密カードデータはそれらのシステム上で処理されるため、あなた側の PCI 負担は小さくなります。\n\nただし、次はあなたの責任です：
また、3D セキュアやプロバイダの不正検知ツールの有効化も検討してください。
返金はダッシュボードから簡単に行えますが、顧客側の銀行で反映されるまで通常5～10営業日程度かかることがあります。\n\nチャージバックは手間がかかり、次の証拠が必要になります：
紛争を減らす簡単な対策：請求名を分かりやすくする、購入時に返品／配送条件を示す、確認メールで追跡情報を送る、サポート窓口を明確にする（例：/support）。
どちらを選ぶかは、スピードとカスタマイズ性のトレードオフです。