EC-CUBE4 管理・運用マニュアル / 4.1.0 版

EC-CUBE4 管理機能

設定>店舗設定>支払方法設定

支払方法設定の概要

ここでは、EC-CUBE4の支払方法設定機能について説明します。

支払方法設定は、ユーザーが商品を注文する際に、どのような方法で支払いをするかを選択できるようにする為の設定です。

支払方法設定画面

支払方法設定画面

デフォルトでは、予め下記の支払い方法が登録されています。

  • 郵便振替
  • 現金書留
  • 銀行振込
  • 代金引換

それぞれの編集画面で手数料などの設定ができます。

新しい支払い方法を登録する場合は、「支払方法を新規入力」ボタンをクリックすると空欄の入力項目が表示されます。

ワンポイント

今時、現金書留での支払いは、あまりないかもしれませんね。

クレジット決済については、クレジット決済のモジュールやプラグインを導入し有効化すると、支払方法設定の一覧に表示されるか、または配送方法設定の画面内で設定できるようになります。

支払方法は別メニューの「配送方法設定」側で、どの配送方法に対しどの支払い方法を利用可能とするかを設定する項目があります。

例えば、配送方法をヤマト宅急便の場合はクレジット決済のみ、配送方法がゆうパックの場合は代引きのみ、というような設定を、支払方法設定と配送方法設定の両方で設定します。

ただし、複数の支払方法や配送方法の組み合わせがある場合、EC-CUBE4のデフォルト機能のままでは、矛盾が起こりますので100%運用に合致した配送料や手数料の課金を行いたい場合は、カスタマイズが必須です。

例えば、メール便で配送できる商品と宅急便でなければ配送できない商品を同時に注文された場合など、1回の注文で選択できる配送方法と支払方法の選択は1種類ずつが基本ですので、それらの組み合わせで注文された場合は総お支払額を的確に算出する事はできません。(カスタマイズが必要です。)

代引き手数料の課金設定 参考例

支払方法編集画面

デフォルトで登録されている代金引換は、手数料=0円、利用条件=0円~無制限となっていますが、通常、代金引換の手数料は、商品代金に応じて代金引換手数料が異なります。

例として、「サンプル運輸」の下記、代金引換手数料の場合の登録をしてみましょう。

  • 商品代金1~9,999円/手数料300円(税込)
  • 商品代金10,000~29,999円/手数料400円(税込)
  • 商品代金30,000~99,999円/手数料600円(税込)
  • 商品代金100,000~300,000円/手数料1,000円(税込)

支払方法編集画面

代金引換の「編集」をクリックして編集画面を開きます。

画像の様に必要項目を入力後、登録します。

設定項目

  • 支払方法・・・・・支払方法は分かりやすい名前で設定しましょう。後々一覧で編集先が分かりやすくなります。例では「代金引換」としています。
  • 手数料・・・・・・ここで登録する支払方法をユーザーが選択注文した場合、課金する手数料を設定します。例では「300」円(税込)としています。
  • 利用条件・・・・・手数料を課金する条件を設定します。ここでの「利用条件」とは、注文された商品の合計金額を指しています。例では「1~9,999円」としています。
  • ロゴ画像・・・・・配送業者のロゴマークをアップロード登録する事が出来ます。フロント側の画面で配送業者を視覚的にユーザーが選択しやすくなります。

ワンポイント

設定例の動作結果は、ユーザーが商品注文の際、支払方法の選択で「代金引換」を選択し、注文商品の合計金額が1~9,999円であった場合、お支払合計金額にはここで設定した代金引換の手数料「300円」が加算されるようになります。


支払方法編集画面

デフォルトで登録されていた代金引換を編集して、

条件1~9,999円=手数料300円

※利用条件の金額設定は、購入商品代金と配送料の合計金額に対する手数料の課金金額の設定です。

で編集登録し、他の3つの条件で代金引換の支払い方法を新規登録します。

  • 10,000円~29,000円=手数料400円
  • 30,000円~99,999円=手数料600円
  • 100,00円~300,000円=手数料1000円

画像は登録後、一覧画面上で見安いように並び替えた状態です。

※この並び順は、ユーザーが選択する画面上での表示並び順となります。

ワンポイント

支払方法の登録名は同じ名称で登録しない場合、選択画面上で別の支払方法として表示されてしまうので、同じ「代金引換」という名称にします。

代金引換でもそれぞれ別の配送業者となる場合は「代金引換(ゆうパック)」「代金引換(宅急便)」のそれぞれについて、各条件分の設定を追加していきます。

「代金引換(ゆうパック)」「代金引換(宅急便)」というように分けた名称で登録することで、ユーザーは希望の配送業者の代引きを選択できるようになります。

※支払い方法を表示させるためには、配送方法設定メニュー側で配送業者毎の設定で登録済の支払方法を紐付けておく必要があります。

フロント決済画面の表示例

支払方法フロント画面

実際のフロント画面(ユーザー画面)では下記のような表示となります。

「商品合計+送料」の合計が10,000~29,999円の範囲で、支払方法を代金引換を選択しているので、手数料として400円が課金された状態となっています。

