PAY.JPとは？手数料3プランとAPI v1・v2の違い、実装コードとStripeとの選び分け【2026年10月】

PAY.JP（ペイドットジェーピー）は、BASEグループのPAY株式会社が運営するオンライン決済サービスです。クレジットカード決済をAPIでWebサービスやアプリに組み込む用途が中心で、2026年2月からはPayPayも扱えるようになりました。

この記事では、手数料とプラン切り替えの損益分岐、PayPay対応のAPI v2と定期課金が使えるAPI v1の選び方、テストカードと本番申請の流れ、payjp.jsとNode.jsで支払いを作るコード、2026年9月に適用されたオーソリ期限の短縮までを、公式の料金ページ・ドキュメント・お知らせ（2026年10月25日時点）で確かめた内容で整理します。

まとめ｜PAY.JPの手数料・v1とv2の選び方・2026年の仕様変更

PAY.JPの手数料は、月額0円のスタンダードが全ブランド3.3%、月額20,000円のビジネスが2.78%、月額50,000円のエンタープライズがVisa・Mastercardで2.59%です。導入費用と返金費用は0円で、入金ごとに振込手数料250円が差し引かれます。「2.59%〜」は最上位プランの料率なので、月間のカード決済額がおよそ385万円に届くまではスタンダードで見積もります。

APIはv1とv2の2系統があります。PayPayを使うならv2が必須で、定期課金（Subscription）やモバイルSDK、マーケットプレイス向けのPlatformを使うなら現時点ではv1しか選べません。v2の定期課金APIは2026年中、Platform対応は2027年中の予定と公式に告知されています。

本記事のv1実装例は、フロントでpayjp.jsと公開鍵を使ってカード情報をトークン化し、サーバーで秘密鍵を使って支払いを作る二段構えです。2026年9月14日からは海外発行カードのオーソリ期限が最大5日に短縮されたので、与信と売上確定を分ける実装はリクエストした日数ではなく返ってきたexpired_atで期限を管理します。

PAY.JPとは｜PAY株式会社の国産オンライン決済サービス

PAY.JPは2015年にBASE株式会社が開始した開発者向けの決済サービスで、現在はBASEの100%子会社であるPAY株式会社（東京都港区六本木・2018年1月4日設立）が運営しています。PAY株式会社のニュース一覧でも、同社は「BASEグループのPAY株式会社」と名乗っています。

対応する決済手段とカードブランド

クレジットカードはVisa・Mastercard・JCB・American Express・Diners Club・Discoverの6ブランドに対応し、ほかにApple PayとPayPayを扱えます。PayPayはAPI v2経由でしか使えず、Apple PayはAPI v1ならアプリとWeb、v2ならWebのみです。コンビニ決済・銀行振込・キャリア決済は2026年10月時点で提供されていません。PAY.JPは「PayPay」というコード決済とは別会社のサービスで、PayPayを決済手段の1つとして加盟店に提供する立場です。

開発者向けには、Ruby・PHP・Node.js・Python・Go・Java・Perlのサーバーライブラリと、iOS・Android・Flutter・React NativeのモバイルSDK（v1のみ）が公式に用意されています。決済代行の接続方式全体の中でPAY.JPがどこに位置するかは、決済システムの仕組みと決済代行との接続方式で整理しています。

PAY.JPで使える機能の範囲

カードの単発決済（Charge）、カードの保存（Customer・Card）、与信と売上確定の分離、定期課金（Plan・Subscription）、返金、Webhookによるイベント通知が基本機能です。複数の出店者に売上を分けるマーケットプレイス型には別サービスのPAY.JP Platformがあります。資金繰りの面では、将来の売上を最短翌日に入金するPAY.JP YELL BANKや、2026年7月15日に始まった請求書の買い取りサービスもあります。

PAY.JPの手数料と料金プラン（2026年10月）

