アフィリエイターへの支払いフローの作り方

01 / DIRECT ANSWER

振込ボタンだけでは、支払いフローは完成しない

支払いは振込作業だけではありません。成果を確定し、支払い対象をつくり、手数料と支払予定を本人にも見えるようにして、完了後に明細を残すまでが一つのフローです。

アフィリエイターへの支払いは、注文が入ったら金額を送るだけの作業ではありません。決済済み注文を成果候補として受け取り、返品・取消・帰属を確認し、ストアが承認して確定報酬に変えます。確定報酬が最低支払額と締め日の条件を満たしたら、同じ人の対象成果を一つの支払いへまとめ、口座・原資・手数料を確認して振込します。最後に本人へ予定と完了を通知し、明細と会計記録を残します。

どこか一つが別の表計算やメールになると、金額の正本が分かれます。特に承認済みと支払い済みを同じ状態にすると、ストアは払ったつもり、アフィリエイターは入金待ちという食い違いが起きます。システム上の支払対象作成、決済事業者への送金依頼、銀行着金は別の出来事です。それぞれの状態、日時、失敗理由を確認できるようにします。

PARELでは確定報酬が五千円に達した後の次回振込日を支払対象とし、五千円未満は失効させずに繰り越す設計です。自動振込またはストア直接振込を選べますが、実際の提供条件、決済事業者の本人確認、手数料はプログラムと時点で変わるため、募集ページ・ポータル・アプリ内の最新表示を正本にします。

02 / PAYMENT STATES

成果発生から銀行着金まで、九つの状態を分ける

支払いトラブルを減らす最初の方法は、状態を細かく分けることです。注文発生、決済確認、保留、承認、確定報酬、しきい値待ち、支払い準備、処理中、支払い済みを区別します。返金、取消、失敗、保留解除、再送も履歴として残します。紹介者にすべての内部用語を見せる必要はありませんが、自分の報酬がどこにあり、次に何を待っているかを示します。

03 / PAYOUT POLICY

開始前に決める十項目

報酬率だけを規約へ書いても、支払い運用はできません。締め日、振込日、最低支払額、繰越、手数料、本人確認、税・書類、返金後、退会後、失敗時を決めます。ストア向けの内部手順と、アフィリエイター向けの説明を同じルールから作り、数字や日付を変えたときに両方を更新します。

1. 01

   1. 報酬の確定条件

   支払い済み注文、対象商品、帰属、保留期間、返金・取消、不正確認を明記します。

2. 02

   2. 計算対象

   割引後商品小計、税、送料、ギフトカード、部分返金をどう扱うか計算例を示します。

3. 03

   3. 締め日

   毎月末など、どの期間の承認済み成果を同じ支払いへまとめるか決めます。

4. 04

   4. 支払日

   翌月何日、休日の場合、決済事業者・銀行の処理日数を含む予定を示します。

5. 05

   5. 最低支払額

   PARELは確定報酬5,000円を基準とし、未満は失効せず繰り越します。

6. 06

   6. 手数料

   PAREL利用料、決済事業者、振込手数料を分け、ストアとアフィリエイターのどちらが負担するか示します。

7. 07

   7. 受取口座・本人確認

   いつ、どの事業者画面で登録し、ストアとPARELが何を保存するか説明します。

8. 08

   8. 返金・取消

   承認前、承認後・送金前、送金後で、再計算・相殺・個別対応を分けます。

9. 09

   9. 退会・停止

   未払い確定報酬、最低額未満、口座未登録、規約違反時の扱いを決めます。

10. 10

    10. 失敗・問い合わせ

    口座エラー、原資不足、通信失敗、銀行休日、未着時の確認期限と窓口を決めます。

04 / MINIMUM PAYOUT

最低支払額5,000円と繰越の考え方

最低支払額は、少額の振込を繰り返して手数料が受取額を圧迫することを避け、ストアの月次処理をまとめるために使います。低すぎると五百円の報酬に対して振込関連費が大きくなり、高すぎると活動しても長く受け取れない不満が生まれます。PARELでは、確定報酬が五千円に達した後の次回振込日を対象とし、未満は消さずに繰り越します。

紹介者には、保留中、確定済み、支払対象、最低額までの残り、次回予定を別に見せます。たとえば確定三千二百円なら『あと千八百円で支払対象。金額は繰越中』と表示します。ストアがキャンペーン終了や退会時に最低額未満をどう扱うか、例外支払いをするかも規約で決めます。しきい値はシステム上の条件であり、確定報酬を没収する理由にしません。

