国内PG・簡単決済 選定ガイド · 2026

決済会社を選ぶ場で最初に求める資料が手数料率表です。国内PGが標準料率を公開する場合もありますが、適用料率は契約や加盟店の条件によって変わることがあります。公開表と個別見積もりをそろえ、同じ条件で比較します。値を分ける条件はおおむね五つです。業種と取扱商品、月間の想定取引額と一件あたりの平均金額、受け付けたい決済手段の構成、精算周期をどれだけ前倒しするか、そして保証保険や担保をどう立てるかです。カードと口座振替、簡単決済、キャリア決済は原価構造が異なるため手段ごとに別の料率が付き、簡単決済の追加料金の有無も手段と契約ごとに確認する必要があります。したがって候補二社のカード料率だけを比べても、実際の負担を比べたことにはなりません。比較は自社の実際の取引構成を書き出してから始めます。直近三か月の注文を手段別の比率と一件あたりの金額に分け、その構成をそのまま候補各社に渡して見積もりを取れば、返ってきた二つの値は同じ条件の上にあります。まだ取引のないサービスなら、開始後六か月の想定構成を同じ形式で書いて渡します。料率のほかにも契約書に値が付く場所があります。加入金や年単位の利用料を置く会社があり、精算振込や適格請求書の発行、管理者アカウントの追加のように件別または月単位で付く項目が別に書かれることもあります。初年度の負担は料率一行だけでは計算できません。

手数料より資金計画を大きく揺らす軸が精算周期です。カード売上はカード会社から決済会社へ、決済会社から加盟店へと流れるため、口座に入金される日は決済日ではなく契約に書かれた周期が決めます。この周期は決済手段ごとに違います。入金が先に確認される仮想口座と、買取手続を経るカードが同じ日に精算されることはありません。周期を前倒しする条件を付けるとその分だけ料率が上がるので、この二つは一つの表で並べて見ます。在庫を先に仕入れて売る事業なら、料率の小数点より精算が数日早いほうが実際に残ります。保証金と保証保険も同じ軸にあります。決済会社は取消と返金、未配送の危険を加盟店に戻す手段を確保しようとするため、業種と取引規模に応じて担保設定や保証保険の加入を契約条件として求めます。前払いチャージや予約のように決済時点と商品の引き渡し時点が離れるサービスでは、この要求が強く付きます。精算保留はとくに条件が広く書かれる箇所です。係争が急増したり取消率が基準を超えたら一定比率を留保するという条項が入りますが、留保比率と解除条件が数字で書かれていなければ、繁忙期に資金が凍る経路になります。取引額が契約時の想定を超えたら料率と周期を再協議できるため、再交渉の時点も最初に決めておきます。契約書を受け取ったら、精算周期、精算保留の条件、担保の規模、解約時の残余代金の扱いという四行を先に探して読みます。

国内で実際に使われる手段は、クレジット・デビットカード、リアルタイム口座振替、仮想口座、簡単決済、キャリア決済、商品券ほどに分かれます。カカオペイやネイバーペイ、トスペイ、ペイコのような簡単決済は決済会社が仲介する形と事業者と直接契約する形の両方があり、どちらで接続するかが料率と精算周期を同時に変えます。サムスンペイやアップルペイのような端末と結び付いた手段は、アプリ環境と機器の条件が別に付きます。手段は料率だけでなく取消の規則が違います。カードは部分取消が一般的ですが、キャリア決済のように通信料金と一緒に請求される手段は請求締めを過ぎると取消の経路そのものが変わり、仮想口座の返金は顧客の口座番号を受け取って送金する手続きが必要です。商品券やポイントが混ざれば、部分返金でどの原資から戻すかも規則として決めておく必要があります。ですから手段の一覧は、マーケティングが望む順ではなく取消と返金が実際に回る順で書きます。現金性の決済を受け付ける通信販売なら、決済代金預託や消費者被害補償保険の要件が電子商取引法に関わるため、その項目も候補を絞る前に確認します。海外で発行されたカードを受け付けるかも同じ場で尋ねます。国内の決済会社が海外カードの承認に対応していても、表示通貨と精算通貨、発行会社の認証手続きが国内カードとは違う形で掛かるため、海外売上の比率があるサービスは検討を別に立てます。