PAY.JPの料金体系では、導入費用・返金費用・トランザクション費用はすべて0円で、通常の利用では決済手数料とプランの月額費用に加え、入金ごとの振込手数料250円がかかります。月額費用は売上金から相殺され、カード決済手数料は非課税です。

カード決済の3プランと決済額ごとの損益分岐

登録直後はスタンダードで、上位プランへは加盟店が自分で切り替えられます。月額費用の差額を料率差で割ると、切り替えの目安となる月間カード決済額が出ます。スタンダードとビジネスの差は0.52ポイントなので、20,000円÷0.52%で月商およそ385万円が分岐点です。ビジネスからエンタープライズへは、全件がVisa・Mastercardなら30,000円÷0.19%で月商およそ1,580万円、JCBやAmerican Expressばかりなら差が0.08ポイントしかなく分岐点は3,750万円まで上がります。ブランド別の売上構成を出してから決めてください。

提携プラン・業種別プランとPayPayの料率

ベンチャーキャピタル経由のPAY.JP Seedと、制作会社・開発会社経由のPAY.JP Partnerは、月額0円で2.78%が1年間適用され、その後スタンダードへ自動で移ります。旅行業登録事業者向けのPAY.JP Travelと、NPO法人の寄付向けのPAY.JP NPOは、Visa・Mastercardが1.5%、ほかのブランドが3.3%です。

PayPayは2026年2月12日のお知らせのとおり、物販・サービスが3.5%、電子書籍や動画配信などのデジタルコンテンツが9.0%で、別途消費税がかかります。プランによる区分はなく、取扱商材の審査で料率が決まります。

入金サイクルと振込手数料250円

カード決済の入金は月1回（末締め）か月2回（15日・末締め）から選べ、PayPayは月1回のみです。入金のたびに振込手数料250円が差し引かれるので、毎回振込が行われる場合、月2回では年24回分で6,000円となり、月1回の年3,000円より3,000円増えます。残高の繰延べと失効の仕様では、締め日の残高が10,000円未満なら振込は次のサイクル以降へ繰り延べられます。繰延べは最後の売上の集計区間の終了日から1年で期限を迎え、その時点で残高が1,000円未満なら振り込まれずに失効します。売上の小さいテスト運用のアカウントを放置しないでください。

API v1とAPI v2の選定基準｜PayPay・定期課金・モバイルSDKへの対応

PAY.JPは2026年2月12日に次世代のAPI v2を公開しました。v1は今後も提供が続き、すぐに移行する必要はないと公式が明言しています。どちらを選ぶかは、使いたい機能がどちらにあるかで決まります。API v1からの移行ガイドの差分表を要約すると次のとおりです。

判断は次の順で行います。PayPayを入れるならv2一択です。ただしv2には定期課金APIが無いので、サブスクリプションを同時に出すなら、v2の都度課金で更新日管理を自前で組むか、v2の定期課金APIの提供を待つかを選ぶことになります。モバイルアプリにネイティブの決済画面を組み込む、またはPlatformで売上を分配するなら、現時点ではv1で始めます。v1固有の機能が不要なカード決済だけの新規実装では、将来の決済手段追加に備えてv2を第一候補にします。v1で作ってからv2へ移すと決済画面とサーバーの両方を書き直すことになるので、既存のv1資産を流用できる場合に限り、v1で始める実装費用と将来の移行費用を比べます。

APIキーはv1とv2で共通で、Customerは同じIDのまま両方から使えます。一方で、v1で作ったChargeの返金や売上確定はv1でしか操作できず、返金期限は売上作成日から180日です。移行期間中の併用は認められていますが、恒常的な併用は想定されていないので、移行するならv1のChargeが残る期間だけv1の処理を残す計画にします。既存のv1加盟店がPayPayを追加する場合は、本番申請の該当箇所を入れ直して追加の審査を受ける必要もあります。

