KOMOJUとは？国内決済手段の対応範囲と実装方式・選び分けを開発視点で解説

KOMOJUは、コンビニ決済30万円・キャリア決済10万円・銀行振込は上限なしという国内特有の支払い上限を1つの契約でまとめて扱えるマルチチャネル決済プラットフォームです。提供元は2026年3月5日に株式会社DEGICAから株式会社KOMOJUへ商号を変更しました。旧社名で書かれた解説記事は、この時点で事実が古い。この記事では対応決済手段の実像、3つの実装方式、コンビニ決済や銀行振込で向き合う非同期な状態遷移とWebhookの受け方、料率が非公開であることを踏まえた選び分けまでを実装者の判断粒度で整理します。

まとめ｜KOMOJU採用の判断軸と実装で詰まる箇所

KOMOJUを選ぶ理由は手数料ではありません。コンビニ・銀行振込・ペイジー・キャリア決済・Paidyといったカード以外の国内手段を1契約で束ね、韓国のToss、オランダのiDEAL、中国のAlipayまで同じAPIで扱える点にあります。料率は公式サイトに掲載されておらず、料金ページはログインが必須。見積は個別問い合わせでしか取れません。

実装で詰まるのは2箇所です。1つはauthorizedとcapturedの取り違え。コンビニ決済では支払い番号の発行時点がauthorized、入金時点がcapturedで、混同すると未入金の注文を出荷します。もう1つはWebhookの受け口。X-Komoju-SignatureのHMAC検証とX-KOMOJU-IDEMPOTENCYによる再送耐性がないまま本番へ出すと、最大25回・約25日のリトライで注文が二重に確定します。

実装方式はPCI DSSの適用範囲をどこまで自社に引き込むかで選びます。まずホストページ、カート内で完結させたいならホストフィールド、独自フローが要るときだけ直接API。この順で検討すれば過剰な実装を避けられます。

KOMOJUの提供主体・対応決済手段の範囲と国内決済ごとの上限額

提供主体と対応範囲から位置づけを確定させます。決済代行そのものの仕組みや自社構築との比較は決済システムの仕組みと決済代行との接続方式を整理した記事で扱っているため、ここではKOMOJU固有の事実に絞ります。

2026年3月5日の商号変更で株式会社DEGICAが株式会社KOMOJUへ

KOMOJUは2016年に始まった決済プラットフォームで、提供元は長く株式会社DEGICAでした。2026年3月5日付でこの法人が株式会社KOMOJUへ商号を変更し、サービス名と社名が一致しました。公式サイトの表記も切り替わっています。

実装への影響はありませんが、契約書・請求書・特定商取引法に基づく表記・取引先マスタでは事業者名が変わります。DEGICA名義で契約済みなら、フッタや決済画面の説明文に旧社名が残っていないかの確認作業が発生。解説記事の多くが「株式会社DEGICAが提供」のままなので、稟議資料を外部記事から引き写すと事実誤認になります。公式サイトは導入実績2万社以上、対応決済手段65以上と示します（2026年9月3日時点）。

国内決済の上限額はコンビニ30万円・キャリア決済10万円が境界

国内手段は上限額の設計が手段ごとにばらつきます。公式の対応決済方法一覧（ページ更新日2026年8月7日）に載る主要な上限は次の通りで、高単価商材では選べる手段が絞られます。

この表が示すのは対応手段の多さではありません。上限を超える金額の注文で、その手段を決済画面に出してはいけないという実装要件です。カート合計に応じて手段を出し分けるロジックは自社側で持ちます。30万円超の商材でコンビニ決済のボタンを残せば、顧客は決済直前で弾かれます。

海外決済はiDEAL・Alipay・Tossなど地域別の手段を1契約で

越境ECでは守備範囲が国内に留まりません。韓国はTossとPAYCO、キャリア決済に加えCulture VoucherやHappy Moneyまで揃います。欧州はオランダのiDEAL、ベルギーのBancontact、ドイツのGiropay、ポーランドのBLIKとPrzelewy24。中国はAlipay・WeChat Pay・UnionPay、東南アジアはOVOやFPX、インドはUPIに対応します。

ただし方式ごとの制約が付きます。インドネシアのDOKU WalletとOVOはHosted Page APIからのみ利用でき、ホストフィールドや直接APIでは扱えません。通貨も手段別に固定され、WeChat PayはUSDとEUR、AlipayはUSD・EUR・JPYという形で決まっています。全手段が全方式で使える前提でフロントを組むと、方式別の分岐を後から足す手戻りが出ます。

ホストページ・ホストフィールド・直接APIの3方式とPCI DSS負担

