PAY.JPとは？国産決済APIの手数料・実装フロー・Stripeとの選び分けを開発視点で解説

PAY.JP（ペイ・ジェーピー）は、クレジットカード決済をシンプルなAPIでWebサービスやアプリに組み込める、日本発のオンライン決済サービスです。この記事では「PAY.JPとは何か」という定義から一歩踏み込み、2.59%〜の決済手数料の構造、公開鍵と秘密鍵を使い分けるトークン化の決済フロー、Charge・Customer・Subscription・3Dセキュアといった実装パターン、そしてグローバル志向のStripeとの選び分けまで、開発者・技術選定者が導入可否を判断できる粒度で整理します。読み終えると、自社の要件でPAY.JPが合うのか、どこまで内製し、どこから受託開発に委ねるべきかが判断できます。

まとめ｜PAY.JP導入判断の手数料・実装フローと採用可否の要点

PAY.JPは、初期費用・月額固定費なしのプランから始められ、決済手数料は業界最低水準の2.59%〜（業種向け特別プランで1.5%〜）で導入できる国産のオンライン決済サービスです。対応の中心はクレジットカードで、2026年2月にはPayPayが決済手段へ加わりました。運営はPAY株式会社で、カード情報を事業者側に通さないトークン化設計とPCI DSS v4.0 Level 1認定により、準拠の負担を小さく保てます。

実装は、フロントで公開鍵を使いカード情報をトークン化し、そのトークンをサーバーへ渡して秘密鍵で支払い（Charge）を作成する二段構えが基本です。顧客カードの保存はCustomer、定期課金はPlanとSubscription、複数事業者への分配はTenant（Platform）が担い、決済結果はWebhookで非同期に受け取ります。APIは日本語ドキュメントが整い、リソース構成が素直なため、標準的なカード決済なら実装のリードタイムが短いのが特長です。判断の分岐点は「決済要件がシンプルなカード決済に収まるか」で、グローバル・多通貨・高度な請求ロジックまで求めるならStripeとの比較や、受託開発での設計を挟む価値が出ます。

PAY.JPとは何か｜国産オンライン決済サービスとしての立ち位置

PAY.JPは、PAY株式会社（2018年1月設立・東京）が提供する、開発者起点のオンライン決済サービスです。ECサイトやSaaS、予約サービスなどにクレジットカード決済を組み込む用途を主軸に、シンプルなAPIと管理ダッシュボードで決済の受け付け・返金・定期課金までを扱えます。「多機能な決済インフラ」というより、日本国内のカード決済を最短距離で実装するための実務的なサービスと捉えると位置づけを見誤りません。

PAY.JPの定義と決済代行サービスとしてカバーする提供範囲

PAY.JPの中核は、Web・モバイルアプリからの決済リクエストをカードブランドへつなぎ、成功・失敗・返金・与信といった状態を一貫して管理するAPI群です。クレジットカードはVisa・Mastercard・JCB・American Express・Diners Clubの主要ブランドに対応し、2026年2月にPayPayが決済手段として追加されました。導入は申し込みから利用開始までオンラインで完結する3ステップ方式で、面倒な書面契約を挟まずに始められます。事業者はカード番号の生データに触れずに決済を完了でき、PCI DSS v4.0 Level 1のサービスプロバイダ認定を受けた基盤上で運用されます。

国産の決済サービスならではの日本語ドキュメント対応と導入のしやすさ

PAY.JPが国内プロジェクトで選ばれる背景には、ドキュメント・管理画面・サポートが日本語で完結し、国内の商習慣に沿った入金や請求に馴染みやすい点があります。海外発の決済プラットフォームは機能が厚い一方、規約や税・請求の実務で英語一次情報に当たる場面が増えます。PAY.JPは、国内カード決済に要件が収まるプロダクトであれば、仕様理解から実装・問い合わせまでの摩擦が小さく、開発チームの学習コストを抑えやすいのが実務上の利点です。決済方式そのものの選び方は決済システムとは何かで全体像を整理できます。

PAY.JPの決済手数料と料金プランの内訳｜総額を見積もる観点

PAY.JPの料金は決済手数料に一本化されており、見積もりはこの手数料とプラン費用の合算で組み立てます。「2.59%だけ」で終わらせず、業種・プラン・決済手段の3軸で総額を見積もると、実運用のコストを取り違えません。