着手時点では不要に見えても半年以内に必ず尋ねることになる機能が三つあります。一つ目は部分取消です。一つの注文に複数の商品が入る、あるいは配送が分かれるサービスでは、決済一件を分けて返す事態がすぐに起きます。決済会社と手段が部分取消をどこまで許すか、何回まで分けられるか、すでに精算が終わった取引はどう扱うかを契約前に尋ねます。二つ目は定期課金です。国内の自動決済は決済会社が発行した課金キーを使って加盟店側から再請求する形で、課金キーの発行は通常の決済とは別の審査項目です。サブスクリプションを後から付ける計画があるなら、最初の契約にこの項目を入れておくほうが審査を二度受けずに済みます。三つ目はエスクローです。決済と引き渡しの間が離れる取引では決済代金預託が要件になり、この機能が付くと購入確定と配送情報の連携という運用手順が新たに生まれます。三つとも後から付ければ注文状態モデルを開き直す作業になるので、いま不要でも対応可否だけは候補比較表に入れます。同じ表に通知の仕様も併せて書きます。決済結果をサーバーへ送る通知が失敗したとき決済会社が何回送り直すか、加盟店が取引状態を問い直す照会仕様があるか、承認後に確定していない取引をいつ自動取消するかは会社ごとに違い、その差がそのまま例外処理のコードになります。

連携方式は、決済会社の画面・ウィジェット・SDKが担う範囲と加盟店サーバーが担う範囲を分けて比較します。決済会社の画面を使いながら、サーバーから承認APIを呼ぶ構成もあります。承認APIを呼ぶというだけで、加盟店サーバーがカード情報の原文を扱うとは限りません。トークンとカード情報の経路、認証・承認・取消の担当を、その商品の連携文書で確認します。画面の変更範囲とセキュリティ要件、追加審査は、その構成に合わせて比較します。 アプリとウェブを同時に出すサービスは同じ決済会社でもSDKが分かれるため、工数を別に数えます。審査は開発とは別の時計で動きます。事業者登録証と通信販売業の届出、精算口座、実際のサービス画面が必要で、審査担当は商品ページと利用規約、返金規定、連絡先の表記まで見ます。業種制限もここで表に出ます。決済会社ごとに受け付けない業種があり、同じ業種でも取扱品目によって条件が付きます。ですから候補を絞る最初の通話で業種から伝え、審査書類の準備を開発着手と同じ週に始めます。開発者が見る条件も候補を分けます。テスト環境で失敗と取消、部分返金まで再現できるか、失敗コードが文書にすべて書かれているか、連携文書が最新のSDKと合っているかは着手初週に表れ、その差がそのまま日程に残ります。候補社の連携文書を契約前に開いてみることで、この軸はおおむね判定が付きます。

決済手段は多いほどよいという言い方は、開発と運用の費用を数えていない言い方です。手段が一つ増えると三つが付いてきます。開発では承認と取消、返金の経路が一組増え、失敗コードと通知仕様が違うため例外処理とテストも一緒に増えます。運用では問い合わせの種類が増え、障害時に確認する窓口がもう一つできます。精算では突合対象のファイルがもう一つ付き、手数料が付く時点と項目名が違うため規則を書き直します。ですから最初のリリースでは決済試行の大半を覆う手段だけを入れ、残りはデータが貯まってから足す順序が安全です。カードと簡単決済を一つか二つで始め、決済画面で離脱する地点と問い合わせで入ってくる要望を見たうえで、離脱が特定の手段の不在から来ていると分かった時点で追加します。追加を判断するときは、その手段が生む売上ではなく、その手段がなくて去った注文を数えます。ゲートウェイ層を先に置けばこの追加が注文コードではなくアダプター一つで終わるため、後の判断が軽くなります。決済会社を二社以上使うと決めたなら、障害時の窓口を契約前に決めます。受付の経路が電話か管理画面か、等級別の連絡体制が文書であるか、夜間と週末に人が受けるか、決済会社側の障害を加盟店へ先に知らせる経路があるかを尋ねます。窓口が二つになると問い合わせが来たときにどちら側の問題かを分ける作業が先に生まれるため、決済会社別の受付方法と判断順序を運用ランブックに書いておく準備まで選定段階で数えます。