実装方式は3つで、選択基準は工数ではなくカード情報が自社サーバを通るかどうかです。公式ドキュメントも直接APIについて「PCI-DSSの負担がかかる可能性あり」と明示します。

ホストページ方式はsessions作成とreturn_urlの2点で完結する構成

最短で組めるのがホストページ方式です。サーバ側で決済セッションを作り、顧客をKOMOJU側の決済画面へ送るだけで、カード番号は自社を通りません。

1. シークレットキーで認証し、amount・currency・return_url を指定して POST /api/v1/sessions
2. レスポンスの session_id を注文レコードへ保存し、session_url へリダイレクト
3. 決済後、顧客は return_url に session_id を付けた形で戻る
4. GET /api/v1/sessions/{session_id} で status（pending・cancelled・complete）と payment を確認

注意点は4番目です。リダイレクトは顧客のブラウザ操作に依存するため、タブを閉じられれば戻ってきません。公式ドキュメントもリダイレクト失敗の対策としてWebhookの併用を推奨します。戻りURLだけで注文を確定させる実装は、入金済み注文の取りこぼしになります。

ホストフィールドはiframeで入力欄を借りPCI負担を抑える方式

カート画面から離脱させたくない場合はホストフィールドを選びます。https://multipay.komoju.com/fields.js をモジュールとして読み込み、<komoju-fields>要素に session-id と publishable-key を渡すと、KOMOJU側のセキュアなiframeが入力欄を描画します。支払い手段の選択UIが必要なら<komoju-picker>を併置。

顧客の入力はiframe内でトークン化され、自社のフロントもサーバもカード番号に触れません。この設計思想はトークナイゼーションの仕組みと実装方式を整理した記事で扱った通りです。fields.submit()を呼ぶとトークンIDが返り、以降はそのIDをバックエンドへ渡して決済を確定させます。publishable-keyはトークン作成とセッションの支払いに用途が限られ、公式ドキュメントも公開して差し支えないと説明します。

直接APIは自由度と引き換えにPCI DSSの適用範囲が広がる選択

直接APIはhttps://komoju.com/api/v1/へRESTfulなJSONで呼び出す方式です。認証はHTTP Basic認証で、シークレットキーをユーザー名に置き、パスワードは空にします。マーチャントアカウントにはLIVEとTESTの鍵ペアが別々に発行されます。

この方式ではカード番号・有効期限・セキュリティコードを自社サーバで受け取るため、PCI DSSの適用範囲が一気に広がります。判断はシンプル。カード情報を自社で受け取る積極的な理由がないなら直接APIは選びません。一方でカード以外の手段だけなら事情が変わります。コンビニ決済や銀行振込は payment_details に type と顧客の氏名・メール・電話番号を渡す形で、カード番号を扱わずに組めます。カード決済のみホストフィールド、非同期の国内手段は直接APIという併用が落としどころ。

コンビニ決済と銀行振込の非同期な状態遷移とWebhook実装の要点

ここがKOMOJU実装の中核です。決済が即時完了しない手段では、注文状態を自社で持ち続ける設計が前提になります。

authorizedとcapturedの差＝非同期決済の入金待ち状態

paymentリソースはstatusで状態を表します。公式定義ではauthorizedが顧客の認証完了で、コンビニ決済や銀行振込では現金の支払いを待つ段階を指します。capturedが支払い完了。pendingはモバイルアプリ決済などで顧客の追加操作を待つ状態です。

コンビニ決済では、顧客がフォームを送信した直後にauthorizedが返ります。この時点で受注メールを送るのは構いませんが、在庫の確定引き当てや出荷指示をここに置いてはいけません。銀行振込はpayment_detailsのレスポンスに bank_name・account_number・account_name・payment_deadline などが入り、振込先と期限を注文詳細画面へ転記できます。コンビニ決済では instructions_url が返り、支払い方法の案内へ顧客を誘導できます。期限切れ注文を自動キャンセル扱いにするバッチも設計対象。

payment.capturedの署名検証に使うX-Komoju-Signature

入金の確定を知る手段はWebhookです。支払い系だけでも送信されるイベントは次の範囲に及びます。

• payment.authorized（入金待ちの成立）／payment.captured（出荷判断の起点）
• payment.expired／payment.cancelled／payment.failed／payment.marked.as.fraud
• payment.refund.created／payment.refunded（返金の作成と完了）
• subscription系5種（定期課金）／settlement.created（出金）／customer系3種／ping

受け口ではX-Komoju-Signatureヘッダの検証を最初に行います。値はシークレットトークンを鍵にリクエストボディから計算したSHA-256のHMACです。検証前にペイロードのJSONを信頼してはいけません。ペイロードは type・object・data・created_at の構造で、object は常に event。実装の型自体は決済Webhookの主要イベントと署名検証・冪等な注文確定を扱った記事と同じで、KOMOJU固有なのはヘッダ名とイベント名の体系だけです。