05 / TWO METHODS

自動振込とストア直接振込を比較する

自動振込は、ストアが成果を承認し、支払条件を満たした報酬をPARELと決済事業者の処理で送る方式です。紹介者は決済事業者の画面で本人確認と受取口座を登録し、ストアが口座番号全体を管理しない構成にできます。ストアの個別振込作業を減らせますが、決済事業者のアカウント・送金・振込等の費用、KYC、利用可能地域、原資管理、失敗対応が必要です。

ストア直接振込は、PARELで支払対象と明細を確定し、ストアが自社の銀行や会計フローで本人へ振り込みます。決済事業者の自動送金費用を避けられる場合がありますが、口座情報の取得・暗号化・権限・CSV・振込・消込・証跡をストアが担います。PARELでCSVを出力しただけでは振込完了ではなく、銀行実行後に支払い済みへ更新します。

06 / FUNDING

自動振込では、報酬原資と利用料を混同しない

アフィリエイター報酬の原資は、ストアの商品売上から自動的にPARELへ移ると決めつけないことが大切です。契約した資金フローに従い、ストアが必要額を入金し、PARELが入金確認後に支払対象へ割り当てる方式などがあります。PARELの利用料、紹介者報酬、決済事業者手数料は別の金額です。ストアの残高画面に、利用可能、予約中、処理中、支払済みを分けます。

原資不足のときは自動送金を開始せず、対象額、必要追加額、入金方法、確認予定を表示します。同じ支払いを繰り返し作らず、冪等なIDで一回だけ処理します。『自動振込残高を追加』の決済後に白画面や数値だけが表示されるのは正しい完了体験ではありません。PARELへ戻り、入金受付・確認中・利用可能のどれかを明示し、ブラウザ再読込でも状態を確認できる必要があります。

07 / PAYOUT ACCOUNT

口座登録は、本人が安全な画面で行い状態だけを共有する

紹介者の口座番号や本人確認書類を、ストア担当者がメール・チャット・表計算で集めない方が安全です。自動振込ではStripe Connect等の決済事業者のHTTPS画面へ本人を案内し、KYCと外部口座登録を行います。PAREL側には、受取設定の完了、銀行名、口座番号下四桁、通貨など必要最小限の表示情報を読み込み、口座番号全体は保存しません。

口座変更時は本人認証を行い、変更後一定期間はCSV出力・送金を保留するなど、不正変更対策を検討します。ストア直接振込で口座情報が必要な場合も、暗号化、アクセス権、ダウンロード履歴、有効期限、変更通知を設けます。CSVを端末へ無期限に残さず、誰がいつ出力したかを監査できるようにします。

1. 01

   本人確認

   決済事業者が要求する氏名・生年月日・住所・本人確認書類等は、その安全な画面で本人が入力します。

2. 02

   ポータル表示

   登録済み銀行名、下四桁、通貨、受取設定完了、要対応を表示し、全口座番号や書類は見せません。

3. 03

   変更

   本人認証、変更通知、一定期間の保留、旧情報の無効化を行い、振込直前の差し替えを確認します。

4. 04

   ストアの権限

   口座情報の閲覧・CSV出力は必要な経理担当だけに絞り、履歴と削除ルールを設けます。

08 / PAYMENT RUN

月次の支払い実行を七段階で確認する

同じ月に同じ紹介者へ複数回送金すると、手数料と明細が分かれます。成果承認は個別に行えても、支払いは締め日単位でアフィリエイターごとに集約するのが実務的です。自動承認期間が終わった成果だけを対象にし、月末に全選択・一括承認した後、次回支払日のバッチへまとめます。

1. 01

   1. 対象期間を締める

   注文月ではなく、承認済み・支払対象になった期間を明確にします。期限前の保留は次回へ回します。

2. 02

   2. アフィリエイター別に集約

   対象成果、返金、報酬、繰越、最低支払額を一人ごとに確認します。

3. 03

   3. 口座・方式を確認

   自動・直接の選択、口座登録、KYC、通貨、要対応、変更保留を確認します。

4. 04

   4. 原資と手数料を確認

   報酬総額、利用可能残高、予約、送金関連費、受取見込を分けて表示します。