v2のWebhookでは、2026年10月1日からイベントのキー名がcreated_at・updated_at・metadataに統一され、旧キー（created_dateなど）は送られなくなりました（v2 Webhookのキー名変更のお知らせ）。2026年夏より前にv2を組んだ場合は、受信側が旧キーを読んでいないか確認してください。

PAY.JPの導入手順｜アカウント登録からテストカード・本番申請まで

アカウントを登録すると、すぐにテストモードのAPIキー（pk_test_で始まる公開鍵とsk_test_で始まる秘密鍵）が使えます。テストモードで実装を終えたら管理画面から本番利用を申請し、審査を通ると本番キー（pk_live_・sk_live_）で決済できるようになります。PAY.JPの公式サイトは、本番利用までを最短3〜4営業日と案内しています。

テストモードで使うテストカード番号

テストカードの一覧では、本物のカード番号の代わりに次の番号を使います。有効期限・セキュリティコード・名義は、バリデーションを通る値なら何でも構いません。

本番でよく起きるのは、トークンは作れたのに支払いで拒否される失敗です。4000000000080319や4000000000080202で、支払い作成時のエラー表示と注文の巻き戻しを必ず試してください。海外発行カードの4000000900000003は、後述のオーソリ期限の短縮を確かめる用途に使えます。

本番申請の審査期間とPayPayの追加審査

本番申請では、事業者・代表者・入金先・サービスと商材の情報に加え、サイトに掲載した特定商取引法に基づく表記・利用規約・プライバシーポリシーを求められます。審査期間のヘルプによると、最短3〜4営業日で使えるのはVisa・Mastercardだけです。JCB・American Express・Diners Club・Discover・Apple PayはVisa・Mastercardの可決後に審査が始まり、結果まで2週間〜1か月、結果の送付から利用開始までさらに約2週間かかります。PayPayは申請から審査完了までおよそ2〜3週間です。公開日が決まっているサービスは、JCBなどが使えない期間を見込んで申請を前倒ししてください。

PayPayは商材ごとに利用可否と料率（3.5%か9.0%か）が審査で決まり、与信と売上確定を分ける「出荷売上」の機能も加盟店ごとの審査です。PayPayの与信機能が有効になっていない状態でcapture_method: 'manual'を指定すると、決済時にエラーになります。

PAY.JP v1でカード決済を実装する手順

標準的なカード決済は、トークン作成・トークン送信・支払い作成・結果確認の4工程です。PAY.JP APIリファレンスによると、ベースURLはhttps://api.pay.jp/v1/で、認証はBasic認証（ユーザー名に秘密鍵、パスワードは空）です。金額は50円から9,999,999円までの整数、通貨はjpyのみです。以下は実装の骨格を示す例です。実行にはテスト鍵と各リソースIDの設定、注文取得関数の実装、フロントとAPIの接続が必要です。

payjp.jsでカード入力欄を表示してトークンを作る

payjp.jsガイドの手順どおり、スクリプトを読み込み、公開鍵で初期化してカード入力欄をマウントします。3Dセキュアをトークン作成時に行う場合は、トークン作成時の3Dセキュアにあるとおり第二引数でthree_d_secure: trueを渡し、名義とメールアドレスまたは電話番号を添えます。

<div id="card"></div>
<button id="pay">支払う</button>
<script src="https://js.pay.jp/v2/pay.js"></script>
<script>
  const payjp = Payjp('pk_test_xxxxxxxxxxxxxxxx', { threeDSecureWorkflow: 'iframe' });
  const cardElement = payjp.elements().create('card');
  cardElement.mount('#card');
  document.querySelector('#pay').addEventListener('click', async () => {
    const r = await payjp.createToken(cardElement, {
      three_d_secure: true,
      card: { name: 'TARO YAMADA', email: '[email protected]' },
    });
    if (r.error) { alert(r.error.message); return; }
    // トークンIDだけをサーバーへ送る（カード番号は自社を通らない）
    const res = await fetch('/api/charge', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ token: r.id, orderId: 'A-1001' }),
    });
    const body = await res.json();
    // サーバーが402を返したら（支払い作成で拒否）利用者にそのまま伝える
    if (!res.ok) { alert(body.message); return; }
    location.href = '/thanks';
  });