X-KOMOJU-IDEMPOTENCYで24時間の冪等性と409の切り分け

決済作成側の再送対策には冪等キーを使います。X-KOMOJU-IDEMPOTENCYヘッダにリクエストごとに一意な文字列を入れる仕組みで、対象はPOSTのみ。キーはランダムなUUIDが推奨され、最大100 ASCII文字までという制限があります。

同じキーと同じボディで再送すると、操作は再実行されず初回と同じレスポンスが返ります。押さえておくべき挙動が1つ。初回リクエストがレスポンスを生成し切る前に再送すると、HTTP 409が返ります。クライアント側のリトライは、409を重複エラーではなく初回処理の進行中と解釈し、間隔を置いて再照会する実装にします。キーの有効期間は初回使用から最大24時間で、その後は再利用可能。注文IDをそのまま流用すると翌日以降の再注文で意図しない一致が起こり得るため、日時やUUIDを組み合わせます。

最大25回・約25日間のリトライ設計と再送耐性のある注文確定処理

受信側はKOMOJUのリトライ仕様に耐える必要があります。配信は最大25回、間隔は段階的に延び、最終的には約100時間おき。最初の送信から25日後が最後のリトライになります。

この仕様の意味は、同じpayment.capturedが25日後に届き得るということです。受信処理を「イベントを受けたら注文を確定して在庫を減らす」と書くと、25日越しの再送で在庫が二重に減ります。data内の支払いIDと配信を識別するX-Komoju-IDヘッダを保存し、処理済みなら200を返して何もしない形にします。処理途中で例外が出た場合は5xxを返し、リトライに任せる。エラーは message・code・param の3フィールドで返り、code には not_found・unprocessable_entity・invalid_token・not_refundable などが入るため、ログにcodeを残すと切り分けが速くなります。

Stripe・PAY.JP・Squareとの機能差と国内EC向けの選び分け

KOMOJUの比較は他社と同じ土俵では組めません。料率が公開されていないためです。この制約を前提にした比較の作り方から入ります。

手数料が非公開のKOMOJUと料率公開のStripeの比較の作り方

料金ページはログインが必須で、未ログインではサインイン画面へリダイレクトされます（2026年9月3日時点）。公開されているのは初期費用と月額費用がかからないという点だけ。対してStripeは日本のカード決済を3.6%、コンビニ決済を3.6%かつ最低120円、銀行振込などを1.5%と公開しています。PAY.JPも2.59%からという形で料率を出しており、違いはPAY.JPの手数料と実装フローを整理した記事で扱いました。

自社の想定流通額と手段別の構成比を先に確定させ、公開料率のあるサービスで基準額を試算する。その数値を持ってKOMOJUへ見積を依頼し、差額が手段の広さに見合うかを判定します。順序が逆だと、提示された料率が高いのか安いのか判断できません。

国内の非同期決済の網羅性で選ぶ場面と、海外カード主体で選ぶ場面

選び分けの軸は流通の中身です。国内向けで、コンビニ決済・銀行振込・ペイジー・キャリア決済・Paidy・プリペイド系まで幅広く並べたい商材ならKOMOJUが有利になります。ゲーム内通貨やデジタルコンテンツのようにカードを持たない層が一定割合を占めるなら、WebMoneyやBitCashを1契約で扱えることが決済完了率に直結します。Stripe側でコンビニ決済・銀行振込を実装する場合の手順はStripeの決済方法を有効化する手順：カード・コンビニ決済・銀行振込の実装とWebhookで解説しています。

逆にカード決済が9割を占め、海外法人からの入金が中心なら、料率が公開され課金・請求の周辺機能が厚いプラットフォームの方が総額で見合います。開発体制の観点も加わります。プラグイン対応のカート（Shopify・WooCommerce・Magento・ebisumartなど）ならほぼ設定作業で済む。対象外のフルスクラッチなら、方式選択から状態管理まで前述の設計が全部必要になります。

KOMOJUを採用する条件と、見送るべき案件の具体的な線引き

ここまでの事実から、採用判断を条件付きで言い切ります。両論を並べても発注も実装も進まないため、線を引きます。

KOMOJUを採用してよい条件は国内非同期決済とプラグイン前提

採用してよいのは次の条件を満たす案件です。第一に、カード以外の国内手段が売上構成に実際に入っていること。念のため用意するではなく、数%以上の実需があるかで判断します。第二に、単価が30万円以下に収まっていること。上限を超える商材が主力なら、コンビニ決済を出せず選定理由の半分が消えます。第三に、対応カートを使っているか、非同期決済の状態管理を自前で設計できる体制があること。

