分割払いAPIとは？イシュア分割・自社割賦・BNPLの違いと決済実装を開発視点で解説

分割払いAPIとは、一回分の支払いを複数回に分けて回収する決済を、加盟店のシステムからプログラムで扱うためのAPIの総称です。高額商品のECやサービス契約で「3回払い」「6回払い」を提供したいとき、決済システムを実装する側から見ると、一括のカード決済とは別に、誰が分割手数料と回収リスクを負うのか、どの支払方式をどう提示するのか、といった設計判断が必要になります。この記事では「分割払いAPIとは何か」という定義から、カード会社が引き受けるイシュア分割・自社が割賦債権を持つ自社割賦・第三者が立替えるBNPLという3方式の違い、Stripeなどで利用可能な分割プランを取得して顧客に選ばせる決済フロー、対応ブランドや回数・通貨の制約、割賦販売法と本人認証・確定処理の連携、そして内製と受託開発のどちらで進めるかの判断軸までを、開発者が設計に落とせる粒度で整理します。

まとめ｜分割払いAPIの方式差と実装判断の要点

分割払いAPIは、支払いを複数回に分ける決済を扱う仕組みですが、実装で最初に決めるべきは「誰が分割の手数料と回収リスクを負うか」です。この負担者の違いが、3つの方式を分ける軸になります。顧客のカード発行会社が引き受けるイシュア分割（オンアス分割）なら、加盟店は通常の一括カード決済と同じく全額を一括で受け取り、利息は顧客がカード会社へ支払う関係です。加盟店自身が割賦債権を持つ自社割賦や、第三者が立替えるBNPL・後払いは、回収リスクと法規制の負担が加盟店側に寄ります。

EC加盟店が最も組みやすいのはイシュア分割で、決済代行のAPIで分割払いを有効化し、利用可能な分割プラン（固定回数・リボ払い・ボーナス払い）を取得して顧客に選ばせ、確定時に選択プランを渡すだけで、与信も分割手数料もカード会社側に載る形です。判断の分岐点は「回収リスクと法規制を自社で抱えるか」で、無利息の集客訴求や自社金融までやりたいのでなければ、イシュア分割を選ぶのが実装も法対応も軽くなります。なお分割払いも各回の内部では通常のカード決済と同じ与信取得と確定が走るため、仕組みは与信枠とはとオーソリとはで地続きに押さえられ、具体的な実装パターンはStripeとはで確認できます。

分割払いAPIとは｜定義と、分割を引き受ける主体で分かれる3方式

まず押さえたいのは言葉と方式の整理です。分割払いAPIは決済処理を呼び出すインターフェースにすぎず、その裏で「どの主体が分割を引き受けるか」が違うと、加盟店の入金・リスク・法対応がまるごと変わります。ここを取り違えると選定を誤ります。

分割払いAPIの定義と、一括のカード決済とは何が実装で異なるか

分割払いAPIとは、支払総額を複数回に分けて回収する決済を、加盟店のシステムからプログラムで発行するためのAPIの総称です。決済代行（PSP）が提供し、通常の一回払いの決済リクエストに「分割で処理する」という意図、すなわち支払方式と回数を追加で載せる形で使います。一括決済との実装上の違いは、金額を分割する計算ロジックを加盟店が持つかどうかではなく、分割の情報を決済リクエストに正しく載せ、その分割を引き受ける主体の仕組みに合わせて画面と後処理を組めるか、という点です。分割払いといっても加盟店のシステムが月々の金額を自分で請求し続けるとは限らず、方式によっては加盟店は一括で受け取り、分割の管理はカード会社側で完結します。

誰が分割手数料と回収リスクを負うか｜イシュア分割・自社割賦・BNPL

