Stripe決済の導入と手数料【2026年9月時点】3.6%に積み上がる費用と、4つの実装方式の選び方

「Stripeの手数料は3.6%と書いてあるが、結局いくら取られるのか」——決済の導入を検討している方から、こうした質問をよく受けます。料率だけは公開されているのに、通貨換算はどうなるのか、返金したら手数料は戻るのか、入金はいつなのか、サブスクにすると何が乗るのか。肝心な部分が別のページに散らばっていて、合計が出せない。だから決められない、という状態です。

結論から言うと、Stripe導入の判断は「決済手数料3.6%」だけでは決まりません。通貨換算が必要なときの+2%、Stripe Billingを使う場合の0.7%、不審請求の申し立て(チャージバック)1件あたり¥1,500、そして返金しても元の決済手数料は戻らないという扱い。ここまで足して初めて、自社の月商と返品率でいくら消えるかが出ます。加えて日本では日次入金が使えないため、資金繰りの前提も変わります。本記事の数値は、すべて2026年9月15日にStripeの日本向け公式ページとドキュメントで直接確認したものです。

もう1つ、同時に決めなければならないのが導入方式です。Payment Links、Stripe Checkout、Elements、API直実装の4つは、コードの量が違うだけではありません。PCI DSSの自己問診票(SAQ)の区分まで一緒に変わります。料率だけ見て契約し、方式は後から決める——この順番が失敗のもとです。方式が決まらないと、実装にかかる作業量も期間も見積もれません。

本記事では、Stripe導入で決めることの整理、手数料の全体像(決済・通貨換算・返金・チャージバック・入金サイクル・消費税)、導入方式4つの比較とPCI DSS、アカウント作成からサブスクリプション課金までの実作業と期間、自社実装と外注の切り分け、当社に依頼する場合、よくある質問の順に解説します。手数料は1つの表に、方式は3つの軸で比べられる表にまとめました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社自身も、Stripe連携・二要素認証・ウォレット・PDF出力を含む決済アプリを新規で開発し、そのまま週次の保守に入っています。その経験から言えるのは、決済で効いてくるのは初期実装の速さではなく、稼働後に取りこぼしを拾い続けられるかだということです。この記事を読み終えるころには、自社でStripeを採用するか、どの方式で作るか、どこまで自社でやるかが判断できるはずです。

Stripe決済の導入とは何を決めることか——「契約」「決済手段」「実装方式」の3つを同時に決める

「Stripeを導入する」という一言には、実際には3つの意思決定が入っています。決済代行としてStripeと契約すること、顧客に提示する決済手段を選ぶこと、そして自社のサイトやアプリに決済画面をどう実装するかを決めること。この3つは独立しておらず、どれか1つを決めると残り2つの条件が変わります。ここを分けずに検討を始めると、料率の話と実装の話が混ざって結論が出ません。

Stripeを導入するとは、決済代行の契約・使う決済手段・画面の実装方式の3つを決めること

Stripeは2010年に米国で創業したオンライン決済プラットフォームで、日本ではストライプジャパン株式会社がサービスを提供しています。初期費用・月額費用がなく、決済が成立したときだけ手数料が発生する従量課金である点が、導入の敷居を下げてきました。

3つの決定は次のようにつながっています。契約(どの国のアカウントで、どの事業として審査を通すか)が、使える決済手段と入金条件を決めます。決済手段(カードだけか、コンビニや銀行振込も出すか)が、返金の扱いと手数料の合計を決めます。実装方式(ノーコードか、埋め込みか、自前の画面か)が、作業量とPCI DSSの負担を決めます。つまり、料率だけを先に比べても導入の全体像は出ません。

この記事では2番目と3番目を中心に扱います。他社の決済代行との横並び比較は本記事の担当範囲外とし、「Stripeを選んだ場合に何がいくらかかり、どれだけ作業が要るか」に絞ります。

日本の事業者が使える決済手段【2026年9月15日時点】——カード、ウォレット、コンビニ、銀行振込、PayPay

Stripeの日本向け料金ページで確認できる主な決済手段は次のとおりです(2026年9月15日にstripe.com/jpで確認)。

カード以外を出すかどうかは、料率だけでなく「入金までの時間差」と「返金の手間」で決めてください。コンビニ決済と銀行振込は、Stripeがネイティブの返金に対応していないため、返金時に顧客から口座情報を回収する手順が入ります(docs.stripe.com/refunds、2026年9月15日確認)。返品が日常的に発生する商材でこれを見落とすと、カスタマーサポートの負荷が跳ね上がります。

