Skip to main content
Payout の承認は、Payout の作成と処理の送信の間に手動の確認の工程を追加する機能です。加盟店アカウントでこの機能が有効な場合、API からでも Merchant Portal からでも、作成されたすべての Payout は In Review に入り、権限を持つメンバーが承認または却下するまで待機します。このページでは、確認の流れ、待機中の残高の扱い、判断できるユーザー、監査のために記録される内容を解説します。
Payout の承認は既定では無効です。無効な場合、Payout はPayout の管理で説明している従来どおりの流れで処理され、承認のメールも送信されません。

​
Payout の承認の流れ

1

Payout が作成される

チームのメンバーが Merchant Portal で Payout を作成する、または連携している仕組みが Payout API で作成します。
2

Payout が In Review に入る

Payout は処理へ送られません。その金額はただちに available の残高から outgoing の残高へ移り、判断が下されるまで資金が確保されます。
3

Hello Clever が承認者へメールを送る

承認のメールがアカウントの Admin へ送られ、Finance のロールを持つすべてのユーザーが CC に入ります。メールには対象の Payout を開く Review Payout のリンクが含まれます。
4

承認者が Payout を確認する

承認者は Merchant Portal で Payout を開き、内容を確認して、承認または却下します。
5

判断が反映される

承認すると Payout は Pending に移り、通常の処理の流れへ引き渡されます。却下すると Rejected に移り、処理されることはありません。

​
Payout の承認を有効にする

この機能は Hello Clever が加盟店アカウントごとに制御するため、Merchant Portal に切り替えの設定はありません。有効化または無効化をご希望の場合は、Hello Clever のサポートへお問い合わせください。
Payout の承認を有効にすると、Portal で作成した Payout だけでなく、API で作成した Payout の挙動も変わります。承認されるまで何も処理へ送られないため、機能を有効にする前に、承認の権限を持つ担当者が確認待ちの Payout を見られる体制になっているか確かめてください。

​
確認の流れで使われるステータス

Rejected と Failed は異なる結果です。Rejected は、送金される前にチームの担当者が Payout を見送ったことを意味します。Failed は、処理は行われたものの送金が完了しなかったことを意味します。Payout が失敗する理由を参照してください。

​
残高の扱い

確認の工程では資金を使える状態のままにせず確保するため、承認された Payout が二重に使われた残高に突き当たることはありません。 available、incoming、outgoing の関係については、残高の管理を参照してください。

​
承認のメール

Payout が確認待ちに入ると、Hello Clever はアカウントの Admin へメールを送り、Finance のロールを持つすべてのユーザーを CC に入れます。件名に金額と受取人が示されるため、承認者はメールを開かずに優先度を判断できます。 メールには次の内容が含まれます。
  • 支払いの内訳：取引金額、手数料、正味の金額。
  • 受取人の情報：使用した Payout の手段に応じた項目。
  • 詳細：Payout ID、Balance ID、External ID、手段、作成日、作成者。
  • Merchant Portal で該当の Payout を開く Review Payout のボタン。
Review Payout のリンクは Merchant Portal の認証を必要とします。メールだけで承認することはできません。リンクは対象の Payout を開くもので、判断は必ず Portal で行います。メールを転送しても承認の権限は渡りません。

​
Payout の確認

承認のメールから Payout を開くか、Payouts のテーブルで In Review のステータスに絞り込んで探します。確認の画面には、判断の前に確かめられるよう記録の全体が表示されます。

​
承認する

Approve を選択します。Payout は Pending に移り、通常の処理の流れへ一度だけ送られます。それ以降は、リトライや失敗時の扱いを含めて、他の Payout と同じように動きます。

​
却下する

Reject を選択します。理由は任意で追加できますが、監査記録とあわせて保存されるため、後から他の担当者が判断の背景を知る必要がある場合には入力しておく価値があります。Payout は Rejected に移り、処理へ送られることはありません。
どちらの判断も取り消せません。却下した Payout を後から承認することはできず、承認した Payout をこの画面から引き戻すこともできません。承認済みの Payout を止めるには、Payout の管理で説明しているキャンセルの方法を使ってください。

​
承認または却下できるユーザー

作成者と承認者の分離は Portal 側で担保されるため、1人のユーザーが自分だけで Payout を作成して送金まで進めることはできません。Admin が1人だけで Finance のユーザーがいないチームでは、そのユーザーは Portal で自ら作成した Payout を承認できません。機能を有効にする前に、2人目の承認者を招待してください。ユーザーの招待を参照してください。

​
監査記録

確認の工程を通ったすべての Payout について、判断の記録が残ります。
  • Payout を作成したユーザー。
  • 結果（承認または却下）。
  • 判断したユーザー。
  • 判断の日時。
  • 却下の理由（入力されている場合）。
この記録は Payout とともに保持されるため、消込や監査の際に承認の経緯を示す証跡として使えます。

​
API で作成した Payout

Payout の承認によって、送信する API のリクエストが変わることはありません。連携している仕組みはこれまでどおり Payout を作成し、レスポンスも同じように返ります。変わるのはその後です。Payout は処理されずに保留され、Portal で承認者が操作するまで何も動きません。 連携では次の点を考慮してください。
  • 遅延を見込む：Payout の作成から処理までの間隔は、確認にかかる時間だけ空きます。作成された Payout を送金済みとして扱わないでください。
  • 却下に対応する：Payout は一度も処理されないまま Rejected で終わることがあります。これは通常の結果であり、リクエストの誤りではありません。
  • External ID を活用する：External ID は承認のメールと確認の画面に表示されるため、承認者が自社の記録と Payout を照合する最短の手がかりになります。
エンドポイントそのものについては、多通貨 Payout APIを参照してください。