決済手数料2.59%〜と業種別プランで適用が変わる料率の考え方

PAY.JPの決済手数料は業界最低水準を掲げる2.59%〜で、固定費やトランザクションごとの費用は発生せず、決済手数料のみが課される明朗会計です。特定の業種・事業に向けた特別プランでは1.5%〜の料率が案内される場合があり、適用料率は取扱高や業態によって異なります。初期費用・月額費用ともに0円のStandardプランに対し、上位プランは機能を保ったまま月額費用が設定される料金体系です。実料率は審査・契約時に確定するため、想定売上と業種を前提に見積もりを取り、料率を数値で押さえてから採用可否を判断します。

売上比例のため小規模では割安に働き、月間の決済額が伸びるほど料率の絶対額が効いてきます。取扱高が大きい事業では、料率の刻みと業種プランの適用可否が総コストを左右するので、想定売上を入れた試算を必ず行います。

入金・返金など運用フェーズで発生するコストの見落としを防ぐ観点

手数料率だけでなく、入金サイクルと返金・チャージバック時の扱いも運用コストとして事前に確認します。決済代行では、売上が事業者に入金されるまでのサイクルや、返金・不正利用が発生した際の手数料の考え方がキャッシュフローに直結します。PAY.JPでも入金や返金はAPIとダッシュボードで管理できますが、料率の低さだけで判断すると、入金サイクルや運用時の負担を見落としがちです。導入前に、平常時の料率と、返金・チャージバックが起きたときの実務フローの両方を押さえておくと、原価計算で後追いの修正が起きません。

PAY.JP APIの構成と決済フロー｜公開鍵・秘密鍵とトークン化

PAY.JPの実装を理解する鍵は、APIキーの使い分けとトークン化の流れです。ここを押さえると、どの処理をフロントに置き、どこからサーバーで扱うべきかの線引きが明確になります。

公開鍵と秘密鍵の役割分担と主要なAPIリソースの全体像の把握

APIのベースURLは https://api.pay.jp/v1/ で、認証はBasic認証（ユーザー名に秘密鍵、パスワードは空）です。キーは2種類あり、公開鍵（pk_test_・pk_live_）はフロントでカード情報をトークン化する用途に限られ、秘密鍵（sk_test_・sk_live_）はサーバー側で支払い作成や顧客管理などすべての操作に使います。test系は実際の請求が発生しないテスト環境、live系が本番です。主要なリソースは、単発決済のToken・Charge、カード保存のCustomer・Card、定期課金のPlan・Subscription、複数事業者向けのTenant（Platform）、通知のEvent・Webhook、入金のTransferで構成され、素直なオブジェクト設計になっています。

トークン生成から支払い作成までをつなぐ基本的な決済実装のフロー

標準的なカード決済は、次の流れで組み立てます。カード番号をサーバーに通さないことが、PCI DSS準拠範囲を小さく保つ設計の要点です。

1. トークン生成：フロントで公開鍵を使い、入力されたカード情報をトークン化します（tokens エンドポイントへPOST）。カード番号はブラウザから直接PAY.JPへ送られます。
2. トークン送信：生成されたトークンIDだけを自社サーバーへ渡します。生のカード番号は自社を経由しません。
3. 支払い作成：サーバーで秘密鍵を使い、トークンIDを指定して支払いを作成します（charges エンドポイントへPOST・card=token_id／amount／currencyを指定）。
4. 結果確認：返ってきたChargeオブジェクトのpaid=trueで成功を確認し、注文確定などの後続処理へ進みます。

支払い作成時にcaptured=falseを指定すると、与信枠の確保のみを行い後から売上を確定できます。この与信と確定を分ける仕組みはオーソリ（決済オーソリゼーション）の考え方そのもので、予約商材や在庫確保が絡む決済で使い分けるものです。トークン生成は10req/s、支払いは14req/s、その他は30req/sというレート制限（livemode）があり、超過時はHTTP 429のover_capacityが返るため、大量処理では再試行の設計を織り込みます。

顧客カードの保存・定期課金・プラットフォーム分配の実装パターン