Stripeが向く事業・向かない事業——先に向かない条件から確かめる

向き不向きは、料率よりも「自社の取引の形」で決まります。先に向かない条件から確かめるのが早道です。

向くのは、オンラインで単発販売または継続課金を行い、開発リソースが社内または外部に確保できる事業です。具体的には、自社ECやD2C、SaaSのサブスクリプション課金、デジタルコンテンツ販売、会員制サービス、予約と同時に決済を取るサービスなどが該当します。予約と枠の管理を伴うサービスでは、決済の前に予約枠の設計が効いてきます。この点は「予約システム開発」の記事で扱っています。

向かないのは、対面販売が中心で決済端末の運用が主になる事業、Stripeが取り扱えない業種に該当する事業、そして開発に一切手をかけられずノーコードの範囲でも運用できない事業です。取り扱えない業種は審査で判明するため、導入を決める前にアカウントを作って事業情報を提出し、確認しておくのが安全です。ここを最後に回すと、実装が終わってから使えないことが分かります。

では、その3.6%の上に何が積み上がるのか。手数料の全体像から見ていきます。

Stripeの手数料の全体像——決済3.6%の上に何が積み上がるか【2026年9月15日時点】

Stripeの手数料は「3.6%」という1つの数字で語られがちですが、実際には決済手数料を土台に、通貨換算・オプション機能・不審請求の申し立て(チャージバック)・消費税が層になって乗ります。ここに挙げる数値はすべて、2026年9月15日にStripeの日本向け料金ページとドキュメントで直接確認したものです。料率は予告なく変わるため、契約前に必ず同じページで再確認してください。

手数料の一覧表——決済・通貨換算・オプション・不審請求の申し立て

見落とされやすいのは、これらが「足し算」になる点です。海外顧客にサブスクリプションを売る場合、カード3.6%+通貨換算2%+Billing 0.7%で、決済額の6%超が手数料になる計算になります。国内向けの単発販売なら3.6%だけで済みます。同じ「Stripe導入」でも、取引の形で負担は倍近く変わるのが実情です。

返金とチャージバック——返金しても決済手数料は戻らない

ここが資金計画で最も効く部分です。Stripeのドキュメントには「元の取引で発生した Stripe の処理手数料は返金されません」と明記されています(docs.stripe.com/refunds、2026年9月15日確認)。つまり1万円の商品を売って返金した場合、売上はゼロに戻りますが、決済手数料の360円は戻ってきません。返品率10%の商材なら、返品分の手数料がそのまま粗利から消えます。

一方、決済が完了する前のキャンセルには手数料がかかりません。同ドキュメントは、取引直後に大量の返金が発生する事業について、オーソリとキャプチャーを分けて手動で行い、キャプチャー前にキャンセルするか、キャプチャー額を減らす運用を勧めています。返品前提の商材では、この設計を最初から入れておくかどうかで年間のコストが変わります。

チャージバックは別の負担です。申し立て1件につき¥1,500がかかり、対応の工数も発生します。売上規模が小さいうちは金額として小さく見えますが、申し立て率が高い状態が続くとカードネットワーク側からの是正要求につながるため、金額より率を見てください。

入金サイクル——日本では日次入金が使えない

Stripeのドキュメントには、日本について「日次入金は利用できません。デフォルトのスケジュールは手動であり、週次および月次の入金スケジュールも利用できます」と記載があります(docs.stripe.com/payouts、2026年9月15日確認)。同ページでは、日本の着金タイミングとして初回が7暦日、その後の既定が4営業日(営業日は月曜〜金曜)と示されています。最低入金額は1 JPYです。

この条件を先に押さえておかないと、「売れた分がすぐ入る」前提で仕入れや広告費を組んでしまいます。特に立ち上げ期は、初回入金までの時間差が運転資金に直結します。入金スケジュールの設定はダッシュボードで変更できるため、契約後すぐに自社の資金繰りに合わせて決めてください。

手数料に乗る消費税と、月商別の試算

