支払い方法
支払い方法は年々多様化が進んでいる。ショッピングする顧客にとっては、自分に合った便利な支払方法が増えるわけだが、バックオフィスにとっては入金確認業務や支払金額変更時の業務が増えるので、バックオフィスの業務を以下に減らすことが出来るかが重要になる。
A.クレジットカード
- クレジットカード決済を提供する決済事業者は複数社あり、決済事業者の選択は、多くの場合料率(注文金額に対する手数料)で決まることが多い。それ以外の要素だと機能的なもので決まることもある。
- よく聞く決済事業者としては(GMO、Veritrans、SoftBankPayment、Paygent、BlueGate)などがある。
PCIDSS認証と非通過対応
- クレカ登録については2018年3月より、PCI DSS を保持していないデータセンターでのクレカ情報保持が禁じられており、PCI DSS の認証を受けるか、自社ECサーバー上でクレジットカードを通過させない非通過対応が必要となる。
- PCI DSS(参考リンクあり) の認証を受けるには、内部運用業務のルール統一と大幅な見直し、高額なコストがかかることが一般的なので、クレジットカードの非通過対応を行う方が一般的である。
- 非通過対応には２種類あり、APIを利用したトークン型の決済を利用するか、外部サイトに遷移する対タイプの決済を利用する。
クレジットカードの不正利用
- クレジットカードの不正利用も増えており、ECサイト運営者を悩ませている。
- クジレットカードの不正利用に関しては、加盟店(ECサイト運営側)が被害額を負担するケースが多い。
- 3Dセキュア形式を採用して、認証を強化することもできるが、カート離脱の原因となるケースが多く、あまり普及していない。
B.代引き決済
- 商品を渡した際に配達員がその代金を回収する方法。
- 代引き手数料が一般的には必要。
C.銀行振込
- 銀行振込は銀行に入金があったかを確認する必要がある。
- 口座に入金された情報をもとに、注文と目検で紐づける形が一般的。
仮想口座
- 仮想口座を使うと、入金と口座が１：１で紐づくので、API経由などで自動で入金処理することが可能。
- 仮想口座の場合は、番号が使いまわしとなっている。
D.後払い(NP、ニッセン、GMO、クロネコヤマト)
- 後から配送先の住所に請求書が送られてきて、コンビニや銀行振込で支払う形になる。ZOZOTOWNだと「ツケ払い」と呼ばれる。
- 与信の方法としてリアルタイム与信(カートから後払いの業者にAPIで通信して与信を確認)と受注後にCSVにリスト抽出して事業者に確認する方法がある。
- 出荷時に売上情報を連携して、後払い業者に請求書を発行してもらう形となる。
E.キャリア決済
- 携帯のキャリアから決済する方法(月々の料金として請求される)。
- クレカを持っていない層、少額課金に有効。
- クレジットカードの決済事業者が提供するAPIを利用して、追加実装するケースが一般的。
F.Amazonペイ
- Amazonの支払い情報を利用して決済することが出来る。導入後10-20％のユーザーが利用するテナントも多く支払い方法として効果が高い。
- 同期型と非同期型があるが、同期型の方が実装がシンプルなためこちらの方が推奨されているようだ。
- 大きなメリットの一つとしては、配送先をAmazonのものから利用することによってマーケットプレイス保証が付く。
G.ペイジー
- 税金の支払いなどで利用されている方法で、金額をセットした「納付番号」を発番し、そちらに振り込む形の形式となる。
- カート時点での処理はなく、在庫引当時に「納付番号」を発行する。
- 顧客が納付番号をもとに銀行から納付すると通知が来るので、その情報を反映する。
H.LINEペイ
- クレジットカードの決済事業者が提供するAPIを利用して、追加実装するケースが一般的。
I.楽天ペイ
- クレジットカードの決済事業者が提供するAPIを利用して、追加実装するケースが一般的。
J.Paypal
- クレジットカードの決済事業者が提供するAPIを利用して、追加実装するケースが一般的。
K.Appleペイ
- クレジットカードの決済事業者が提供するAPIを利用して、追加実装するケースが一般的。
ワークフローが必要な決済
- 受注生産や予約商品などEC上で購入したとしても実際の決済確定タイミング発送時になる場合は、与信の情報を取っておく必要がある。クレジットカードの情報はシステム上保持せず、決済プロバイダー上に保存しておくのが一般的である。決済確定まで３か月空いてしまう予約商品など場合によっては期限が切れてしまうので、保存した与信情報を適宜更新する。