5. 05

   5. 支払いを確定

   件数・金額・対象者を再表示し、一意な支払いIDを作成して二重実行を防ぎます。

6. 06

   6. 結果を受け取る

   成功、処理中、失敗をプロバイダーや銀行結果で更新し、HTTP応答だけで完了にしません。

7. 07

   7. 通知と明細

   本人へ受取額、手数料、予定・完了日、対象成果を示し、ストアの会計用CSV・履歴を残します。

09 / FAILURE RECOVERY

送金失敗と再送を、安全に扱う

失敗の原因には、口座未登録、KYC未完了、無効口座、名義不一致、原資不足、上限、決済事業者の一時障害、銀行休業日があります。エラー文をそのまま紹介者へ見せず、誰が何をすればよいかへ変換します。口座修正は本人、原資追加はストア、一時障害はPARELの再処理など担当を分けます。

再送ボタンは通常の支払いボタンと区別し、『自動送信に失敗・保留した利用料や送金を再送する復旧操作』と注釈します。同じプロバイダーIDや処理開始時刻がある支払いを新規作成せず、結果照会を先に行います。二回押し、画面再読込、Webhook再送、定時処理の重複でも一回だけ送金されることをテストします。

10 / STATEMENT

支払明細と通知に入れる情報

紹介者向け明細には、対象期間、支払いID、成果件数、注文日またはマスクした注文番号、対象商品小計、報酬率・固定額、返金調整、確定報酬、繰越、手数料、受取額、振込日、方式、状態を含めます。購入者の氏名、住所、電話、メールなど不要な個人情報は載せません。

ストアの会計用には、支払主体、取引ID、決済事業者IDまたは銀行振込ID、手数料区分、税込・税抜の扱い、証跡へのリンクを追加できます。請求書・支払調書・源泉徴収等の要否は相手の属性、契約、金額、業務内容で変わるため、税理士等へ確認します。PARELの画面だけで税務判断が完結するとは案内しません。

11 / IMPLEMENTATION WORKBOOK

「アフィリエイターへの支払いフローの作り方」を自社へ落とし込む実践ワーク

ここまでの内容を読んだだけで終わらせず、自社の現在地へ置き換えます。まず、アフィリエイターの支払いフローを作りたいという目的について、対象商品、対象者、担当者、開始日、完了条件を一枚に書いてください。完了条件は「設定画面へ入力した」ではなく、管理者とアフィリエイターが同じ条件を確認でき、テスト注文または具体的な運用例で期待どおりになった状態とします。分からない項目は空欄のまま公開せず、誰がいつ決めるかを置きます。

次に、現在使っているフォーム、表計算、メール、チャット、銀行、レポートを並べ、情報がどこで転記されているかを確認します。成果確定の条件を決める、支払い対象を月次でまとめる、完了後の明細・連絡を用意するという三つの作業で、同じ名前・金額・状態を二回以上入力している場所があれば、誤りと担当者依存が起きやすい部分です。すぐ全自動にするのではなく、正本を一つ決め、他の場所は通知または参照へ変えます。

さらに、アフィリエイター本人のスマートフォンで同じ流れを試します。招待・応募からログインし、条件を読み、リンクや素材を受け取り、成果・報酬・支払いを確認するまでに、担当者へ質問しなければ進めない箇所を記録します。その質問はヘルプへ追加するだけでなく、疑問が生まれた画面の見出し、注釈、ボタン文言、次の行動を改善する材料にします。自己解決できる画面と、人が判断する相談を分けることが、人数が増えても関係を粗くしない運用につながります。

最後に、初月で変える項目を一つだけ選びます。条件、対象者、商品、報酬、素材、計測、承認、支払いを同時に変えると、何が結果へ影響したか分かりません。基準となる期間を保存し、一つの変更後に同じ指標を確認します。売上だけでなく、開始率、活動率、承認までの日数、未対応件数、問い合わせ、返金、紹介者の継続意向を見て、続ける・直す・やめるを一文ずつ残してください。

12 / TEAM QUESTIONS

導入・見直し会議で確認する八つの問い

会議では機能名の読み上げではなく、誰がどの状態を見て何を判断するかを確認します。次の問いへ具体的な担当、期限、画面、数字で答えられない項目は、公開後に止まりやすい場所です。すべてを一度に決める必要はありませんが、金額、権利、個人情報、支払いに関する未決定は参加者へ案内する前に解消します。