日本の事業者向けのサポートページには、一部のStripe手数料(Connect、Radar、一部の決済処理手数料など)に現行の標準税率で日本の消費税が適用されるとあり、毎月の適格請求書はダッシュボードの書類セクションに毎月10日までに表示されると記載されています(support.stripe.com、2026年9月15日確認)。対象と適用開始時期はサービスごとに分かれている段階のため、本記事では個別の税率計算までは踏み込みません。仕入税額控除の扱いは、必ず自社の顧問税理士とダッシュボードの書類で確認してください。

そのうえで、国内向けのカード決済のみ(通貨換算なし・Billingなし・消費税分を除く)で試算すると、次のようになります。

手数料を下げる現実的な手は3つです。1つ目は銀行振込の併用。料率1.5%とカードの3.6%は倍以上の差があり、BtoBの高単価取引では効きます。2つ目はサブスクリプションの年額プラン化で、決済回数そのものを減らす方法。3つ目は取扱高が大きくなった段階での料率の相談です。いずれも「実装で下げる」のではなく「取引の形を変えて下げる」手であり、実装方式の選択とは別の話です。

手数料の合計が見えたら、次は同じくらい重要な、導入方式の選択に進みます。

導入方式の選び方——Payment Links / Checkout / Elements / API直実装を3つの軸で比べる

導入方式の選択は、単に「コードを書くか書かないか」ではありません。決済画面の自由度と、実装・保守の作業量と、PCI DSSの自己問診票(SAQ)の区分を、同時に決めてしまいます。ここを後回しにしたまま料率だけで契約すると、監査要件が想定と違って作り直しになります。まず4方式を並べてください。

4方式の比較表——コード量・自由度・PCI DSSのSAQ区分・向く案件

Stripeの公式ドキュメントは、ほとんどの実装で Checkout Sessions API を推奨しています。PaymentIntents を直接使う場合、割引・税計算・通貨換算・サブスクリプションなどを自前で組み立て、維持し続ける必要があるためです(docs.stripe.com/payments/online-payments、2026年9月15日確認)。自由度を取るほど、作るものと壊れるものが増えるという当たり前の関係がここにも出ます。

PCI DSSとカード情報の非保持化——「使えば関係ない」ではなく「実装方式で区分が変わる」

よくある誤解が、「Stripeを使えばPCI DSSは自社に関係ない」というものです。Stripe自身のセキュリティガイドには、PCI準拠は共同責任であり、支払いを受け付ける企業は準拠した方法で受け付け、毎年それを証明する必要があると書かれています(docs.stripe.com/security/guide、2026年9月15日確認)。

区分を分けるのは、カード番号がどこを通るかの一点です。Payment LinksとCheckoutは、カード情報の入力欄がStripeのドメインが提供するiframe内にあるため、カード情報が自社サーバーに触れません。これがSAQ Aです。Elementsも、公式SDKのUIコンポーネントを使う限りカード番号は顧客からStripeへ直接渡り、SAQ Aの扱いになります。一方、自社サイト上のフォームにカード情報を入力させる実装(Stripe.js v2)はSAQ A-EPで、毎年の準拠証明が必要です。サーバー側でカード情報を受けて処理する実装はSAQ Dで、300を超えるセキュリティコントロールと外部監査人の関与が必要になり得ます。

実務上の結論はシンプルです。カード番号を自社のサーバーに通さない実装を選ぶ。これが「カード情報の非保持化」の中身であり、契約書や社内規程ではなく実装方式で決まります。 なお、開発を外部に委託する場合のセキュリティは、PCI DSSの区分だけでは足りません。契約・人・環境・運用・法規制の層で組む必要があり、その全体像は「オフショア開発 セキュリティ」の記事で扱っています。

加えて、決済ページではTLS 1.2以上を使うこと、WebhookのエンドポイントにもTLSを使い署名を検証すること、Content Security Policyを設定している場合はStripeが要求するディレクティブを追加することが、同ガイドに明記されています。当社でも、決済まわりの実装はGitのプルリクエストによるコードレビューを標準化し、リリース前にダブルチェックを入れています。

迷ったときの決め方——3つの質問で方式を絞る

API直実装はこの表に入れていません。カード番号を自社で扱う必然性がある事業は限られており、それ以外では監査負担に見合わないためです。迷っているなら Checkout から始めてください。後からElementsへ寄せることはできますし、逆に「自由度が要らなかった」と分かる案件のほうが多いのが実情です。

導入の実作業と期間——アカウント作成からサブスクリプション課金まで