※設定編集画面でロゴマークをアップロードしたので、支払方法の選択項目欄にロゴマーク画像が表示されています。

ワンポイント

ECサイトでの主な支払方法は下記の様なものがあります。

  • 銀行振込・・・・・・ショップ側で準備した口座へ前金で振り込んで貰う時に登録しておきます。格安の手数料で振込が可能なネットバングなどもあり、特にネット通販のヘビーユーザーに対しては準備が必須ですね。
  • 郵便振込・・・・・・ゆうちょ銀行の口座ですので、地方の山間部や離島など一般銀行の支店が無いような地域でも郵便局があれば利用できるというメリットもありますので、一つは準備しておいた方が良いかもしれません。ネットバンキングにも対応しています。
  • 代金引換・・・・・・代金引換も購入者が安心出来る点で人気があり、ECサイトでは必須となる支払方法でしょう。安心以外にも、週末までに商品を受け取りたいので直ぐに発送して欲しい!というユーザーが利用するケースもかなり多くなっています。
  • クレジット決済※・・・振込の手間が無く、銀行の営業時間外でも決済できるので、直ぐに商品が欲しい!(注文を確定させたい)と思うユーザーにとっては、非常に便利な支払方法です。
  • コンビニ決済※・・・・各社サービスによって色々なものがありますが、基本的には購入者は画面上で注文後に発行される番号を控え、最寄りのコンビニ内端末からレシートを発行し公共料金の支払同様に現金で代金を支払うような方法です。
  • 仮想通貨・・・・ビットコインなど仮想通貨による支払いなども徐々に普及しつつあるようです。

クレジット決済の導入について

クレジット決済やコンビニ決済を導入する場合、カード会社または決済代行サービスを行っている業者と直接契約を取り交わす必要があります。

申込後は決済サービス会社から審査を受ける必要があり、利用可能となるまでには申込から凡そ1~1.5カ月程度の審査期間がかかります。

※審査を受ける為に、取り扱い商材や実際のサイトを確認される可能性が高く、全くサイトが無い場合は審査を受けれない場合があるかもしれませんので、ECサイトを構築後にクレジット決済を導入するという順序でも良いかもしれません。

クレジット決済用の課金データ(商品情報や販売単価など)を決済会社システムと店舗ECサイトシステム間で送受信できるように接続部分の機能を追加する必要があります。

EC-CUBEには各決済用の接続モジュールやプラグインが多数配布されているので、その中から申し込む決済会社を選択するのが良いかもしれません。EC-CUBE用のモジュールやプラグインが無い決済会社を利用したい場合は、プラグインなどの開発が必要になりますが、オーソリ仕様の調査なども必要になりますので開発費用は高額になります。

クレジット情報非保持化の法改正について(2018/4月1日より法施行されました。)

消費者の保護の観点から、経産省主導による法改正で、非対面販売によるクレジット決済について、カード情報の保持、及びデータのサーバー通過が2018/4月以降、禁止されました。

2018/10月時点でECサイトにクレジット決済を導入されているサイトでは既に対応済だと思いますが、対応していないサイトはクレジット決済が出来ない状態となっていますので、「そんな事聞いたことが無い」というショップさんは一度確認されてみるのが良いと思います。

クレジット決済を導入しているつもりでも注文ユーザーは買い物が出来なくなっている可能性があります。

詳しくは、

EC-CUBEクレジット情報非保持化特設サイト

日本カード情報セキュリティ協議会サイト

をご参照ください。

SSL証明書の導入について

ECサイトにはクレジット情報のみならず、会員情報や注文時の住所情報など、個人情報を入力させるフォーム画面があり、安全の為には暗号化されたデータ通信を行う必要があります。

SSL証明書を取得導入済のサイトは、サイトのURLがhttpではなく、httpsでの暗号化されたWEBデータ通信となります。

また、現在はGoogle検索エンジンアルゴリズムにも、WEBサイトデータの通信にSSL暗号化通信を行っているか否かの判定が採用されていますので、SEOの面でも入力フォームのあるページのみでなく、静的WEBサイトについても常時SSL通信が必須という事になります。

GoogleChromeブラウザのアップデートで、より厳しい警告表示が出るようになっていますので、今般、WEBサイトの常時SSL化はスタンダードとなっています。

このSSL通信を行う為には、1ドメインに1対の証明書を取得しなければなりません。

概要ですが、SSL証明書はそのドメインの利用者(サイト管理者)の所在や所有を明確にすることで、特定の暗号鍵を発行してもらい、その鍵をサーバーに設置することで、httpsというアドレスから始まる独自ドメインでの送受信データが暗号化されるしくみになっています。

法人などで取得するJP属性ドメイン(.co.jp など)は、SSLの取得申請の際に、登記簿や印鑑登録証などの公的証明書の提出が必要になる場合があります。

価格の差は、証明会社自体の信頼度やデータ漏洩時などの保険(保証)金額、携帯端末などへの対応レベルなどにより様々です。

執筆協力パートナーご紹介

株式会社シロハチ

株式会社シロハチ

自由な発想で、お客様のご要望にレスポンス良くお答えいたします。深夜作業対応など、他社対応不可な部分などでもご相談ください。

PAGE TOP