2 5月, 2022

提供していない決済方法を業務で取り扱う際に気をつけること

ECプロダクトを扱っていると、銀行振込という決済方法には欠かせないものとなります。しかしながら、特定のターゲット層を除いて、高いコストがかかる銀行振込は通常は裏メニューとして実装されることが多いでしょう。今回は、このケースにおける課題と解決策について詳しくご説明いたします。事前に対策を講じておくことで、業務の硬直化やスケーリングへの影響を最小限に抑えることができるでしょう。

thumbnail

PROBLEM

銀行振込のみを通常の決済方法として提供している場合には、以下のような問題が生じることがあります。

人力でトランザクションを処理する必要があるため、予期せぬ支払いや二重決済が発生する可能性があります。
不整合処理に関わるCS担当者に権限が集中してしまい、運用上の制約が生じることがあります。

通常のケース

skinparam handwritten true

actor ユーザ as U
box プロダクト
    database "プロダクト\nアプリ" as D
    database "プロダクト\n決済" as N
end box
database 銀行 as B
actor "CS" as C
actor 配送 as L

group (1) 決済方法を銀行に変更
    U <-> C: |問い合わせ|\n決済方法を銀行に変更
    activate U
    activate C
    C -> D: |管理画面|\n決済方法を銀行振込にロック
    activate D
end

group (2) 支払い
    U -> B: 銀行振込
    deactivate U
    activate B
end

group (3) 決済完了
    C -> B: 振込確認
    deactivate B
    C <-> D: |管理画面|\n決済状況を銀行振込完了に変更
    deactivate C
end

group (4) 発送
    L <-> D: |管理画面|\n決済完了により指示に上がっているアイテムを発送
    deactivate D
end

「ユーザ」：もしも銀行振込に変更したいんだけど、できる？「CS」：（管理画面を通じて）了解しました。銀行振込を設定しますね。

不整合が起きるケース「銀行振込と通常決済が同時に実行」

skinparam handwritten true

actor ユーザ as U
box プロダクト
    database "プロダクト\nアプリ" as D
    database "プロダクト\n決済" as N
end box
database 銀行 as B
actor "CS" as C
actor 配送 as L

U <-> C: |問い合わせ|\n決済方法を銀行に変更\n* この時点ではCSとユーザ間の取り決めに過ぎない\n* トランザクションなし
activate U
activate C

group (1) 正常な支払い
    U -> B: 銀行振込
    activate B
end

group (2) 想定外の支払い
    U -> D: |アプリ|\n決済
    deactivate U
    activate D
    D <-> N: 決済
    activate N
end

group (3) 発送
    L <-> D: |管理画面|\n決済完了により指示に上がっているアイテムを発送
end

group (4) 決済確認
    C -> B: 振込確認
    deactivate B
end

group (5) 想定外の支払いを確認
    C <-> D: |管理画面|\n決済方法が変更できないことを確認
end

group (6) 不整合処理
    C -> D: |管理画面|\n請求情報の支払い方法の変更
    deactivate D

    C <-> N: 決済のキャンセル
    deactivate C
    deactivate N
end

「ユーザ」：（問い合わせをする）銀行振込に変更したいです。「CS」：（了承を得て）もちろん、銀行振込をお使いいただけますよ。

（ユーザが「銀行振込」を選択し、一方で「通常決済」も行われるシーン）

「ユーザ」：（アプリを通じて）支払い完了！「CS」：（困惑した表情で）えっ、銀行振込を選択してくれたはずなのに、通常決済も同時に行われている…？何が起きているのか調べないと。

SOLUTION

銀行振込の不整合を防ぐために、システム側に決済ロックを実装することが重要です。ただし、振込確認を人力で行っている場合には、銀行振込を表側に出すのは難しいかもしれません。そこで、問い合わせタイミングでロックできるよう、問い合わせ窓口を工夫する必要があるでしょう。プロダクトのUXにも関わる重要な課題ですが、根気よく取り組んでいくことが必要です。

skinparam handwritten true

actor ユーザ as U
box プロダクト
    database "プロダクト\nアプリ" as D
    database "プロダクト\n決済" as N
end box
database 銀行 as B
actor "CS" as C
actor 配送 as L

group (1) 決済方法を銀行に変更
    U -> D: |問い合わせ|\n決済方法を\n銀行に変更
    activate U
    activate D
    D -> D: 決済方法を\n銀行振込に\nロック
    D -> C: 問い合わせ
    activate C
    C --> U: 銀行振込方法の案内
end

group (2) 支払い
    U -> B: 銀行振込
    deactivate U
    activate B
end

group (3) 決済完了
    C -> B: 振込確認
    deactivate B
    C <-> D: |管理画面|\n決済状況を銀行振込完了に変更
    deactivate C
end

group (4) 発送
    L <-> D: |管理画面|\n決済完了により指示に上がっているアイテムを発送
    deactivate D
end

「ユーザ」：（問い合わせをする）銀行振込に変更したいです。「プロダクトアプリ」：（問い合わせを受け取りつつ）わかりました。銀行振込をロックしますね。

「CS」：（ユーザへ案内しながら）銀行振込の方法についてご案内いたします。

WRAPUP

ECプロダクトが成長し、決済方法が増えてくると業務処理が複雑化してきます。特に決済の適正性には細心の注意が必要であり、トランザクションの量に応じてリスクアセスメントを行い、適切な対応策を講じていくことが大切です。これにより、業務のスムーズな運営と顧客満足度の向上につなげることができるでしょう。