</script>

カード入力欄はPAY.JPのドメインで描画されるiframeなので、自社のJavaScriptからカード番号は読めません。2026年8月3日からは、トークン作成時のカード有効性確認は原則0円となり、失敗時は1円、さらに失敗すると11円で確認する方式に変わり、デビットカードで「11円の引き落とし通知」が出る問い合わせは起きにくくなりました。

curlとNode.jsで支払いを作り、与信と売上確定を分ける

まずはcurlで1件通すと、認証と必須パラメータの感触がつかめます。秘密鍵の後ろのコロンは、Basic認証のパスワードが空であることを表します。

# 与信だけ確保する（7日以内に確定する前提）
curl https://api.pay.jp/v1/charges \
  -u sk_test_xxxxxxxxxxxxxxxx: \
  -d card=tok_xxxxxxxxxxxxxxxx \
  -d amount=3500 \
  -d currency=jpy \
  -d capture=false \
  -d expiry_days=7
# 発送が決まったら売上を確定する
curl -X POST https://api.pay.jp/v1/charges/ch_xxxxxxxxxxxxxxxx/capture \
  -u sk_test_xxxxxxxxxxxxxxxx:

アプリケーションに組み込むときは、公式SDKのpayjp-nodeを使うと認証とエラー処理の記述が減ります。次は、上のフロントから受けたトークンで支払いを作るExpressの骨格例です。本番では注文の所有者確認、注文単位の排他制御、決済結果の保存と再照合を追加します。

// npm install express payjp
const express = require('express');
// Visaのブランドトークン適用で応答が延びるため、タイムアウトは余裕を持たせる
const payjp = require('payjp')(process.env.PAYJP_SECRET_KEY, { timeout: 30 * 1000 });
const app = express();
app.use(express.json());

app.post('/api/charge', async (req, res) => {
  const { token, orderId } = req.body;
  try {
    const order = await findOrder(orderId); // 金額はサーバー側の注文データから引く
    if (!order) return res.status(404).json({ message: '注文が見つかりません' });
    const charge = await payjp.charges.create({
      card: token,
      amount: order.amount,
      currency: 'jpy',
      metadata: { order_id: orderId },
    });
    res.json({ paid: charge.paid, id: charge.id });
  } catch (e) {
    res.status(402).json({ message: e.message });
  }
});
app.listen(3000);

金額をフロントから受け取ったまま使うと、改ざんされた金額で決済が通ります。例では注文IDだけを受け取り、金額はサーバー側の注文データ（findOrderは自社の実装）から引いています。metadataに注文IDを入れておくと、管理画面とWebhookの両方から注文を突き合わせられます。

レート制限はlivemodeでトークン作成10リクエスト毎秒、支払い作成・確定・返金14リクエスト毎秒、その他30リクエスト毎秒で、testmodeは一律2リクエスト毎秒です。超えるとHTTP 429とover_capacityが返ります。テストモードでは、アカウント内の各ゾーンへの送信頻度を毎秒2リクエスト以下に制御し、HTTP 429には待機後の再試行で対応します。

Webhookを受けてX-Payjp-Webhook-Tokenを検証する

PAY.JPのWebhook仕様では、イベントはPOSTで送られ、すべてのリクエストにアカウント固有のX-Payjp-Webhook-Tokenヘッダが付きます。応答は200である必要があり、それ以外なら3分間隔で最大3回まで再送されます。v2のWebhookガイドでは、10秒以内に2xxを返さないと失敗扱いになり、同じく3分間隔で最大3回再送されます。

const crypto = require('crypto');