1. 01

   この施策で、誰のどの行動を変えるのか

   アフィリエイターの支払いフローを作りたいという言葉を、対象者、商品、行動、期限が入った一文へ変えます。認知、応募、クリック、購入、再購入、店頭送客のどれを主目的にするか決め、補助目的を増やしすぎません。

   記録するもの：目的の一文、主KPI、対象期間
2. 02

   参加前に、本人が判断できる条件はそろっているか

   支払いフローは成果承認、最低支払額、支払対象の集約、原資、口座、振込、通知、明細、失敗時の復旧までを含むという考え方を、募集ページ、規約、ポータルで同じ言葉にします。報酬、義務、対象、期限、承認、返金、支払いなど、参加の意思に関わる条件を承認後まで隠しません。

   記録するもの：公開条件、適用日、条件の正本URL
3. 03

   ストアの担当者が休んでも、次の作業が分かるか

   成果発生から銀行着金まで、九つの状態を分けるについて、担当、代理、期限、未対応アラート、完了条件を決めます。個人の受信箱や記憶だけに置かず、管理画面で現在地と履歴を確認できるようにします。

   記録するもの：担当・代理担当、確認頻度、期限超過時の対応
4. 04

   アフィリエイターは、自分の状態を自分で確認できるか

   PARELでは確定報酬5,000円以上を支払対象とし、未満は消えずに次回へ繰り越すという情報が、メールを探さなくてもスマートフォンのポータルで分かるかを試します。リンク、素材、成果、報酬、予定、口座、明細など、本人に関わる状態をストアだけが持たないようにします。

   記録するもの：本人テストの画面、迷った箇所、質問
5. 05

   例外が起きたとき、誰が止めて誰が再開するか

   自動振込とストア直接振込を比較するに関係する返金、取消、誤帰属、重複、不正疑い、口座・原資・通信の失敗を想定します。自動処理が失敗したときに二重実行せず、確認・修正・再送の担当と証跡を残します。

   記録するもの：例外一覧、停止条件、再開条件
6. 06

   費用と利益を、同じ注文で説明できるか

   商品売上、購入者割引、アフィリエイター報酬、PAREL等の利用料、決済・振込費、原価、送料、返金を分けます。率だけでなく実額の例を作り、ストアの粗利と紹介者の受取見込が同時に分かるようにします。

   記録するもの：通常注文とキャンペーン注文の試算
7. 07

   法令・規約・個人情報の責任者は決まっているか

   PR表記、商品表現、素材利用、応募情報、本人確認、口座、購入者データを誰が確認するか決めます。アプリの初期値を法的判断の代わりにせず、商材や対象地域に応じて公式情報と専門家を確認します。

   記録するもの：確認者、参照した公式資料、改定日
8. 08

   三十日後に、何を見て継続を決めるか

   自動振込とストア直接振込は、手数料・口座情報・実務負担・証跡を比較し、プログラムごとに選ぶという方針に沿い、最初から大人数へ広げません。開始率、活動率、クリック、承認済み成果、粗利、返金、未対応、問い合わせを同じ期間で見て、一項目だけ改善します。

   記録するもの：基準値、変更内容、次回確認日

13 / EVIDENCE & RECORDS

公開・変更・月次運用で残す記録

運用の記録は、問題が起きたときだけ作るものではありません。条件を公開した日、誰が何を承認したか、紹介者へどう表示されたか、テストで何を確認したかを残すと、問い合わせへの回答、担当者の引継ぎ、条件変更、障害対応を早くできます。個人情報や秘密情報をスクリーンショットへ無制限に残さず、必要な項目をマスクし、アクセス権と保存期間を決めます。

1. 01

   公開前の基準

   対象商品、対象者、条件、担当、成果確定の条件を決める、完了条件を保存します。画面を作った事実ではなく、テストした入力・期待結果・実結果を記録します。

   残すもの：条件バージョン、テストケース、確認者
2. 02

   参加者への表示

   支払い対象を月次でまとめるという内容が、募集ページ、承認案内、ポータル、規約で一致するか確認します。変更時は旧条件と新条件の適用日を分けます。

   残すもの：公開URL、表示文、通知日
3. 03

   実行した操作

   開始前に決める十項目に関する登録、承認、変更、出力、送信は、操作者、日時、対象、件数、結果を残します。ボタンを押したことと外部処理の成功を同じにしません。

   残すもの：操作ID、対象件数、外部結果ID