「Stripeは最短当日で入る」という説明と、「決済の実装に2か月かかった」という話が、どちらも本当です。差を生むのは方式と、決済画面以外の作業量です。ここでは工程ごとに何をやるか、どれくらいかかるかを目安で示します。期間は当社が決済アプリを新規開発した経験と、一般的な体制(エンジニア1〜2名)を前提にした目安であり、既存システムの状態で変動します。

工程別の作業と期間の目安(表)——最短と標準

この表で伝えたいのは、工程4より工程5のほうが重いという点です。決済フォームは公式のドキュメントどおりに作れば動きます。時間を食うのは、決済が終わったあとに自社のデータをどう正しく更新するかのほうです。

アカウント作成と本人確認(KYC)——ここで止まる案件がある

Stripeの公式ドキュメントには、KYC(顧客確認)の義務により全ユーザーから情報を収集・保持する必要があり、利用規約の遵守を確認するための審査を行い、追加情報を求める場合があると記載されています(docs.stripe.com/get-started/account/activate、2026年9月15日確認)。また、本番でサービスを有効にした後は事業の所在国を変更できない、とも明記されています。

実務で気をつける点は3つです。1つ目は、開発を始める前に事業情報を提出しておくこと。取り扱えない業種や、追加資料が必要な事業だと分かるのは審査のタイミングです。2つ目は、顧客のカード明細に出る表記(明細表記)を事業名と結びつけておくこと。ここが分かりにくいと、顧客が決済を認識できず不審請求の申し立てにつながります。3つ目は、法人・個人事業主のどちらで申し込むかを最初に決めること。所在国と同様、後からの整理は手間がかかります。

実装で重いのは決済画面ではなくWebhookと突合

Stripeは決済ライフサイクルの各段階でイベントを送ります。自社側は、決済完了・失敗・返金・サブスクの更新といったイベントを受けて、注文ステータス、会員権限、在庫、会計データを更新します。ここで必要になる作業が、決済画面より確実に多くなります。

具体的には、同じイベントが複数回届いても結果が変わらないようにする冪等化、署名の検証、受信に失敗したときの再試行と手動リカバリ、そしてStripe側の記録と自社DBの突合(照合)です。当社が決済アプリを新規開発し、そのまま週次の保守に入った案件で効いてきたのも、初期実装の速さではなくこの部分でした。決済は作って終わりではありません。Webhookの取りこぼしや、返金・チャージバックの照合を毎週見る体制があるかどうかで、半年後の状態が変わります。

なお、決済まわりのコードは仕様変更の影響を受けやすい領域です。当社では日本人PMが設計レビューを行い、Gitのプルリクエストでコードレビューを標準化し、リリース前にダブルチェックを入れる3点セットで運用しています。決済は1件の取りこぼしが金銭の問題になるため、レビューを省く設計は失敗のもとです。

サブスクリプション課金で増える作業——解約・日割り・失敗時の再試行

サブスクリプションを扱うと、単発決済にはない分岐が増えます。プラン変更時の日割り計算、解約とその予約(期末解約)、無料トライアルからの移行、支払い失敗時の再試行と督促、カードの有効期限切れへの対応、そして請求書・領収書の発行です。

Stripe側では Checkout Sessions API にサブスクリプション作成が組み込まれており、割引・税・住所回収も標準機能として使えます。PaymentIntents を直接使う場合は、これらを個別に実装する必要があります(docs.stripe.com/payments/online-payments、2026年9月15日確認)。加えて、Stripe Billing を使う場合はBilling取引額に対して0.7%が上乗せされます。

判断としては、サブスクを扱うなら Checkout(+必要に応じて Billing)から入るのが素直です。自前で日割りと再試行を組むのは、機能としては作れても、運用に入ってからの問い合わせ対応まで自社で抱えることになります。

ここまでで、必要な作業量が見えてきたはずです。次は、どこまでを自社でやるかの話です。

自社実装と外注の切り分け——どこまで自分でやり、どこから頼むか

決済の実装は、全部を内製しても全部を外注しても続きません。仕様変更と料率改定に追随し続ける機能である以上、判断は自社に残り、手は外に持てる形が現実的です。ここでは切り分けの原則と、外注する場合に見積書で確認する項目を示します。

切り分けの原則——要件と運用は自社、コードと保守は体制で持つ