app.post('/webhook/payjp', (req, res) => {
  const received = Buffer.from(req.get('X-Payjp-Webhook-Token') || '');
  const expected = Buffer.from(process.env.PAYJP_WEBHOOK_TOKEN);
  if (received.length !== expected.length ||
      !crypto.timingSafeEqual(received, expected)) {
    return res.sendStatus(401);
  }
  const event = req.body;
  // 同じイベントが再送されても二重処理しないよう event.id で重複を弾く
  if (event.type === 'charge.succeeded') {
    // 注文を確定する処理（冪等に書く）
  }
  res.sendStatus(200);
});

再送は3分間隔で3回なので、最初の送信から約9分で打ち切られます。デプロイやSSL証明書の期限切れで受信側が10分止まれば、その間の通知は取りこぼされます。管理画面から再送はできますが、夜間バッチで支払い一覧と注文を突き合わせる経路を1本持っておくほうが確実です。署名検証と冪等な注文確定の設計は決済Webhookの実装解説に、重複処理の止め方は冪等キーの発行・保存・再生にまとめています。

オーソリ期限の短縮（2026年9月）｜海外発行カードは最大5日

与信だけを確保して後から売上を確定する実装（capture=false）は、予約商材や受注生産で使われます。v1のexpiry_daysは既定7日で1〜60日を指定できます。v2の国内発行カードは通常7日、延長時25日で、PayPayは30日です。海外発行カードの扱いは、オーソリ期限の短縮についての続報どおり2026年9月14日から変わりました。

• 海外発行カード（Cardオブジェクトのis_jpがfalse）は、expiry_daysの指定に関わらず期限が最大5日に短縮される（v1・v2とも）
• v1の国内発行カードは指定どおりの期限が返るが、ブランドルール上の売上確定までの目安は最大25日程度。v2の国内発行カードは通常7日、延長時25日
• 目安を超えて売上確定すると「オーソリ未取得」を理由にチャージバックが成立する場合がある

短縮されてもオーソリ自体はエラーにならず、返ってくるexpired_atがリクエストより早い日時になるだけです。だから、「7日後に確定するバッチ」のように日数で決め打ちしている実装は、海外カードの注文だけ期限切れで確定に失敗します。期限管理はexpired_atを基準にし、5日を超えて確定を待つ商材では、海外発行カードの注文を即時売上にするか、期限前に再オーソリする分岐を入れてください。テストカード4000000900000003でこの挙動を再現できます。

v2では、2026年10月19日から与信期限切れやCheckout Sessionの期限切れでPayment Flowがキャンセルされたときにpayment_flow.canceled（cancellation_reasonはexpired）が送られるようになりました（2026年10月9日のお知らせ）。過去分の補正では通知が送られないので、それ以前の売上確定待ちの注文は自社のデータと突き合わせて整理します。与信と売上確定の考え方そのものはオーソリ（決済オーソリゼーション）の解説と売上確定（キャプチャ）の実装の勘所で詳しく扱っています。

PAY.JPの定期課金（Plan・Subscription）の実装と課金日の注意点

定期課金は、金額と周期を定義するPlanと、顧客とPlanを結ぶSubscriptionで実装します。v1の定期課金ガイドによると、Planのintervalはmonthかyear、trial_daysは0〜365日、月次プランのbilling_dayは1〜31日です。

# 毎月1日に課金する月額980円のプランを作る
curl https://api.pay.jp/v1/plans \
  -u sk_test_xxxxxxxxxxxxxxxx: \
  -d amount=980 \
  -d currency=jpy \
  -d interval=month \
  -d billing_day=1
# カード登録済みの顧客をプランに加入させる（初回は作成日から1日までの日割り）
curl https://api.pay.jp/v1/subscriptions \
  -u sk_test_xxxxxxxxxxxxxxxx: \
  -d customer=cus_xxxxxxxxxxxxxxxx \
  -d plan=pln_xxxxxxxxxxxxxxxx \
  -d prorate=true