分割払いは、負担の主体で3つに分かれます。1つ目はイシュア分割（オンアス分割）で、顧客のカード発行会社が分割の与信と手数料を引き受ける方式です。加盟店は通常の一括カード決済と同様に全額を一括で受け取り、分割手数料（利息）は顧客がカード会社へ支払います。EC加盟店が決済代行のAPIで組む分割払いは、多くがこの方式です。2つ目は自社割賦で、加盟店または提携する信販会社が割賦債権を保有し、複数回に分けて自ら回収します。回収リスクを自社で抱えるうえ、後述の割賦販売法の規制対象にもなり得る方式です。3つ目はBNPL・後払い（分割後払いサービス）で、第三者が代金を立替払いして加盟店には一括入金し、顧客からの回収はそのサービス事業者が担います。どの方式を選ぶかで入金タイミング・貸倒れリスク・必要な法対応が変わるため、方式の選択が分割払いAPI導入で最初に越える分岐点です。決済方式や接続方式そのものを俯瞰したい場合は決済システムとは？仕組み・種類と接続方式・自社構築の判断軸で全体像から整理できます。

分割払いAPIの仕組み｜イシュア分割の決済フローと実装の流れ

ここからは、加盟店が最も組みやすいイシュア分割を軸に、決済APIがどう動くかを追います。要点は、分割プランを固定で埋め込むのではなく、カードごとに利用可能なプランを判定して顧客に選ばせる、という流れです。

決済APIで分割払いを有効化し、利用可能な分割プランを取得する

イシュア分割では、まず決済リクエストで分割払いを有効化します。Stripeを例に取ると、支払い方法のオプションでカードの分割払い設定を有効（enabled を true）にしておき、顧客がカード番号を入力・設定した後に、そのカードで利用可能な分割プランを決済プラットフォーム側が判定します。プランを固定でハードコードしないのは、使えるプランがカードブランドやカードごとに変わるためです。実装としては、カード情報を設定してから利用可能な分割プラン（available_installments_plans に相当する情報）を取得し、その一覧を決済画面に提示する順番になります。Stripeがホストする決済画面を使う場合は、対応カードが入力されたときだけ分割払いの選択肢が自動で現れ、加盟店が直接APIを叩く場合は、カード番号を収集してから利用可能プランを表示する流れが推奨されています。

選択した分割プランを確定し、加盟店は全額を一括入金で受け取る

顧客がプランを選んだら、決済の確定時にその選択プランを渡します。プランは、支払方式を表すtype（固定回数の fixed_count、リボ払いの revolving、ボーナス払いの bonus）と、回数を表すcount、支払間隔を表すintervalといった要素で構成されます。ここで押さえるべき勘所は入金の形です。イシュア分割では、加盟店は分割払いを受け付けても追加手数料はかからず、通常のカード決済と同様に全額を一括で受け取ります。顧客が支払う分割手数料（利息）は顧客とカード発行会社の間の話で、加盟店の入金額には影響しません。利息は、2回払いやボーナス払いのプランでは原則かからず、それ以外の分割では顧客に発生するのが一般的です。この「加盟店は一括入金・与信と手数料はカード会社」という性質が、イシュア分割を実装面でも法対応面でも軽くしています。なお分割払いの各回そのものは、通常のカード決済と同じく与信取得（オーソリ）と売上確定の流れに乗る点は変わりません。承認から確定までの内部処理はオーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンで確認できます。

分割払いAPI実装の制約｜ブランド・回数・割賦販売法と本人認証

分割払いAPIは、一括決済にはない外部条件の制約を受けます。対応ブランドと回数、法規制、本人認証の3点を設計前に把握しておかないと、対応できないカードで分割が出せない、あるいは表示義務を満たせない、といった手戻りが起きます。

対応カードブランドと分割回数・通貨の制約を選定時に必ず確認する

