出店型ECプラットフォームの開発事例

本件のお客様は、複数の事業者がそれぞれ自分のネットショップを開設し、運営できる「出店型のECプラットフォーム」を企画された事業者様です。

本案件では、ショップの開設・商品登録から、購入者による注文・オンライン決済、発送処理、そして各ショップへの売上精算・振込までを、ひとつのサービス内で完結できるECプラットフォームを新規開発しました。決済代行サービスとAPIで連携し、購入者からの集金と、手数料を差し引いた各ショップへの振込を、システム上で自動的に処理できるようにしています。

本記事では、開発前の課題、提案したアプローチ、実装した主な機能、そして開発で苦労した点を整理してご紹介します。

今回のポイントは、ショップオーナー・購入者・運営者という立場の異なる三者が同じ基盤を使いながら、出店した各ショップが「独立した自分のお店」として見えるようにしつつ、注文から決済・精算・振込までのお金の流れを人手を介さずに自動で回せる仕組みを実現したことです。

開発前の課題

自社サイトでもモールでもない、第三の選択肢

ネットショップを始めたい事業者にとって、自社サイトを一から構築するのは費用も期間もかかります。かといって大手のモールに出店すると、今度は自社ブランドが並びの中に埋もれてしまう。

そこで求められたのが、プラットフォームとしては一つの仕組みでありながら、出店した各ショップは「自分だけのサイト」として見えるという、両取りの形でした。

ショップごとに独自のドメインで公開でき、デザインも切り替えられる。しかし裏側は共通のシステムで運用する。この前提が、設計全体を大きく左右しました。

立場の異なる三者が、同じサービスの中に同居する

また、このサービスには商品を売りたい「ショップオーナー」、商品を買いたい「購入者」、両者の間で発生するお金と品質を管理したい「運営者」という、立場の異なる三者が関わります。

それぞれ必要な情報も操作もまったく異なるため、同じサービスの中に、立場ごとの画面・権限・通知を用意する必要がありました。

他社の売上金を、1円のズレもなく扱う

お金の流れも課題でした。購入者からの入金をいったんプラットフォーム側で受け取り、手数料を差し引いて各ショップへ振り込む、という流れになります。

出店数が数十・数百と増えていけば、集金・集計・振込を人手で回すのは現実的ではありません。しかも扱うのは他社の売上金であり、1円のズレも許されません。

日本のECならではの細かな要件

加えて、税抜表示と税込表示、標準税率と軽減税率が混在する消費税、都道府県ごとに異なる送料、離島への追加送料、納品書の発行、特定商取引法に基づく表記など、日本のECならではの細かな要件にも対応する必要がありました。

課題	具体的に必要だったこと
一つの仕組みで「別々のお店」に見せる	ショップごとの独自ドメインでの公開と、デザインの切り替え
立場の異なる三者が同居する	ショップオーナー・購入者・運営者それぞれの画面・権限・通知の作り分け
他社の売上金を扱う	集金・集計・振込の自動化と、1円のズレも出さない精算
日本のECならではの要件	消費税の表示と税率、都道府県別・離島の送料、納品書、特定商取引法に基づく表記

ご提案・開発アプローチ

4つの領域に切り分けて設計する

まず、システム全体を「ショップ管理」「ショップの店頭」「購入者マイページ」「運営管理」という4つの領域にはっきり分けて設計しました。

同じサービスでありながら、立場ごとに見える画面と権限を明確に切り分け、それぞれのログイン状態は互いに干渉しないよう独立して管理しています。

「独立した自分のお店に見せる」という要件には、ショップごとのサブドメインと独自ドメインの両対応と、デザインテンプレートの切り替えで応えました。

決済代行サービスとの連携を軸に、お金の流れを組み立てる

お金の流れは、決済代行サービスとの連携を軸に組み立てました。注文時にまずカード枠を確保し、発送のタイミングで売上を確定します。

締め日ごとに売上を自動集計し、手数料を差し引いた金額を各ショップへ自動で振り込む、という一連の流れをシステム側で処理します。振込に失敗した場合には、再振込を行える仕組みも用意しました。

日本のEC実務に合わせて、自前で組み立てる

消費税や送料の計算は、汎用的な仕組みに寄せるのではなく日本のECの実務に合わせて自前で組み立てる方針としました。

また、機能をすべての店舗に一律で提供するのではなく、料金プランと「プラグイン」による拡張という形にし、必要な店舗だけが必要な機能を追加できるようにしています。

開発前の課題	今回のアプローチ
一つの仕組みで別々のお店に見せたい	4つの領域に分けて設計し、サブドメイン／独自ドメインとデザインテンプレートで切り替える
立場ごとに必要な画面・権限が違う	立場ごとに画面と権限を分け、ログイン状態も独立して管理する
集金・集計・振込を人手で回せない	決済代行サービスと連携し、締め日ごとの自動集計・自動振込・再振込を用意する
日本のECならではの細かな要件	消費税や送料の計算を、実務に合わせて自前で組み立てる
店舗ごとに必要な機能が違う	料金プランと「プラグイン」による機能拡張で対応する