billing_dayを指定すると、課金は指定日の日本時間午前9時ごろに固定されます。指定しないと最初に課金した時刻からのサイクルになり、29〜31日に始めた定期課金は2月を境に課金日が前にずれていきます。日本時間の深夜0時台に作った定期課金は、PAY.JP内部ではUTCの前日扱いになり、月末と月初が入れ替わることもあります。全会員の課金日をそろえる月次課金では、billing_dayを指定してください。加入日基準の課金では未指定も選べますが、月末とUTC基準による日付のずれを設計に織り込みます。

カードの有効期限切れなどで課金に失敗すると、Subscriptionのstatusはpausedになり、以降の課金は止まります。自動では再開されないので、subscription.pausedのWebhookを受けて顧客にカード更新を促し、カードを差し替えてから再開APIを呼ぶ流れを最初から組んでおきます。更新失敗の設計はサブスクリプション課金の更新失敗対策と同じ考え方です。

PAY.JPのセキュリティ｜PCI DSS・3Dセキュア・ブランドトークン

PAY.JPのセキュリティページによると、PAY.JPはPCI DSS Version 4.0のLevel 1サービスプロバイダで、APIを含む全機能でTLS 1.2以上が必須です。加盟店はPAY.JPへの問い合わせによりPCI DSSの準拠証明書（AOC）の取得・閲覧を依頼できるので、取引先のセキュリティ審査で提出を求められたときに使えます。

トークン化によるPCI DSS準拠範囲の縮小

payjp.jsのトークン化を使うと、カード番号はブラウザから直接PAY.JPへ送られ、自社サーバーを通りません。カード情報を保持も伝送もしないため、PCI DSSの準拠範囲を自己問診（SAQ）の小さい構成へ寄せられます。自前のフォームでカード番号を受ける実装は準拠範囲が一気に広がるので、採用する理由がありません。トークン化と暗号化の違いは決済トークンの仕組みで、12要件の全体像はPCI DSSの解説で確認できます。

3Dセキュアは全件実施が前提

経済産業省が2025年3月に公表したクレジットカード・セキュリティガイドラインの改訂で、EC加盟店にはEMV 3-Dセキュアの導入が求められています。PAY.JPにおける3Dセキュアでも、義務化要件を満たすには「すべての支払い作成前にトークン作成時の3Dセキュアを行う」か「すべての支払い作成時に3Dセキュアを行う」のどちらかが必要と明記されています。v2では全カードが初回決済までに3Dセキュア認証を求められます。

v1の実施方法はトークン作成時・支払い作成時・顧客カードの3つで、画面遷移はiframe型・リダイレクト型・サブウィンドウ型から選びます。認証結果はthree_d_secure_statusで確認し、verifiedとattemptedが成功です。認証は30分以内に終えないと期限切れになります。SPAならiframe型、サーバーレンダリングの画面ならリダイレクト型が素直で、サブウィンドウ型はポップアップブロックに当たるので第一候補にしません。認証の仕組みはEMV 3-Dセキュア2.0の解説が詳しいです。

Visaブランドトークン適用による応答時間への影響

2026年9月17日のお知らせで、Visaカードの決済ではカード番号の代わりにブランド（ネットワーク）トークンを使う処理が順次適用されると告知されました。加盟店側の改修は不要ですが、支払い作成APIの応答時間が延び、適用時期は個別に案内されません。タイムアウトを短く設定している実装や、毎朝のバッチで大量の定期課金を流す運用は、先にタイムアウト値とバッチの開始時刻を見直しておきます。上のNode.js例の30秒は説明用の設定値です。公式は具体的な応答時間を示していないため、自社の計測結果と注文の照合・復旧手順に合わせて調整します。

PAY.JPとStripe・KOMOJUの選び分け

PAY.JPは国内のカード決済を少ない手数料で素直に組み込むためのサービスで、決済手段の数や海外対応で選ぶサービスではありません。Stripeの日本の料金ページと並べると性格の違いがはっきりします。

Stripeの製品の広がりと日本での提供可否はStripeの機能一覧に、Stripe側でPayPayを組む手順はStripe PayPay決済の実装手順にまとめています。