イシュア分割は、すべてのカードブランドで同じように使えるわけではありません。Stripeの日本向け分割払いを2026年7月時点で見ると、Visaとmastercardは分割・リボ払い・ボーナス払いに対応し分割は最大60回程度まで、JCBは分割が最大24回程度まで、American Expressは分割払いに非対応、Diners Clubはリボ払いとボーナス払いのみ、といったブランドごとの差があります。加えて、通貨は日本円のみ、対象は日本で発行されたクレジットカード（デビットカードやプリペイドカードは不可）という条件が付きます。また、顧客が支払い時にプランを選ぶ都度の決済に限られ、登録カードへ自動で繰り返し課金する継続課金との併用はできません。ボーナス払いは受付期間が季節で制限される点も、UIの出し分けに関わります。これらの対応範囲は決済サービスやブランドの規約で変わり得るため、断定せず、選定するPSPの最新ドキュメントで対応ブランド・回数・通貨を必ず確認してください。継続課金側の反復決済との違いはリカーリング決済とは？カードオンファイルとMIT・CITの仕組みで整理できます。

割賦販売法の負担範囲と、本人認証・確定処理との実装連携の要点

法規制の重さも方式次第です。割賦販売法は、2026年7月時点の枠組みで、支払期間が2ヶ月以上かつ3回以上の分割払い（またはリボ払い）を「割賦販売／信用購入あっせん」として規制対象とし、支払総額や手数料・支払時期の表示義務、過剰与信を防ぐための支払可能見込額の調査などを課しています。翌月一括や2回払い、ボーナス一括はこの定義の外です。ここで重要なのは、イシュア分割ではこれらの与信審査や法定表示の義務を主にカード発行会社が負う点で、加盟店の実装負担が軽くなります。逆に自社割賦を選ぶと、これらの義務を加盟店（または提携信販）が正面から引き受けることになります。実装連携としては、EC決済で分割払いを扱う場合も本人認証（3Dセキュア2.0）を通す設計が求められ、決済の確定や返品・キャンセルはWebhookで非同期に受け取って自社の状態を更新するのが定石です。本人認証の組み込みは3Dセキュア2.0（EMV 3-Dセキュア）とは？仕組み・認証フローとEC決済への実装、分割の各回で確保される与信の考え方は与信枠とは？クレジット決済の仕組み・オーソリでの確保と再オーソリ実装で確認できます。

分割払いAPIを内製と受託開発で分ける判断軸と外注が向く局面

ここからは判断を言い切ります。分割払いAPIは、イシュア分割で標準的な回数を提示するだけなら内製で十分に組めますが、自社割賦やBNPL、独自の分割条件が絡むと、法対応と回収設計の品質が事業リスクを直接左右するため、体制の選び方が結果を分けます。

内製で組み切れる分割払いAPIの要件と、標準機能で足りる範囲

次の条件に収まるなら、内製で十分に回ります。国内取引でイシュア分割を採用し、決済代行が提供する分割払い機能をそのまま使って、利用可能な分割プランの取得・提示・確定をプラットフォーム側に任せられるケースです。この範囲であれば、加盟店は一括入金で受け取り、与信も分割手数料も法定表示もカード会社側に載るため、割賦販売法の重い義務を自前で抱える必要がありません。実装は、分割払いを有効化し、カード入力後に利用可能プランを取得して選ばせ、選択プランを確定リクエストに渡し、結果をWebhookで受ける、という標準的な流れで済みます。まずこの構成で公開し、要件が育ってから作り込むのが工数を抑える進め方です。具体的な実装パターンはStripeとは？決済プラットフォームの仕組み・手数料・実装パターンで確認できます。

受託開発で設計を固めるべき複雑な分割払い要件と外注が向く局面

逆に、次の要件が絡むと、初期の設計品質がその後の法対応と回収率を大きく決めるため、決済設計の経験がある体制で固める価値が出ます。加盟店自身が割賦債権を持つ自社割賦や、無利息分割を集客の武器にして手数料を加盟店が負担する構成、BNPL・後払いサービスとの連携、基幹システムや会計・債権管理との回収データ連携、複数の決済手段と分割条件を出し分ける決済画面の設計などです。これらは、割賦販売法に基づく表示・与信義務の遵守、貸倒れを見込んだ回収フロー、返品・途中解約時の分割残債の扱いといった、実装だけでなく法務と業務が密に絡む領域になり、後から作り替えると二重請求や表示不備のリスクが高くなります。こうした複雑な分割払いの実装は決済・サブスクリプションシステムの受託開発で設計から相談でき、まずイシュア分割の標準機能で走り出しつつ、自社割賦やBNPL連携といった難所だけ外部の設計を挟む進め方も現実的です。