この3つが揃う案件では、複数の決済代行と個別契約する構成より運用が軽くなります。締結する契約が1本になり、入金と突合の口も1本になるためです。実装負荷はカート次第で大きく変わるため、フルスクラッチのECや業務システムへ決済を組み込む場合は、方式選択と状態設計を含めて決済・サブスクリプションシステム開発として設計段階からご相談いただくと、後戻りの少ない構成に寄せられます。

見送るべきはマルチ通貨の与信管理と細かな料率交渉が必要な案件

逆に、次の場合は見送ります。1つ目は、料率の1桁下まで詰めた原価計算が意思決定の前提になっている案件。料率が非公開のため、比較検討の初期段階で数値を並べられません。稟議のスケジュールが短い案件では、見積待ちがそのまま遅延要因になります。

2つ目は、複数通貨を同一アカウントで一元管理し、通貨別の与信枠や再オーソリを細かく制御したい案件です。KOMOJUは手段ごとに受け付ける通貨が固定され、WeChat PayはUSDとEUR、韓国のTossはKRWという形で分かれます。通貨横断の与信管理を前提にした設計とは噛み合いません。

3つ目は、決済画面を自社で完全に作り込む要件があり、PCI DSSの準拠体制を持たない組織です。直接APIなら要件は満たせますが、適用範囲が広がった状態で準拠を維持できないなら、監査上の負債を抱えただけになります。この場合はホストフィールドの制約内でUIを詰める方が実務的。

よくある質問

KOMOJUの導入検討と実装で確認されることの多い論点をまとめます。

KOMOJUの初期費用と月額費用はいくらですか？

公式サイトでは初期費用と月額費用がかからないと示されています（2026年9月3日時点）。かかるのは決済手数料のみという体系です。ただし料率は非公開のため、総コストは見積を取らないと確定しません。入金については、公式サイトのKOMOJUターミナルの説明として最短翌営業日への言及があります。振込サイクルと振込手数料の条件は契約内容に依存するため、見積時に手段別の料率とあわせて確認してください。

KOMOJUの決済手数料は公開されていますか？

公開されていません。料金ページは未ログインだとサインイン画面へリダイレクトされ、料率を参照できない状態です。比較記事の料率は取材時点の個別条件の可能性があり、自社の試算根拠にはしません。手段別の料率・返金時の手数料・流通額に応じた条件を問い合わせで確定させ、公開料率のある他サービスの試算値と並べて判定します。

コンビニ決済や銀行振込は返金できますか？

APIには返金の操作があり、Webhookにも payment.refund.created と payment.refunded が定義されています。一方でエラーコードには not_refundable（この支払いは払い戻しができません）があり、すべての支払いが一律に返金可能ではないと分かります。手段別の可否と手数料の扱いは公式FAQと契約条件で確認してください。実装側では返金不可のケースを想定し、銀行振込での返金運用などの代替を業務フローに用意しておくと安全です。

Shopify以外のカートでもKOMOJUは使えますか？

使えます。公式サイトが挙げるプラグイン対応はShopify・Wix・WooCommerce・Magento・ebisumart・Salesforce Commerce Cloud・Shopline・Cafe24です。これ以外のカートやフルスクラッチでは、ホストページ・ホストフィールド・直接APIのいずれかで自前実装します。工数差は大きく、プラグインなら設定作業で終わるところが、自前実装では非同期決済の状態管理とWebhookの受け口の設計が必要になります。

テスト環境で本番と同じ決済手段を試せますか？

マーチャントアカウントにはLIVEとTESTの鍵ペアが別々に発行されるため、シークレットキーを差し替えればテスト環境の決済を実行できます。ただしコンビニ決済や銀行振込のように実際の入金を伴う手段は、本番と同じ経路での挙動確認に制約が出ます。入金確定後の分岐は、ダッシュボードからの手動再送信やpingイベントで受信処理側を検証する形が現実的。状態遷移の検証はTEST側で通し切ってから本番へ移します。

関連記事

• 決済システムとは？仕組み・種類と、決済代行との接続方式・自社構築の判断軸を解説：決済代行か自社構築かという上位の判断を扱った記事です。
• 決済Webhookとは？仕組み・主要イベントと署名検証・冪等な注文確定の実装を開発視点で解説：署名検証と冪等な注文確定の一般形です。
• トークナイゼーションとは？決済のカード情報を守る仕組みと暗号化との違い・実装方式を開発視点で解説：ホストフィールドがPCI DSS負担を抑える前提の仕組みです。
• PAY.JPとは？国産決済APIの手数料・実装フロー・Stripeとの選び分けを開発視点で解説：見積評価の基準額を作る国産決済APIです。
• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：カード決済主体の構成での比較対象です。