実装した主な機能

実装した機能は多岐にわたります。ここではショップの開設から、注文・決済・発送、そして売上の集計・振込までの流れに沿って、3つに分けて整理します。

ショップの開設と店舗運営

• ショップオーナー・購入者・運営者それぞれの登録・ログイン・管理画面
• ショップ開設と、サブドメイン／独自ドメインでの公開
• 商品登録・3階層のカテゴリー管理・商品画像管理
• デザインテンプレートの切り替えと、プラグインによる機能拡張
• 料金プランの契約・変更（サブスクリプション課金）

注文から決済・発送まで

• 商品検索、お気に入り、カート、ゲスト購入を含む注文手続き
• オンライン決済と、キャンセル時の返金処理
• 受注確認・発送処理・納品書PDF発行
• 送料設定（送料無料条件・都道府県別・離島追加送料）と税率設定

売上の集計・振込と、運営者による管理

• 売上の自動集計と、手数料を差し引いた各ショップへの自動振込・再振込
• 運営者による全ショップ・全購入者の管理と、手数料率の設定
• 顧客管理と、通知メールテンプレートのカスタマイズ
• 注文確認・発送完了・キャンセルなど、各種通知メールの自動配信

開発で苦労した点

ひとつのシステムを、店ごとに別サイトとして見せる

今回もっとも設計に影響したのが、ショップごとにサブドメインや独自ドメインで公開できるという要件です。通常のWebシステムは「ひとつの住所（ドメイン）で動く」ことを前提に作られているため、店舗ごとに住所が変わる構造は、標準的なやり方の外側にあります。

特に厄介だったのが、サイト内のリンクの生成です。同じ「商品ページへのリンク」でも、どの店の、どの入り口から見ているかによって出力すべきURLが変わります。

ここを場当たり的に書くと独自ドメインで見ている購入者が、リンクを押した瞬間に共通ドメイン側へ飛ばされてしまうといった事故が起きます。そこで、店舗の状態に応じて正しいURLを組み立てる専用の仕組みを用意し、実装者が個々に判断しなくても崩れない形にしました。

あわせて、有効期限切れで店舗が閲覧できなくなることのないよう、SSL証明書の更新も自動で回るようにしています。

「預かって、締めて、配る」お金の流れを止めない

購入者から先に決済し、後から各ショップへ振り込む流れは、途中で失敗すると「購入者からはお金をいただいたのに、ショップへ渡せていない」という事態を招きます。外部の決済サービスと連携する以上、通信の失敗や一時的な不調は避けられません。

そのため、締め日ごとに振込データを作成し、実際の送金は日次の処理で実行する二段構えとし、失敗した分は記録として残して再振込できるようにしました。

注文時に確保したカード枠にも期限があるため、期限切れになる前に自動で売上を確定させる処理も定期的に走らせています。お金に関わる処理は、失敗することを前提に、あとから追跡・やり直しができる形にしておく——これは最初に固めた方針です。

外部サービスの「期限」に、運用を合わせ込む

とりわけ設計が難しかったのが、キャンセルと返金です。決済代行サービスの返金機能には利用可能な期間の上限があり、それを過ぎると「返金したくても返金できない」状態になります。

ところが実際の運用では、ショップが長期間発送しないまま注文が放置され、気づいたときには期限間際、というケースが起こり得ます。

そこで、時間軸に沿った多段の仕組みを用意しました。一定期間発送されていない注文にはショップへお知らせを送り、それでも動きがなければ、期限に余裕を残した段階でシステム側が自動的にキャンセルと返金を行います。

さらに取りこぼしに備え、期限が迫った注文については決済サービスを介さず、次回の振込額から差し引いて精算する方式へ自動的に切り替えるようにしています。

注文の状態	システム側の動き
一定期間、発送されていない	ショップへお知らせを送る
お知らせ後も動きがない	期限に余裕を残した段階で、自動的にキャンセルと返金を行う
返金の期限が迫っている	決済サービスを介さず、次回の振込額から差し引いて精算する方式へ切り替える

外部サービスの制約は変えられないため、こちらの運用スケジュールをその制約の内側に収まるよう逆算して設計するという考え方で組み立てました。

まとめ

出店型ECプラットフォームの開発事例では、共通の仕組みの上で各ショップを独立したお店として見せながら、注文から決済・精算・振込までのお金の流れを自動で回す仕組みを整えたことがポイントです。

複数の立場が関わるサービスや、外部の決済サービスと連携してお金を扱う開発では、正常に進む場合だけを考えていては動きません。

通信に失敗したとき、担当者が対応を忘れたとき、外部サービスの期限が迫ったとき——そうした「うまくいかないとき」に、システムがどう検知し、どうやり直せるようにするか。そこまで含めて設計することを重視しました。

同様に、ECサイト・出店型プラットフォーム・決済や精算を伴うサービスの開発をご検討の際は、お気軽にご相談ください。