カードを保存して再利用する場合はCustomerに紐付け、default_cardでメインカードを指定します。定期課金は、金額と課金間隔（月次・年次）やトライアル日数を定義するPlanと、それに基づいて自動で繰り返し課金するSubscriptionで実装する形です。更新日計算や停止・再開・解約の状態管理をAPIに委ねられます。複数の出店者や事業者に売上を分配するマーケットプレイス型では、Tenant（PAY.JP Platform）を使って事業者単位に手数料率を設定し、入金先を分けます。自前で更新日や分配ロジックを組むより、これらのオブジェクトに状態管理を委ねるほうが破綻しにくい設計です。

PAY.JPのセキュリティ設計と3Dセキュア対応の実装パターン

カード決済を扱う以上、PCI DSS準拠と本人認証は避けて通れません。PAY.JPはこの負担を軽くする仕組みを備えており、実装方式の選定がそのままセキュリティ要件の選定になります。

トークン化によるPCI DSS準拠範囲の最小化と負担軽減の考え方

PAY.JPのトークン化を使うと、カード番号はブラウザから直接PAY.JPへ送られてトークンに変換され、自社サーバーを通りません。事業者はカードの生データを保持・伝送しないため、PCI DSSの準拠範囲を自己問診（SAQ）の最小構成へ寄せられます。逆に、トークン化を使わず自前フォームでカード番号を受けてしまうと準拠範囲が一気に広がるため、フロントでのトークン生成は「実装の型」であると同時に「準拠負担を最小化する前提」だと捉えます。基盤側はPCI DSS v4.0 Level 1のサービスプロバイダ認定を受けており、事業者は自社が触れる範囲だけを守れば十分です。

3Dセキュア（EMV 3-D Secure）の3つの実装パターン

PAY.JPはEMV 3-D Secureに対応し、支払い作成時などにthree_d_secure=trueを指定して本人認証を開始します。カード発行会社の認証画面を経て、tds_finishにあたる工程で認証後の決済を実行し、three_d_secure_statusで認証結果（verified・attempted・failedなど）を確認する流れです。実装パターンは、トークン作成時に認証する方式、支払い作成時に認証する方式、保存済みの顧客カードで認証する方式の3通りがあり、それぞれ画面遷移（リダイレクト／iframe等）の扱いが異なります。国内では不正利用対策として3Dセキュアの導入が求められる場面が増えており、どのパターンを選ぶかは、決済体験（離脱率）と対策の強度のトレードオフで決めます。

PAY.JPとStripe・他の決済代行の選び分け｜採用判断の軸

ここからは判断を言い切ります。PAY.JPは万能ではなく、料金構造と機能の範囲から「合う要件」と「過剰・不利になる要件」がはっきり分かれます。

PAY.JPの採用が合うプロダクト要件と事業フェーズの具体条件

次の条件が2つ以上重なるなら、PAY.JPの採用が合います。第一に、決済の中心が国内のクレジットカードで、要件がシンプルなカード決済・定期課金に収まること。第二に、日本語ドキュメントと国内サポートで開発・運用を回したいこと。第三に、初期費用を抑えて短期間でカード決済を立ち上げたいアーリーフェーズであること。第四に、素直なAPIで自社サイト内に決済を組み込み、学習コストを抑えたいこと。これらはPAY.JPがシンプルなAPIで直接支える領域で、重厚なプラットフォームだとかえって過剰になる部分です。

Stripeなどグローバル決済と比較して見送る・切り替える場面

逆に、次の場面ではPAY.JPだけで完結させず、比較や切り替えを検討します。多通貨・越境ECで海外発行カードや現地決済手段を幅広く扱いたい場合、あるいは高度な請求ロジック（従量課金の細かな按分、複雑な分配、豊富な決済手段の同時提供）が要件に入る場合は、機能の厚いStripeのほうが自前実装を減らせることがあります。両者は「国産のシンプルなカード決済 ⇔ グローバルで多機能」という軸で性格が異なるため、対象市場・決済手段・請求ロジックの複雑さを並べて選ぶのが妥当です。事業フェーズや商材ごとに使い分ける判断もあり得ます。実店舗のPOS決済とオンラインを同じ基盤で一元管理したいなら、Square APIも選択肢に入ります。