原則は1行です。「何をいくらで、どういう条件で売るか」は自社が持ち、「どう作り、どう直し続けるか」は体制で持つ。

自社が持つべきものは、商品と価格の設計、税と請求の方針、返金・キャンセルのポリシー、入金スケジュールの設定、そしてStripeアカウントの管理権限です。これらは事業判断であり、外部に決めさせるものではありません。特にアカウントの管理権限と本番のAPIキーは、委託先に渡しきりにしないでください。

外に出してよいのは、決済画面の実装、Webhookの受信と業務処理、テストの整備、稼働後の監視と修正です。ここは専門性と継続性が要る領域で、社内に1人しかいないエンジニアに丸ごと載せると、その人が離れた瞬間に決済が誰も触れないコードになります。

Payment Linksだけで足りる規模なら、外注せず自社で完結できます。相談を受けて「まずPayment Linksで売ってみて、売れてから作りましょう」とお伝えして見送った案件も少なくありません。作らずに済むなら、それが一番安い選択です。

外注する場合に見積書で確認する6項目

このうち2と5が抜けた見積もりが一番多く、そして一番もめます。決済は稼働してから問い合わせが来る機能なので、「作る費用」と「直し続ける費用」を最初から分けて出してもらってください。

決済実装費は全体費用の一部——費用相場と会社選びは別記事へ

ここで押さえておきたいのは、決済の実装費はシステム全体の費用の一部でしかないという点です。ECサイトなら商品管理・カート・配送・基幹連携が、SaaSなら認証・権限・管理画面がその外側にあり、決済はそのうちの1機能です。決済だけの見積もりを取って安いと判断しても、全体の費用構造が見えていなければ意味がありません。ECサイト開発の費用相場全体は「ECサイト開発 費用 外注」の記事に、サブスク型プロダクトの外注範囲の切り方は「SaaS開発 外注」の記事にまとめています。

外注先の選び方そのものも、決済に固有の話ではありません。評価軸の立て方、見積もりの比べ方、面談で聞く質問は「システム開発会社 選び方」の記事で扱っています。本記事では、決済という機能に限った確認項目(上の6項目)だけを示すに留めます。

では、当社に頼む場合はどうなるのか。ここまでの内容を前提に、正直なところを書きます。

当社に依頼する場合——決済アプリの新規開発と週次保守の実績から

当社TALENTBASE VIETNAMは、ベトナム・ホーチミンを拠点に、日本人PMをフロントに置いたラボ型の開発チームを提供しています。決済については、Stripe連携を含むアプリケーションを新規で開発し、そのまま週次の保守に入った実績があります。ここでは、その経験をもとにできることと、向かない相談を並べます。

実績: Stripe連携・二要素認証・ウォレット・PDF出力を新規開発し、週次保守へ

当社が担当した決済アプリでは、Stripeによる決済に加えて、二要素認証、ウォレット機能、PDF出力を実装しました。新規開発を終えたあと、案件はそのまま週次の保守フェーズに移っています。

この案件で学んだことは本記事の中で繰り返し書いたとおりで、決済は稼働後が本番だという一点に尽きます。Webhookの取りこぼし、返金とチャージバックの照合、カード有効期限切れによる継続課金の失敗——これらは仕様どおりに作っても発生し、週次で見ていれば数日で気づき、見ていなければ月次の締めで気づきます。当社が決済案件を単発の請負ではなく継続の体制で受けているのは、この差が事業の数字に直結するためです。

品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準運用としています。他の事例(介護記録SaaS「CareViewer」、金融系マッチング)は「オフショア開発 事例」の記事にまとめています。

体制と費用の目安——日本人PMフロント+2〜3人月で月額約80万円〜

体制は2パターンです。パターンA(推奨)は日本人PM/ブリッジSE+エンジニアの構成で、発注側は優先順位の判断に集中できます。パターンBはエンジニアのみの構成で、社内にPMがいる場合に選べます。

公開している単価は、実務3年目安で1,500USD(約22.5万円、1USD=150円換算目安)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです。2,000名以上のIT人財データベースから直接アサインするため、協力会社や紹介経由の仲介マージンが入りません。最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。

1名から契約でき、最短2週間で開始、増員は約1週間、縮小・交代は1か月単位で調整できます。流れは、打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始です。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

当社に向く相談・向かない相談