PAY.JPの適性｜国内カード中心で決済額が伸びる事業

決済の中心が国内の円建てカードなら、標準料率の時点でPAY.JPの3.3%はStripeの3.6%より低く、カード決済額が月385万円を超えてビジネスプランに移ると差が広がります。月1,000万円なら、Stripeの3.6%が36万円、PAY.JPのビジネスプランが27.8万円＋月額2万円で、差は月6.2万円です。日本語のドキュメントと国内サポートだけで開発と運用を回したいチームにも向きます。

PAY.JPを選ばない方がよい場面

海外の顧客に現地通貨で請求する越境ECには使えません。コンビニ決済・銀行振込・キャリア決済まで1契約で揃えたいなら、KOMOJUの決済手段と手数料が比較対象になります。PayPayと定期課金を同時に、しかもAPIで完結させたい事業は、v2の定期課金APIが出るまでPAY.JPだけでは組みにくい時期です。実店舗のPOSとオンライン決済を同じ基盤で管理したいならSquare APIが候補に入り、PayPalとの比較が必要ならStripeとPayPalの違いも参考になります。Stripeそのものの仕組みと手数料はStripeの解説で確認できます。

よくある失敗は、料率だけでPAY.JPを選び、あとからPayPayとサブスクリプションの両方が必要になってv1とv2の板挟みになる形です。半年先までの決済手段と課金方式を書き出してから、v1かv2か、PAY.JPかStripeかを決めてください。定期課金・分配・基幹システム連携がある場合は、初期設計で決済状態の管理主体、重複処理の防止、障害時の照合手順を決めます。設計から相談したい場合は決済・サブスクリプションシステム開発で受け付けています。

PAY.JPのよくある質問

PAY.JPの手数料はいくらですか？

2026年10月時点で、カード決済は月額0円のスタンダードが3.3%、月額20,000円のビジネスが2.78%、月額50,000円のエンタープライズがVisa・Mastercard 2.59%・その他2.7%です。導入費用と返金費用は0円で、入金ごとに振込手数料250円がかかります。PayPayは物販・サービス3.5%、デジタルコンテンツ9.0%（別途消費税）です。

PAY.JPとStripeはどちらを選ぶべきですか？

標準料率ではPAY.JPの3.3%はStripeの3.6%より低く、月間カード決済額が約385万円を超えるとPAY.JP内ではビジネスプランが有利になります。総費用は振込手数料や追加機能の料金も含めて比較します。多通貨・越境、コンビニ決済、豊富な請求ロジックが必要ならStripeです。

PAY.JPのテストカード番号は何ですか？

Visaの成功用は4242424242424242、Mastercardは5555555555554444、JCBは3530111333300000です。有効期限・セキュリティコード・名義には、入力欄のバリデーションを通過する値を使います。支払い時に拒否されるカード（4000000000080319）や海外発行カード（4000000900000003）も用意されています。

PAY.JPのAPI v2で定期課金は使えますか？

2026年10月時点では使えません。v2の定期課金APIは2026年中の提供予定です。今すぐPlanとSubscriptionで定期課金を組むならv1を使い、v2では都度課金で更新日管理を自前で実装します。

PAY.JPのWebhookが届かないときはどうなりますか？

200以外を返すと3分間隔で最大3回再送され、それでも失敗すれば自動の再送は止まります。管理画面から手動で再送できますが、支払い一覧と注文を定期的に突き合わせるバッチを用意しておくと取りこぼしを防げます。

関連記事

• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説
• オーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンを開発視点で解説
• 決済Webhookとは？仕組み・主要イベントと署名検証・冪等な注文確定の実装を開発視点で解説
• サブスクリプション課金とは？継続課金の仕組み・オフセッション決済と更新失敗対策の実装を開発視点で解説
• KOMOJU（コモジュ）とは？運営会社・手数料3.25%と2026年10月の不正アクセスの影響を解説