内製での実装と受託開発を分ける判断軸と外注が向く具体的な局面

内製と受託開発の分岐点は「決済フローに独自要件がどれだけあるか」です。トークン化とChargeで完結する標準的なカード決済なら、日本語ドキュメントが整うPAY.JPは内製で十分に回せます。一方、Subscriptionでの複雑な課金設計、Tenantによる分配、既存の基幹システムや会計とのAPI連携、Webhookの署名検証・冪等（べきとう）処理・再送対策まで絡むと、初期の設計品質がその後の事故率を大きく決める局面です。ここは決済とシステム連携の設計経験がある体制で固めたほうが、後戻りコストを抑えられます。要件が複雑な決済・サブスクリプションの構築は決済・サブスクリプションシステムの受託開発で設計から相談でき、基幹システムや外部サービスとのつなぎ込みはAPI開発・システム連携の領域として切り出せます。内製で走り出しつつ、難所だけ外部の設計を挟む進め方も有効です。

PAY.JP導入でよくある質問｜手数料・API実装・安全性の疑問

PAY.JPの導入検討でよく挙がる質問に、開発・費用・セキュリティの観点から簡潔に答えます。

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

標準の決済手数料は業界最低水準を掲げる2.59%〜で、固定費やトランザクションごとの費用はかからず、決済手数料のみが課される明朗会計です。特定の業種向けには1.5%〜の特別プランが案内される場合があります。Standardプランは初期費用・月額費用ともに0円で始められますが、実際の適用料率は業種や取扱高、契約内容で確定するため、想定売上を前提に見積もりを取って判断します。

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

国内のカード決済が中心で、要件がシンプルなカード決済・定期課金に収まり、日本語での開発・運用を重視するならPAY.JPが向きます。多通貨・越境や、豊富な決済手段・高度な請求ロジックまで求めるなら、機能の厚いStripeが自前実装を減らせる場面があります。対象市場・決済手段・請求ロジックの複雑さを並べ、要件で選ぶのが妥当です。

PAY.JPの実装にはどの程度の開発工数がかかりますか？

標準的なカード決済は、フロントでのトークン生成とサーバーでの支払い作成という二段構えで組め、リソース設計が素直なため小〜中規模で実装できます。顧客カードの保存（Customer）、定期課金（Plan・Subscription）、Webhookでのイベント処理、3Dセキュアを含めるほど設計・テストの比重が上がるため、まず単発決済で公開し、段階的に機能を足す進め方が現実的です。

PAY.JPはPCI DSSやセキュリティの面で安全ですか？

PAY.JPの基盤はPCI DSS v4.0 Level 1のサービスプロバイダ認定を受けた環境です。トークン化を使えばカード番号はブラウザから直接PAY.JPへ送られ、自社サーバーを経由しないため、事業者側のPCI DSS準拠範囲を最小構成へ寄せられます。自前フォームでカード番号を受ける実装は準拠範囲が広がるため避け、3Dセキュアやアクセス制御を要件に応じて組み合わせます。

PAY.JPは3Dセキュアに対応していますか？

EMV 3-D Secureに対応しており、支払い作成時などにthree_d_secure=trueを指定して本人認証を開始し、認証後に決済を確定します。トークン作成時・支払い作成時・顧客カードの3つの実装パターンがあり、画面遷移の扱いはパターンごとに異なる点に注意が必要です。国内でも不正利用対策として3Dセキュアの導入が求められる場面が増えているため、決済体験と対策強度のバランスで実装方式を選びます。

関連記事

• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：グローバル志向のStripeと比較し、多通貨・多機能が必要な場面での選び分けを確認できます。
• オーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンを開発視点で解説：PAY.JPのcaptured=falseで使う与信確保と売上確定の考え方を掘り下げられます。
• 決済システムとは？仕組み・種類と、決済代行との接続方式・自社構築の判断軸を解説：PAY.JPを含む決済方式全体の選び方と、自社構築の判断軸を整理できます。
• 決済・サブスクリプションシステム開発：定期課金や分配など、要件が重い決済実装を設計から相談できます。
• API開発・システム連携：PAY.JPと基幹システム・外部サービスをつなぐAPI連携の設計・実装を切り出せます。