4. 04

   金額と状態

   発生、保留、確定、支払対象、処理中、完了、返金・取消を区別し、同じ注文・成果・支払いIDで追えるようにします。合計だけでなく構成を確認できる状態にします。

   残すもの：商品小計、率、報酬、調整、手数料
5. 05

   例外と復旧

   アフィリエイト報酬は注文後すぐ振り込まれますか？への回答を、個別メールだけで終わらせません。原因、影響、停止、修正、再開、本人への説明、再発防止を一つの記録にします。

   残すもの：事象、原因、対応、再確認結果
6. 06

   月次の判断

   完了後の明細・連絡を用意することまで確認し、継続、改善、中止を一文ずつ残します。売上だけでなく、参加者と担当者が迷った回数、未対応日数、例外率も見ます。

   残すもの：月次KPI、判断理由、翌月の一変更

14 / FINAL CHECK

このページを閉じる前の最終チェック

最後に、次の項目へ「はい」と答えられるか確認してください。一つでも未決定なら、公開を止める必要がある項目か、限定テストの中で確認できる項目かを分けます。金額・支払い・権利・個人情報に関する項目は推測で進めず、表示と運用を一致させます。

1. 01

   目的と対象を一文で説明できる

   アフィリエイターの支払いフローを作りたいという目的が、誰、商品、行動、期間まで具体化され、関係者が同じ言葉で説明できます。

2. 02

   三つの基本作業に担当と期限がある

   成果確定の条件を決める、支払い対象を月次でまとめる、完了後の明細・連絡を用意するについて、担当、代理、期限、完了条件、次回確認日が決まっています。

3. 03

   ストアと本人の表示が一致する

   支払いフローは成果承認、最低支払額、支払対象の集約、原資、口座、振込、通知、明細、失敗時の復旧までを含むという重要条件が、管理画面だけでなく募集・ポータル・明細にも同じ意味で表示されます。

4. 04

   通常・例外・失敗をテストした

   通常の成功だけでなく、取消・返金・重複・期限・再読込・再送など、このテーマで起きる例外をテストしています。

5. 05

   金額の内訳を実例で確認した

   商品小計、割引、報酬、利用料、手数料、返金、受取額を同じ注文で照合し、総額だけに頼っていません。

6. 06

   本人がスマートフォンで完了できる

   アフィリエイターがメールを探し回らず、ログイン、条件確認、リンク・素材、成果・報酬、必要な手続きを完了できます。

7. 07

   個人情報を必要以上に持たない

   応募、審査、発送、本人確認、口座、購入者情報を段階ごとに分け、利用目的・権限・保存・削除を決めています。

8. 08

   外部処理の成功まで確認できる

   メール送信、Shopify課金、決済、振込などはHTTP応答やボタン押下だけでなく、相手側状態・通知・明細まで確認できます。

9. 09

   三十日後の見直し日がある

   初月の基準値、変更する一項目、見る指標、判断者、見直し日を決め、設定して終わりにしていません。

10. 10

    PARELを含む候補を実画面で比較した

    機能表だけでなく、一商品・数名・一件のテストを管理者とアフィリエイターの両方で行い、残る手作業と迷いを確認しています。

15 / WITH PAREL

PARELで、成果承認から支払い明細までをつなげる

PARELでは、紹介成果を保留・承認し、確定報酬が五千円に達したアフィリエイターを次回支払対象へまとめます。五千円未満は消えずに繰り越され、本人のポータルで残額と状態を確認できます。ストアのダッシュボードには未承認件数、紹介売上、報酬、支払済み、利用料を分けて表示し、必要な画面へ直接進めます。

支払い方式は、Stripe Connect等を通じるPAREL自動振込と、ストアが銀行で実行する直接振込をプログラムに合わせて選べます。自動振込では本人が決済事業者の画面でKYCと口座登録を行い、PARELには銀行名・下四桁・状態など必要最小限だけを表示します。直接振込では支払対象CSV、銀行実行、支払い済み更新、証跡を一続きで管理します。

本番利用前には、テストアフィリエイターで口座登録、五千円の成果、承認、原資、送金、銀行着金、通知、明細、返金後の扱いを確認してください。PAREL自身も自動振込を正式ローンチする前に、決済事業者承認、KYC、規約・資金フロー、実送金を含む検証を完了する方針です。最新の提供状態はアプリ内表示を確認してください。