分割払いAPIでよくある質問｜仕組み・費用・実装の疑問に回答

分割払いAPIの実装検討でよく挙がる質問に、仕組み・費用・実装の観点から簡潔に答えます。

分割払いを提供すると加盟店は分割で入金されるのですか？

イシュア分割（オンアス分割）であれば、加盟店は分割ではなく全額を一括で受け取ります。顧客のカード発行会社が分割の与信と手数料を引き受け、加盟店には通常の一括カード決済と同じ形で入金されるためです。分割手数料（利息）は顧客がカード会社へ支払う関係で、加盟店の入金額には影響しません。加盟店が分割で回収するのは、自社割賦のように加盟店が割賦債権を持つ方式を選んだ場合です。

分割払いAPIの実装で加盟店に手数料はかかりますか？

イシュア分割では、分割払いを受け付けること自体に対する追加手数料は原則かかりません。分割の利息は顧客とカード会社の間で処理されます。ただし、通常のカード決済手数料は発生し、無利息分割のように手数料を加盟店が負担する形の設計を採る場合は加盟店側のコストになります。費用構造は採用する方式と契約で変わるため、決済代行の料金条件を確認してください。

分割払いはどのカードブランドや回数でも使えますか？

いいえ、ブランドごとに対応が異なります。一例として、VisaやMastercardは分割・リボ・ボーナスに広く対応し回数の上限も大きい一方、JCBは分割回数の上限が小さめ、American Expressは分割払いに非対応、といった差があります。加えて通貨や発行国という条件も前提です。対応範囲は決済サービスやブランドの規約で変わるため、利用可能な分割プランをカードごとに取得して提示する実装にし、固定回数を決め打ちしないのが安全です。

分割払いを提供すると割賦販売法の対応が必要になりますか？

これは方式次第です。支払期間2ヶ月以上かつ3回以上の分割払いは割賦販売法の規制対象になりますが、イシュア分割では表示義務や与信審査といった義務を主にカード発行会社が負うため、加盟店の負担は軽くなります。加盟店自身が割賦債権を持つ自社割賦を選ぶと、支払総額・手数料の表示や支払可能見込額の調査などを加盟店側が引き受けることになります。法対応の重さを避けたい場合はイシュア分割が現実的です。

分割払いAPIの実装で本人認証や決済代行は必要ですか？

EC決済で分割払いを扱う場合も、通常のカード決済と同様に本人認証（3Dセキュア2.0）を通す設計が求められます。また、カード番号を自社サーバーに保持するとPCI DSSへの対応負担が大きいため、決済代行にカードを預けてトークンで参照し、分割の情報を決済リクエストに載せて発行する構成が現実的です。分割払いも各回は与信取得と売上確定の流れに乗るので、決済代行の分割払いAPIを使うことで、これらの処理と法対応をまとめて任せられます。

関連記事

• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：分割払いを含むカード決済の具体的な実装パターンとAPIの使い方を開発視点で確認できます。
• 3Dセキュア2.0（EMV 3-Dセキュア）とは？仕組み・認証フローとEC決済への実装を開発視点で解説：分割払いを含むEC決済で必要になる本人認証の仕組みと実装を詳しく確認できます。
• オーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンを開発視点で解説：分割払いの各回で走る与信取得から売上確定までの内部処理を確認できます。
• 決済システムとは？仕組み・種類と、決済代行との接続方式・自社構築の判断軸を解説：分割払いを含む決済システム全体の種類・接続方式・自社構築の判断軸を整理できます。