向く相談は、決済を含むプロダクトを新規に作り、その後も継続して改善していく案件です。SaaSのサブスクリプション課金、会員制サービス、予約と決済を組み合わせたサービスなど、要件が動き続ける開発と相性が良い体制です。

向かない相談も正直に書きます。1つ目は、Payment Linksで足りる規模の単品販売。これは自社で30分で終わる作業で、外注する費用に見合いません。2つ目は、要件が完全に確定していて改修予定のない単発の実装。この場合は請負のほうが適しています。3つ目は、カード情報を自社サーバーで扱う前提の実装(SAQ D)。監査体制まで含めた支援は当社の範囲外です。

合わない案件には、その旨を先にお伝えします。

【FAQ】Stripe決済の導入と手数料に関するよくある質問

Stripeの導入と手数料について、相談の場で繰り返し聞かれる質問を5つにまとめました。数値はすべて2026年9月15日時点で公式ページを確認したものです。

Q1. 個人事業主でもStripeは使えますか?

使えます。Stripeは初期費用・月額費用がなく、事業情報と本人確認を通せばアカウントを有効化できます。ただし、事業の所在国は本番でサービスを有効にした後は変更できないため(docs.stripe.com/get-started/account/activate、2026年9月15日確認)、法人化の予定がある場合は、どちらの名義で申し込むかを先に決めてください。

Q2. 審査にはどれくらいかかりますか?

事業情報が揃っていれば短く済みますが、業種や提出資料によって追加確認が入り、期間は変わります。Stripeは利用規約の遵守を確認するための審査を行い、追加情報を求める場合があると明記しており、具体的な日数は公開していません。実務上は、開発に着手する前にアカウントを作って事業情報を提出し、通ることを確かめてから実装を始めるのが安全です。

Q3. 3.6%は他社と比べて高いのですか?

国内のオンライン決済としては横並びの水準です。判断すべきは料率の小数点以下ではなく、通貨換算(+2%)、Billing(0.7%)、返金しても戻らない決済手数料、不審請求の申し立て(¥1,500)まで足した合計と、乗り換えに必要な再実装の工数です。料率を0.1%下げるために再実装で数十万円を使うなら、本末転倒になります。

Q4. 途中で導入方式を変えられますか?

変えられます。ただし決済画面とWebhookの処理を作り直すことになるため、実質は再実装です。Payment Links → Checkout は比較的軽く、Checkout → Elements は重くなります。逆方向(Elements → Checkout)への移行も選択肢で、「自由度が要らなかった」と分かった場合はむしろ保守が軽くなります。

Q5. 決済だけ先に作って、本体は後から作れますか?

可能です。Payment Linksで先に売上を立て、注文が増えてから会員機能や在庫連動を作るという順番は、検証フェーズの標準的な進め方。

まとめ: 手数料の全体像を先に出し、そのうえで導入方式を選ぶ

Stripeの導入可否は、決済手数料3.6%だけでは決まりません。通貨換算が必要なときの+2%、Stripe Billingの0.7%、不審請求の申し立て1件あたり¥1,500、そして返金しても元の決済手数料は戻らないという扱いまで足して、初めて自社の負担が出ます。加えて日本では日次入金が使えず、初回の着金は7暦日、その後の既定は4営業日です(すべて2026年9月15日にstripe.com/jpおよびdocs.stripe.comで確認)。料率は変わるため、契約前に必ず同じページで再確認してください。

合計が見えたら、次は導入方式です。Payment Links、Stripe Checkout、Elements、API直実装の4つは、コード量と自由度だけでなくPCI DSSのSAQ区分まで同時に決めます。カード番号を自社サーバーに通さない実装を選ぶこと——これが「カード情報の非保持化」の中身です。作業量の目安は、Payment Linksで当日〜数日、Checkoutで2〜4週間、Elements+サブスクリプションで1.5〜3か月。時間を食うのは決済画面ではなく、Webhookの受信・冪等化・突合のほうです。当社は決済アプリを新規開発し、そのまま週次の保守に入った実績から、この部分を体制で持つことをお勧めしています。

自社で持つのは要件と運用、外に出すのはコードと保守。Payment Linksで足りる規模なら、外注せず自社で完結させるのが一番安い選択です。決済を含むシステム全体の費用感はECサイト開発を外注する費用の相場、外注先の評価軸はシステム開発会社の選び方もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、どの導入方式が合うかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。