StripeでPayPayを受け付けるには、ダッシュボードで決済手段を有効にし、日本円の単発決済としてCheckoutかPaymentIntentを作るだけで足ります。一方で、継続課金・Stripe Connect・手動キャプチャーには対応しておらず、ここを知らずに設計すると後から作り直しが必要です。この記事では、Stripe PayPayの対応条件と手数料、Node.jsとcurlでの実装コード、サンドボックスでのテスト、採用と見送りの判断基準を、2026年10月時点の公式ドキュメントをもとに解説します。
まとめ｜Stripe経由のPayPay決済の対応条件・実装手順・非対応機能
Stripe経由のPayPayは、日本のStripeアカウントで日本円の単発決済を受けるための決済手段です。1回50円から100万円まで、手数料は3.98%（デジタルコンテンツ事業は9.48%）です。
実装はカード決済とほぼ同じ流れで、違いは顧客がPayPayへリダイレクトされて承認する点だけです。ダッシュボードでPayPayを有効にすれば、CheckoutやPayment Elementに自動で表示されます。注文の確定はWebhookで行い、戻り先ページだけに頼りません。
物販や予約の単発購入なら採用してよい手段です。月額課金やマーケットプレイスの売上分配が主目的なら、Stripe経由のPayPayは使えないため、別の経路を検討します。
Stripe経由のPayPay決済で使える範囲：対応条件・金額上限・手数料の確認
実装に入る前に、自社のアカウントと商材がPayPayの条件を満たすかを確かめます。条件から外れると、コードが正しくても決済画面にPayPayが出ません。
日本のStripeアカウントと日本円の決済に限られるPayPayの対応条件
Stripe公式のPayPay決済ページによると、PayPayを受け付けられるのはビジネスの所在地が日本（JP）のStripeアカウントで、顧客の所在地は日本、取引通貨は日本円（jpy）のみです。米国法人のアカウントで日本向けにPayPayを出す、ドル建ての商品に付ける、といった構成は取れません。
提供時期は、Stripeの2025年4月22日のニュースリリースで先行提供版の申し込み受付が始まったと発表されています。同リリースはPayPayを登録者数6,800万人のコード決済と紹介し、入金は他の決済手段と同じく4営業日で完了するという説明です。同リリースは、業界平均の翌月末入金より早い点を利点に挙げています。
1回50円から100万円まで・承認期限1時間という支払い側の制約
1回の請求額は最小50円、最大1,000,000円です。100万円を超える高額商材では、PayPayを選んだ顧客が決済できません。カートの合計が上限を超えたらPayPayを選択肢から外す制御か、注文分割の案内が要ります。
顧客がPayPay側で支払いを承認できる時間は1時間です。1時間以内に承認されないと、支払い試行はpayment_intent_payment_attempt_expiredで失敗します。在庫を仮押さえする実装では、仮押さえの解放時刻を1時間より長めに取ると、承認済みなのに在庫が無いという事故を避けられます。
決済手数料3.98%とデジタルコンテンツ9.48%で変わる粗利の試算
Stripeの日本の決済手段の料金ページでは、PayPayの手数料は決済成功ごとに3.98%、デジタルコンテンツ事業向けは9.48%です（2026年10月時点）。同じ売上でも、商材の区分で手数料は2倍以上違います。
| 決済額 | 通常（3.98%） | デジタルコンテンツ（9.48%） |
|---|---|---|
| 3,000円 | 約119円 | 約284円 |
| 10,000円 | 398円 | 948円 |
| 月商100万円 | 39,800円 | 94,800円 |
電子書籍や動画、オンライン講座のように粗利の薄いデジタル商材では、9.48%が採算を左右します。カードや他の決済手段の料率と並べた比較はStripeの機能一覧と日本の決済手段の料率にまとめています。
継続課金・Connect・異議申し立て・手動キャプチャーが非対応となる影響
公式ページの決済手段のプロパティでは、PayPayは継続課金・Connect・異議申し立て・手動キャプチャーのいずれも「いいえ」です。返金と一部返金には対応しています。設計への影響は次の4点です。
- 継続課金：Stripe Billingのサブスクリプションで毎月PayPayから引き落とす構成は組めない
- Connect：マーケットプレイスの出品者へ売上を分配するStripe Connectの資金フローにPayPayを載せられない
- 手動キャプチャー：
capture_method=manualで与信だけ取り、発送時に売上確定する運用ができない - 異議申し立て：PayPay決済でStripeのディスピュート対応フローは使わない前提になる
実務で最初に効くのは手動キャプチャーです。カード決済で「受注時に与信、出荷時に確定」の流れを組んでいる通販では、PayPayだけ受注時に即時売上となり、欠品時は返金で戻す運用に変わります。与信と売上確定の違いはオーソリと売上確定の実装パターンで解説しています。
ダッシュボードでPayPayを有効化してCheckoutで受け付ける手順
実装量がもっとも少ないのは、Stripeがホストする決済ページ（Checkout）を使う方法です。既にカード決済をCheckoutで受けているなら、追加のコードはほぼ要りません。
決済手段の設定画面でPayPayを有効にし動的な決済手段で表示させる
最初に、Stripeダッシュボードの決済手段の設定画面でPayPayを有効にします。公式ガイドは、Checkout SessionやPaymentIntentの作成時に決済手段の種類を固定で渡さず、動的な決済手段に任せる方式を推奨しています。Stripeが通貨・金額・顧客の所在地から表示可否を判断するため、PayPayが表示されるのは、日本円で50円から100万円までの決済だけです。
Checkout・Payment Element・Payment Linksは対応していますが、Apple PayやGoogle Payのボタンを並べるExpress Checkout ElementはPayPayに対応していません。ワンクリック決済のボタン群にPayPayを並べたいデザインは、そのままでは実現できない点を先に共有しておきます。
Checkout Sessionを支払いモードと日本円で作るNode.jsコード
Checkoutでの受け付けガイドの互換性条件は、支払いモードであること、明細の通貨がすべて同じであること、合計が50〜1,000,000円であることの3つです。セットアップモードとサブスクリプションモードではPayPayは表示されません。Node.jsでは次のように作成します。
const Stripe = require('stripe');
const express = require('express');
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY); // sk_test_ で始まるキー
const app = express();
app.post('/create-checkout-session', async (req, res) => {
const session = await stripe.checkout.sessions.create({
mode: 'payment', // PayPayは支払いモードだけで表示される
line_items: [{
price_data: {
currency: 'jpy', // 明細の通貨はすべて日本円にそろえる
product_data: { name: 'Tシャツ' },
unit_amount: 3000,
},
quantity: 1,
}],
success_url: 'https://example.com/after-checkout?session_id={CHECKOUT_SESSION_ID}',
});
res.redirect(303, session.url);
});決済手段を固定で指定していないため、ダッシュボードで有効にしたカードやPayPayが条件に応じて並びます。既存コードでpayment_method_types: ['card']を渡している場合は、そこにPayPayが含まれないので画面に出ません。公式の例のように['card', 'paypay']を足すか、指定自体を外して動的な決済手段へ移します。ui_modeの違いと埋め込み型Checkoutの実装はStripe Checkoutの実装方法：ui_mode別のセッション作成とWebhookでの注文確定で解説しています。
checkout.session.completedで注文を確定し二重処理を防ぐ実装
注文のフルフィルメントに関する公式ガイドは、顧客が戻り先ページを必ず開くとは限らないため、注文確定はWebhookで行うよう求めています。PayPayは承認の成否がすぐ確定する決済手段なので、checkout.session.completedを受けた時点でpayment_statusを確かめて確定できます。
app.post('/webhook', express.raw({ type: 'application/json' }), async (req, res) => {
let event;
try {
event = stripe.webhooks.constructEvent(
req.body, req.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET);
} catch (err) {
return res.sendStatus(400); // 署名が合わないリクエストは処理しない
}
if (event.type === 'checkout.session.completed') {
await fulfillCheckout(event.data.object.id);
}
res.sendStatus(200);
});
async function fulfillCheckout(sessionId) {
// 同じセッションIDで複数回・同時に呼ばれても、注文確定は1回だけにする
const session = await stripe.checkout.sessions.retrieve(sessionId, { expand: ['line_items'] });
if (session.payment_status !== 'unpaid') {
// 注文テーブルに session.id を一意キーで記録してから在庫・配送を動かす
}
}公式ガイドは、Webhookの遅延に備えて戻り先ページからも同じfulfillCheckoutを呼ぶ構成を勧めています。そのため関数は、同じIDで2回呼ばれても注文を二重に作らない作りが前提です。署名検証と冪等な確定の実装は決済Webhookの署名検証と冪等な注文確定で詳しく扱っています。
Payment Elementと独自UIでPayPayへリダイレクトさせる実装手順
自社の決済画面にフォームを埋め込む場合は、PaymentIntentを作り、Stripe.jsでPayPayへリダイレクトさせます。カード決済をPaymentIntentで実装済みなら、差分はリダイレクトと戻り先の処理です。
PaymentIntentをcurlで作りclient secretをフロントへ渡す
PayPayの受け付けガイド（ダイレクトAPI）の基本形は、金額と通貨だけを指定してサーバーでPaymentIntentを作る方法です。
curl https://api.stripe.com/v1/payment_intents \
-u "sk_test_xxxxxxxx:" \
-d amount=3000 \
-d currency=jpy \
-d "automatic_payment_methods[enabled]=true"APIバージョン2023-08-16以降はautomatic_payment_methodsが既定で有効なので、この行は省略できます。決済手段をPayPayに絞りたい場合、2026年10月時点のPaymentIntent作成APIのリファレンスでは作成時のパラメータ名がallowed_payment_method_typesで、ガイドの例も-d "allowed_payment_method_types[]=paypay"です。応答のclient_secretをフロントへ渡します。金額は改ざんを防ぐため必ずサーバー側で決めます。APIキーと冪等キーの扱いはStripe APIの使い方とPaymentIntentの作成を参照してください。
confirmPaymentにpaypayと戻り先URLを渡すリダイレクト処理
フロントではstripe.confirmPaymentにpayment_method_data.typeとしてpaypayと、承認後の戻り先return_urlを渡します。Stripe.jsがPayPayへのリダイレクトを処理します。
const stripe = Stripe('pk_test_xxxxxxxx');
document.getElementById('payment-form').addEventListener('submit', async (event) => {
event.preventDefault();
const { error } = await stripe.confirmPayment({
clientSecret, // サーバーで作成したPaymentIntentのclient secret
confirmParams: {
payment_method_data: { type: 'paypay' },
return_url: 'https://example.com/checkout/complete',
},
});
if (error) {
document.getElementById('error-message').textContent = error.message;
}
});return_urlを渡さずに確定するとpayment_intent_redirect_confirmation_without_return_urlで失敗します。リダイレクトを自前で処理する場合は、サーバーで確定したPaymentIntentのnext_action.typeがredirect_to_urlになるので、そのURLへ顧客を送ります。
return_urlで受け取るpayment_intentとステータス確認の分岐
PayPayでの承認後、顧客はreturn_urlに戻り、URLにはpayment_intentとpayment_intent_client_secretのクエリパラメータが付きます。支払いステータス確認の公式ガイドに沿って、このclient secretでPaymentIntentを取得し、statusで画面を分けます。
分岐は2つで足ります。succeededなら完了画面、requires_payment_methodなら拒否・期限切れとして決済手段の選び直しへ戻します。戻り先ページは表示のためだけに使い、在庫引当や発送指示はWebhookのpayment_intent.succeededで行う点はCheckoutと同じです。
サンドボックスでのPayPay決済テストとエラーコード別の対処
PayPayのテストには、カードのような番号の使い分けはありません。テスト決済ページで承認と拒否を選ぶ方式です。
サンドボックスのテスト決済ページで承認と拒否を切り替える確認手順
Payment Element版の受け付けガイドによると、サンドボックスで決済手段にPayPayを選んで支払うと、Stripeのテスト決済ページへリダイレクトされ、そこで承認か拒否を選べます。本番では顧客はPayPayのサイトへ送られ、この選択画面は出ません。
- テスト決済ページで承認し、完了画面とWebhookでの注文確定を確認する
- 同じ手順で拒否を選び、選び直し画面へ戻ることと注文が作られないことを確認する
- テスト決済ページを開いたまま閉じ、放置時に仮押さえ在庫が解放されるかを確認する
拒否を選ぶと、PaymentIntentのlast_payment_error.codeにpayment_intent_authentication_failureが入ります。カード決済の拒否理由別のテストはStripeテストカード一覧と使い方で扱っています。
payment_attempt_expiredなど5つのエラーコードと画面側の対処
受け付けガイドのエラーコード表から、実装で分岐させるものを抜き出すと次のとおりです。
payment_intent_payment_attempt_expired：1時間以内に承認されなかった。決済をやり直す導線を出すpayment_intent_authentication_failure：承認されずに失敗した。決済手段の選び直しへ戻すpayment_intent_payment_attempt_failed：支払い試行が失敗した。エラーメッセージを記録して原因を調べるpayment_intent_invalid_currency：日本円以外で作成した。通貨をjpyに直すpayment_intent_redirect_confirmation_without_return_url：戻り先URLなしで確定した。return_urlを渡す
下の2つは実装のバグで、本番の利用者に見せるものではありません。リリース前のテストで出なくなっていることを確かめます。上の2つは顧客の操作で日常的に起きるので、画面文言を用意しておきます。
365日以内の全額・一部返金とrefund.failed時の別手段での返金
PayPayは全額返金と一部返金に対応し、返金できる期間は購入後最大365日です。公式ページでは、PayPayの返金は即時に完了するとされています。
返金の最終結果はrefund.updatedまたはrefund.failedのWebhookで届きます。失敗した場合、金額はStripe残高に戻り、顧客に対しては、別の方法による返金の手配が必要です。返金処理を管理画面のボタン1つで終わらせる設計にせず、refund.failedを受けたら担当者へ通知する経路を作っておきます。
Stripe経由でPayPayを入れるか見送るかの判断基準と導入時の注意点
ここまでの制約を踏まえると、Stripe経由のPayPayが向く事業と向かない事業ははっきり分かれます。
単発購入のECと予約サイトでStripe経由のPayPayを採用する条件
採用してよいのは、次の条件をすべて満たす場合です。日本円の単発決済であること、1回の決済が100万円以下であること、出荷時の売上確定にこだわらないこと、そして決済をStripeに一本化して管理画面と入金を1つにまとめたいことです。
物販EC、イベントや施設の予約、受注生産でない単品販売はこれに当たります。既にStripeでカード決済を動かしているなら、追加の実装は決済手段の有効化とWebhookの分岐確認程度です。PayPayと直接契約して別の管理画面と入金サイクルを持つより、運用の手間は確実に少なくなります。コード決済全体の導入形態はQRコード決済の仕組みと導入形態で比べています。
サブスクやマーケットプレイスでStripe経由のPayPayを見送る場面
月額課金が売上の中心のサービスでは、Stripe経由のPayPayは見送ります。継続課金に非対応なので、毎月PayPayで払いたい顧客には毎回の手動決済を求めることになり、更新率が落ちます。継続課金の設計はサブスクリプション課金の仕組みと実装を参照してください。
出品者へ売上を分配するマーケットプレイスも同じ判断です。Connectに非対応なので、PayPayの売上だけプラットフォームの口座に入り、出品者への支払いを別に組む二重構造になります。デジタルコンテンツ事業で9.48%が粗利を圧迫する場合も、PayPayは既定の決済手段にしません。
PAY.JPやPayPay直接契約と比べた選び分けと開発体制の判断
PayPayを受け付ける経路は、Stripe経由のほかに、PAY.JP経由や、PayPayとの直接契約があります。PAY.JPのPayPayは同社の新しいAPI v2経由でのみ使えるため、既存のPAY.JP実装からは、移行作業が必要になる仕組みです。違いはPAY.JPの手数料とAPI v2でのPayPay導入で整理しています。PayPay以外の国内決済方法（コンビニ決済・銀行振込）をStripeで実装する手順はStripeの決済方法を有効化する手順：カード・コンビニ決済・銀行振込の実装とWebhookにまとめています。
判断の軸は、すでに使っている決済代行です。Stripeでカード決済を運用中ならStripe経由が最短で、Stripeを新規に入れるならStripeの仕組みと実装パターンから全体を検討します。在庫引当・返金・会計連携まで含めた決済フローの設計や、既存システムへのPayPay追加を外部に任せたい場合は、決済・サブスクリプションシステム開発で要件の整理から相談できます。
Stripe PayPay決済の実装と手数料に関するよくある質問
Stripe経由でPayPayを導入する際によく出る疑問をまとめました。
StripeでPayPayはいつから使えるようになりましたか？
Stripeは2025年4月22日のニュースリリースで、PayPayのオンライン決済の追加を発表し、同日から先行提供版の申し込み受付を始めました。2026年10月時点の公式ドキュメントでは、日本のStripeアカウントであれば、ダッシュボードの決済手段の設定画面からPayPayを有効にする手順が案内されています。アカウントの状態によって表示が異なる場合は、設定画面の表示とStripeのサポートで確認してください。
なお、PayPayの店頭での決済は、Stripe Terminalでは2026年10月時点で限定プレビューの扱いです。対面決済で使えるリーダーと決済手段、実装の流れはStripe Terminalの実装手順：日本の対応リーダーとサーバー主導型APIのコードにまとめています。
Stripe PayPayの手数料はいくらですか？
2026年10月時点のStripeの料金ページでは、PayPayの手数料は決済成功ごとに3.98%、デジタルコンテンツ事業向けは9.48%です。1万円の決済なら通常398円、デジタルコンテンツなら948円になります。月額の固定費の記載はなく、決済が成功した分だけかかります。料率は改定されることがあるため、契約前に料金ページの最新の表示を確認してください。
Stripe PayPayでサブスクリプションの定期課金はできますか？
できません。Stripe公式のPayPay決済ページでは継続課金が「いいえ」とされ、Checkoutのサブスクリプションモードとセットアップモードにも対応していません。PayPayは顧客が毎回承認する単発決済として使います。月額課金を受ける場合はカードなど継続課金に対応した決済手段を使い、PayPayは初回購入や単発の追加購入に限定する設計が現実的です。
Stripe PayPayの売上はいつ入金されますか？
Stripeの発表では、PayPayの売上はStripeの他の決済手段と同じスケジュールで、4営業日で入金されます。公式の決済手段ページでも、入金サイクルの記載は「標準」です。発表では、業界平均とされる翌月末入金より早い点が利点として示されています。入金の詳細な日程はアカウントの入金設定で確認できます。
Payment LinksやノーコードでもPayPayを受け付けられますか？
受け付けられます。公式ページでPayPayの対応プロダクトとして挙げられているのは、Payment Links・Checkout・Elementsです。Payment Linksはダッシュボードで作る決済用リンクで、PayPayを有効にしておけば、日本円の単発決済のリンクにPayPayが表示されます。コードを書かずに試せるため、本格的な実装の前に需要を確かめる手段としても使えます。
関連記事
- Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：PayPayを載せる前提となるStripeの全体像と実装パターン。
- Stripe APIの使い方：PaymentIntentの作成・APIキー認証・冪等キーをNode.jsとcurlで実装：PayPayでも使うPaymentIntentの基本実装。
- 決済Webhookとは？仕組み・主要イベントと署名検証・冪等な注文確定の実装を開発視点で解説：PayPay決済の注文確定を受けるWebhookの作り方。
- Stripeの機能一覧｜主要プロダクト14種の守備範囲と日本での提供可否：PayPayとカード・コンビニ決済などの料率比較。
- QRコード決済とは？仕組みとCPM・MPMの違い、店舗の導入形態と手数料の見方：PayPayを含むコード決済の方式と直接契約の手数料。
