UC 7.3

Flow 5 - Routing & Execution: chọn Path A/B/C (Dots / Rippling) theo billing_country, current_level và trạng thái W-2, gửi lệnh trả tiền kèm idempotency key và xử lý kết quả

Field	Value
BA in Charge	Anh Hoang
Date Created	2026-10-10
Version	v1.3
Document References	Zapier Integration V7.pdf (§Flow 5 — Routing & Execution · §3.1 bảng `Users`) · RFQ_ Stack Trading Prop Tech V7.pdf (§3.4 Bonus Payouts — Dots) · QnA from clients — `QnA_STAGE5_PAYOUT_WITHDRAWAL.md` mục UC_7.3 (A-10, A-20…A-29, A-55, A-65, A-68, A-71, A-73, A-96, A-107, A-115) · Common Rules CR-08, CR-15.2

UC_7.3 — Flow 5: Routing & Execution

🇻🇳 Section này viết bằng tiếng Việt để BA review. Mọi ID, anchor, tên field/API và text hiển thị cho user giữ nguyên tiếng Anh.

1. Overview

Field	Content
ID	UC_7.3
Use Case	Flow 5: Routing & Execution
Description	UC này gửi tiền thưởng lên level cho trader, sau khi hồ sơ nhận tiền của trader đã được duyệt. Hệ thống chọn đường trả tiền phù hợp với trader: qua Dots cho trader là contractor, qua Rippling cho trader là nhân viên W-2 ở Mỹ, rồi gửi lệnh trả. Nếu lệnh trả bị lỗi thì hệ thống dừng lại và báo Operations xử lý.
Phạm vi	UC này chỉ chọn đường trả tiền và gửi lệnh sang Dots hoặc Rippling. Không gồm: kiểm tra hồ sơ và chốt số tiền (UC_7.2), ghi Immutable Ledger và QuickBooks (UC_7.4), mời đánh giá Trustpilot (UC_7.6).
Zapier Flow	Flow 5 (Payouts — Bonus), bước "Routing & Execution". Chạy sau UC_7.2, trước UC_7.4
Zapier Table	Không đọc Table nào, vì số tiền đã chốt ở UC_7.2
API	Dots API (Push-to-Debit/RTP) · Dots API · Rippling Off-Cycle Payroll API
Cron Job task	Không có
3rd Party	Dots, Rippling, Slack

2. Trigger

UC_7.2 cho qua: hồ sơ nhận tiền của trader có Payout_Status = 'Approved' (Ref: UC_7.2 BR_7.2.1).
Hoặc khoản tiền đang bị giữ ở UC_7.2 được giải phóng, khi Dots báo hồ sơ của trader đã về Approved (Ref: UC_7.2 BR_7.2.2).

3. Pre-conditions

Hồ sơ nhận tiền của trader có Payout_Status = 'Approved' (Ref: UC_7.2 BR_7.2.1).
Bảng payouts đã có bản ghi của lần lên level này, với số tiền đã được Flow 4 chốt lúc promotion (Ref: UC_7.2 BR_7.2.3).
Path A và Path B: trader đã có hồ sơ Dots, tức là Users.dots_payee_id có giá trị (hồ sơ được tạo ở UC_5.4).
Path C: trader đã có W-2 employee record trên Rippling (Ref: UC_8.1.2).

4. Post-conditions

Thành công: bản ghi payout có provider_transaction_id, là mã giao dịch Dots hoặc Rippling trả về (BR_7.3.9). Flow 5 đi tiếp UC_7.4 và UC_7.6.
Timeout: lệnh bị giữ lại, không gửi lại; Operations đã nhận Sev-1 alert; Flow 5 dừng (E_7.3.1).
Dots hoặc Rippling báo lỗi, từ chối: bản ghi payout có payout_status = 'Failed' kèm mã lỗi và lý do; Operations đã nhận Sev-1 alert; Flow 5 dừng (E_7.3.2).

5. Basic Flow

5.1 Chọn đường trả tiền

Stage 1 — Đọc dữ liệu trader

Zapier Flow 5 chạy bước Routing & Execution cho bản ghi payout của trader, sau khi UC_7.2 đã xác nhận Payout_Status = 'Approved'.
Middleware đọc bảng Users tại thời điểm trả tiền để lấy billing_country, current_level, trạng thái onboarding W-2 trên Rippling và dots_payee_id.

Middleware chọn 1 trong 3 path theo BR_7.3.1:

Path	Điều kiện	Trả qua
A — US Contractor	`billing_country` là US và trader chưa hoàn tất onboarding W-2 trên Rippling (Level 1 đến 5, hoặc Level 6 trở lên nhưng đang làm dở Flow 6)	Dots
B — International Contractor	`billing_country` không phải US, ở mọi level	Dots
C — US W-2	`billing_country` là US và `current_level` từ 6 trở lên và đã hoàn tất onboarding W-2 trên Rippling	Rippling

VD: trader ở Mỹ, Level 6, đã hoàn tất onboarding W-2 thì đi Path C. Trader ở Việt Nam, Level 7 thì đi Path B. Trader đổi quốc gia thì xem E_7.3.4.

Middleware tạo một idempotency key cho lệnh trả tiền này. Đây là mã duy nhất gửi kèm lệnh: cùng một key gửi lại thì Dots hoặc Rippling không trả lần hai (BR_7.3.3).

5.2 Gửi lệnh trả tiền

Stage 2 — Gọi Dots hoặc Rippling

Middleware gửi lệnh trả tiền theo path đã chọn. Mỗi path gọi đúng một API:

Path	API Middleware gọi	Input
A	Dots API (Push-to-Debit/RTP)	`dots_payee_id` · `Payout_Amount` (Gross, USD) · idempotency key
B	Dots API	`dots_payee_id` · `Payout_Amount` (Gross, USD) · idempotency key
C	Rippling Off-Cycle Payroll API	Employee ID Rippling của trader · `Payout_Amount` (Gross) · idempotency key

Payout_Amount là đúng số Gross đã chốt ở UC_7.2. Middleware không tính thuế, phí hay tỷ giá (BR_7.3.2). Endpoint cụ thể của Dots và Rippling do BE xác định theo tài liệu của bên đó.

Nếu trader có nhiều khoản đang bị giữ từ nhiều level, Middleware gộp lại thành 1 lệnh với số tiền tổng, kèm 1 idempotency key (BR_7.3.2). Mỗi level vẫn giữ bản ghi payout riêng, và UC_7.4 ghi sổ tách theo từng khoản. VD: trader có 3 khoản bị giữ là Level 2 $1,000, Level 3 $2,000 và Level 4 $3,000. Middleware gửi 1 lệnh $6,000 sang Dots; UC_7.4 ghi 3 event Polygon và 3 Journal Entry.

5.3 Xử lý kết quả

Stage 3 — Đọc kết quả và đi tiếp

Dots hoặc Rippling trả kết quả thành công thì Middleware lưu mã giao dịch vào provider_transaction_id (BR_7.3.9) và trả 200 OK cho Zapier. Từ mốc này hệ thống không chờ hay theo dõi gì thêm với lệnh (BR_7.3.4). Timeout hoặc bị báo lỗi thì xem E_7.3.1, E_7.3.2.
Zapier Flow 5 đi tiếp 2 việc:
- UC_7.4: gọi POST /api/ledger/record với receipt_hash là provider_transaction_id, đồng thời ghi Journal Entry QuickBooks.
- UC_7.6: gọi POST /community/trigger-review-invite để hẹn lời mời Trustpilot.
Khi đã có xác nhận thành công từ Dots hoặc Rippling, và UC_7.4 đã có tx_hash, Middleware đẩy WebSocket event "Payout Completed" để Dashboard hiện thông báo kèm biên nhận blockchain (BR_7.3.7). Trader bấm Resign trong lúc lệnh đang chạy thì xem E_7.3.3.

6. Exceptional Flows

Exception ID	Exception	Condition	System Handling / Fallback
E_7.3.1	Timeout (Ref: BR_7.3.5)	Hết thời gian chờ mà Dots hoặc Rippling không trả kết quả. Thời gian chờ do BE cấu hình.	Middleware giữ lệnh lại và không gửi lại dưới bất kỳ hình thức nào. Middleware gửi Sev-1 alert vào Slack `#ops-general` theo mẫu ở BR_7.3.5. Flow 5 dừng, không chạy UC_7.4 và UC_7.6 cho lệnh này. Operations đối chiếu và xử lý bằng tay.
E_7.3.2	Dots hoặc Rippling báo lỗi, từ chối (Ref: BR_7.3.6)	Dots hoặc Rippling trả lỗi hoặc từ chối lệnh.	Middleware đặt `payout_status = 'Failed'` và lưu mã lỗi, lý do. Middleware gửi Sev-1 alert vào Slack `#ops-general` theo mẫu ở BR_7.3.5, kèm `user_id` và lý do lỗi. Flow 5 dừng: không ghi Immutable Ledger, không chạy UC_7.6. Operations xem xét và xử lý bằng tay.
E_7.3.3	Trader Resign khi đang được trả tiền (Ref: BR_7.3.8)	Trader bấm Resign trong lúc lệnh trả tiền đang chạy.	Lệnh vẫn hoàn tất. `POST /resign` không huỷ lệnh trả tiền.
E_7.3.4	Trader đổi quốc gia (Ref: BR_7.3.1)	Trader chuyển sang quốc gia khác.	Hệ thống không tự chuyển path hay hồ sơ. Trader báo Operations, và Operations xử lý bằng tay trên Dots hoặc Rippling.
E_7.3.6	Không có mã giao dịch (Ref: BR_7.3.5)	Dots hoặc Rippling không trả `transaction_id`.	Middleware gửi Sev-1 alert vào Slack `#ops-general` theo cùng mẫu ở BR_7.3.5.
E_7.3.5	Ghi Polygon đang thử lại (Ref: BR_7.3.7)	UC_7.4 chưa có `tx_hash` vì ghi Polygon đang thử lại (UC_7.4 BR_7.4.2).	Thông báo "Payout Completed" đến chậm. Việc này chấp nhận được, vì tiền đã nằm trong ví Dots hoặc Rippling của trader.

7. Business Rules

BR_ID	Rule Description
BR_7.3.1	Chọn đường trả tiền: Middleware đọc `Users` tại thời điểm trả tiền, lấy quốc gia theo `billing_country`.- Path A (US Contractor): `billing_country` là US và trader chưa hoàn tất onboarding W-2 trên Rippling. Trả qua Dots API (Push-to-Debit/RTP).- Path B (International Contractor): `billing_country` không phải US, ở mọi level. Trả qua Dots API.- Path C (US W-2): `billing_country` là US, `current_level` từ 6 trở lên và đã hoàn tất onboarding W-2 trên Rippling. Trả qua Rippling Off-Cycle Payroll API.Trader đổi quốc gia thì hệ thống không tự chuyển path hay hồ sơ; Operations xử lý bằng tay (E_7.3.4).
BR_7.3.2	Số tiền gửi đi: Gửi đúng số Gross đã chốt ở UC_7.2, gồm tiền thưởng theo Table A hoặc B và tiền hoàn phí Market Data nếu có (UC_7.2 BR_7.2.3).Middleware không tính thuế, phí hay tỷ giá; Dots và Rippling tự xử lý.Không có ngưỡng tối thiểu `Min_Payout_Threshold`, không có số dư dồn sang kỳ sau (Rollover Balance): có khoản là trả.Gộp các khoản bị giữ của nhiều level thành 1 lệnh gửi sang Dots hoặc Rippling: khi `Payout_Status` của trader về `Approved`, Middleware gửi 1 lệnh trả tiền với số tiền tổng. Mỗi level vẫn là một bản ghi payout riêng, nên UC_7.4 ghi Immutable Ledger và QuickBooks tách theo từng khoản (UC_7.4 BR_7.4.3).
BR_7.3.3	Chống trả trùng: Mọi lệnh gửi sang Dots và Rippling đều kèm idempotency key; cùng key gửi lại thì không trả lần hai.Hệ thống không bao giờ tự gửi lại một lệnh trả tiền, kể cả khi timeout (BR_7.3.5).
BR_7.3.4	Mốc thành công: Lệnh trả tiền thành công khi Dots hoặc Rippling trả kết quả thành công. Hệ thống không chờ hay theo dõi gì thêm sau mốc này.- Dots: mốc thành công là tiền vào hồ sơ Dots của trader. Dots tự lo hình thức nhận tiền, rút về ngân hàng, thuế 1099 hoặc thuế quốc tế, quy đổi tiền tệ.- Rippling: mốc thành công là khoản bonus vào Off-Cycle Payroll. Rippling tự lo khấu trừ thuế, payslip, direct deposit.Trader xem lịch sử và chi tiết khoản nhận trên Dots hoặc Rippling. Billing trên Dashboard không hiển thị khoản này.Sau mốc thành công, Flow 5 đi tiếp UC_7.4 và UC_7.6; đồng hồ `delay_hours` của UC_7.6 bắt đầu tính từ mốc này.
BR_7.3.5	Timeout — giữ lệnh, không gửi lại: Dừng và giữ lệnh. Không tự gửi lại dưới bất kỳ hình thức nào. Thời gian chờ để tính là timeout do BE cấu hình. Gửi Sev-1 alert vào Slack `#ops-general` (Prod `C0BR8LRC5MK`, Test `#test-ops-general` `C0BR6UXRR8D`, CR-15.2). Mẫu alert dùng chung cho timeout, lỗi hoặc từ chối, và trường hợp không có `transaction_id`:`[SEV 1 - PAYOUT FAILURE] User ID: {user_id}
BR_7.3.6	Dots hoặc Rippling báo lỗi, từ chối: Middleware làm đủ 3 việc:1. Không ghi Immutable Ledger, tức là không emit `CorporateMetricVerified` lên Polygon.2. Đặt `payout_status = 'Failed'` trong PostgreSQL và lưu mã lỗi, lý do mà Dots hoặc Rippling trả về.3. Gửi Sev-1 alert vào Slack `#ops-general` theo mẫu ở BR_7.3.5, có `user_id` và lý do lỗi.Việc xem xét và xử lý sau alert do Stack Trading Operations làm.
BR_7.3.7	WebSocket "Payout Completed": Chỉ emit khi có đủ cả hai:1. Middleware có xác nhận thành công từ Dots (`transfer.completed`) hoặc Rippling (payroll clearance confirmation). Cách nhận xác nhận, qua kết quả của lệnh trả tiền hay qua webhook, do BE xác định theo tài liệu của Dots và Rippling.2. UC_7.4 đã lưu `tx_hash` Polygon cho bản ghi payout này.Event đẩy qua WebSocket để Dashboard hiện thông báo "Payout Completed" kèm biên nhận blockchain (`tx_hash`).Không tách thành 2 lần (báo trước, gắn biên nhận sau), vì trang certificate cần `polygon_tx_hash` để hiện QR xác minh; báo sớm thì trader mở ra certificate chưa đầy đủ. Ghi Polygon đang thử lại thì thông báo đến chậm (E_7.3.5).
BR_7.3.8	Trader Resign khi đang được trả tiền: Lệnh trả tiền đang chạy vẫn hoàn tất. `POST /resign` không huỷ lệnh trả tiền.
BR_7.3.9	Dữ liệu UC này ghi vào bản ghi payout:- Idempotency key: ghi trước khi gửi lệnh (bước 4).- `provider_transaction_id`: ghi khi Dots hoặc Rippling trả kết quả thành công. Giá trị này được chuyển sang UC_7.4 làm `receipt_hash`. Lệnh gộp nhiều khoản thì cùng một `provider_transaction_id` được ghi vào mọi bản ghi payout trong lệnh.- `payout_status = 'Failed'` kèm mã lỗi, lý do: ghi khi Dots hoặc Rippling báo lỗi hoặc từ chối (BR_7.3.6). Lệnh gộp nhiều khoản bị lỗi thì mọi bản ghi payout trong lệnh đều là `'Failed'`.`payout_status` là trạng thái của từng lệnh trả tiền, khác `Payout_Status` là trạng thái hồ sơ Dots của trader (UC_7.2). UC này chỉ ghi giá trị `'Failed'`. Mọi thời điểm lưu theo CR-08 (UTC, ISO 8601).

8. Open Items

#	Hạng mục	ID	Mức độ
1	Công cụ để Operations kết thúc lệnh bị giữ sau timeout (nội dung alert đã chốt ở BR_7.3.5)	A-73	🟠

9. Phân chia trách nhiệm

Hạng mục	Sotatek build	Stack Trading Ops	Bên thứ 3 tự chạy
Bước Routing & Execution của Zap Flow 5, logic chọn Path A, B, C	✅	—	Zapier
Gọi Dots API (Path A, B), Rippling Off-Cycle Payroll API (Path C), idempotency key	✅	—	—
Ghi `provider_transaction_id`, `payout_status = 'Failed'` và mã lỗi, Sev-1 alert Slack	✅	—	Slack
WebSocket event "Payout Completed"	✅	—	—
Đối chiếu và xử lý lệnh bị giữ hoặc `Failed`	—	✅	—
Trader đổi quốc gia: chuyển đổi hồ sơ	—	✅	Dots, Rippling
Hình thức nhận tiền, rút về ngân hàng, thuế, tỷ giá	—	—	Dots
Khấu trừ thuế W-2, payslip, direct deposit	—	—	Rippling

Changelog

Date	Version	Updated item	Before	After	Notes
2026-10-10	v1	Initial document	—	—	Bản tiếng Việt để BA re-check trước khi chuyển sang tiếng Anh. Nguồn chính: `Zapier Integration V7.pdf` §Flow 5 (Routing & Execution — Path A/B/C) và QnA STAGE 5 A-20, A-21, A-22 (Adrian Q5), A-25, A-26, A-28, A-29, A-55, A-65, A-107, A-115; A-27 trả lời một phần (chỉ phần Gross / thuế). QnA override spec V7: (1) bỏ Minimum Check ($100 `Min_Payout_Threshold`) và Rollover Balance khỏi Flow 5 — A-10 / Adrian Q4: "Please remove the Min_Payout_Threshold check and any rollover balance logic entirely from Flow 5." (2) Thêm xử lý lỗi không có trong V7: timeout → dừng, không retry, Sev-1 (A-25 — khác đề xuất retry 3 lần của BA); bị từ chối → `Failed`, không ghi Polygon, Sev-1 `#operations` (A-107 — khác đề xuất treo lại của BA). (3) Thêm thông báo "Payout Completed" (A-29) — V7 Flow 5 không có bước thông báo trader.
2026-10-12	v1	§8 Hạng mục mở	17 hạng mục, viết theo ngôn ngữ kỹ thuật	16 hạng mục, viết lại bằng ngôn ngữ nghiệp vụ, sắp theo mức độ; gộp A-96 + A-82	Theo yêu cầu BA. Giữ đủ mọi câu hỏi, không bỏ câu nào.
2026-10-12	v1	§1, §5, §6, §7 (BR_7.3.1–BR_7.3.9), §8, §9	16 hạng mục mở. Path A ghi "Push-to-Debit / RTP". Slack `#operations`. Chưa có rule trader Resign khi đang trả. Chưa định rõ mốc trader Mỹ Level 6 thành W-2. 8 BR	BA chốt 13 hạng mục, còn 3 mở (A-73, A-71, A-79). Path A/B chỉ ghi "Dots API". Slack `#ops-general`. Thêm BR_7.3.8 (Resign vẫn trả); BR thông tin kỹ thuật chuyển thành BR_7.3.9. 9 BR. §6 đánh số lại (6.1 Path C · 6.2 Timeout · 6.3 Lỗi · 6.4 Resign)	BA Anh Hoang chốt 2026-10-12: A-24 dùng `billing_country` — khác hướng CR-20260812-005 (Flow 3D dùng quốc gia Veriff), giữ nguyên có chủ đích. Mới — mốc W-2 = trader hoàn tất onboarding trên Rippling, trước đó trả qua Dots (thay A-21 "Flow 6 chưa xong"). A-64/A-74, A-96/A-82 — trader tự xem khoản nhận trên Dots/Rippling, Dashboard không hiển thị Billing cho khoản này. A-108 — bỏ khỏi UC này: lỗi bước không chạy có thể xảy ra ở mọi bước, xử lý trong từng UC. A-23 — trader tự báo Ops, Ops làm tay, ngoài scope Sotatek. A-106, A-27 — Dots/Rippling tự xử lý hình thức nhận, thuế, tỷ giá, ngoài scope Sotatek. A-109 — không có bước duyệt, đủ điều kiện là trả (không ghi thành rule). A-72 — mốc thành công = tiền vào Dots/Rippling. A-80 — vẫn trả. A-81 — tiền tiếp tục bị giữ tới khi Dots duyệt lại, đã nằm trong cơ chế giữ tiền của UC_7.2 BR_7.2.2, không thêm rule ở UC này. Slack — `#ops-general` thay `#operations` khách ghi (kênh không có trong CR-15.2). A-73 — xử lý sau cảnh báo do Stack Trading làm; nội dung cảnh báo timeout BA đang hỏi khách.
2026-10-12	v1	Toàn UC — bổ sung đặc tả kỹ thuật	Phần kỹ thuật gom trong một BR "Thông tin kỹ thuật cho dev" (BR_7.3.9), chỉ ghi chung "Dots API", "Rippling API". Không có endpoint, không có vòng đời `payout_status` ngoài `Failed`. 3 hạng mục mở	Thêm §7 "API & Tác vụ nền" (API-1→API-5): Dots `POST /v2/transfers`, Rippling Off-Cycle Payroll, webhook `transfer.completed`, Sev-1 Slack; ghi rõ UC không có cron job. Luồng §5 ghi theo request / trạng thái (`Pending` → `Sent` → `Confirmed`). BR_7.3.9 đổi thành "Bản ghi payout và vòng đời `payout_status`". Thêm 4 hạng mục mở N-01→N-04 (endpoint Flow 5, endpoint Rippling, endpoint webhook Dots, ngưỡng timeout). Đánh số lại: BR §7→§8, Hạng mục mở §8→§9, RACI §9→§10	Theo yêu cầu BA: UC phải ghi đủ API và tác vụ nền. Nguồn: `POST /v2/transfers` — CR-20261011-001; webhook `transfer.completed` — A-29; vòng đời `Pending → Sent → Confirmed → Failed` + UNIQUE — A-26; allowlist IP Dots — RFQ V7 Webhook Whitelisting. Endpoint Flow 5, endpoint Rippling, endpoint webhook Dots, ngưỡng timeout không có trong source → hạng mục mở.
2026-10-12	v1	§5 Luồng cơ bản, §6 Luồng thay thế	Bảng luồng không có cột API; bước Zapier gọi Middleware, webhook Dots và lệnh Rippling không ghi tên API; §6 viết dạng đoạn văn	Thêm cột API cho §5 và §6 (6.1–6.3 chuyển sang dạng bảng); mỗi bước gọi API ghi tên + method/path (API-1→API-5, `POST /api/ledger/record`, `POST /community/trigger-review-invite`, WebSocket); path chưa có trong source ghi `<path chờ chốt>` kèm N-xx; tách hẹn Trustpilot thành bước 9 riêng	Theo yêu cầu BA: API phải xuất hiện ngay trong basic flow, mục API chỉ đặc tả chi tiết.
2026-10-13	v1	§1, §4, §5, §6, §7, BR_7.3.4, BR_7.3.5, BR_7.3.9, §9, §10	§5 chỉ có Path A/B; Path C nằm ở §6.1 như luồng thay thế. Có bước chờ webhook Dots `transfer.completed` và bước chờ Rippling xác nhận mới đặt `Confirmed`; API-4 webhook Dots; hạng mục mở N-03 (path webhook Dots). Hẹn Trustpilot và WebSocket nằm trong luồng UC này	§5 chia 3 bước: (1) nhận yêu cầu + query `Users`, (2) bảng 3 path A/B/C — A/B gọi Dots `POST /v2/transfers`, C gọi Rippling Off-Cycle Payroll API, (3) response thành công → `Confirmed`, kết thúc. Bỏ bước chờ webhook / xác nhận; bỏ API webhook Dots và N-03; Slack đổi thành API-4. §6 chỉ còn ngoại lệ (6.1 Timeout · 6.2 Lỗi · 6.3 Resign). Mốc thành công = response thành công của API-2 / API-3	BA Anh Hoang: luồng chính theo `Zapier Integration V7.pdf` §Flow 5 — query `billing_country` + `current_level`, trigger Dots / Rippling cho `Payout_Amount`; hệ thống chỉ gửi lệnh, sau đó không làm gì thêm.
2026-10-13	v1	BR_7.3.7 điều kiện 1	`payout_status = 'Confirmed'` (response thành công của API-2 / API-3)	Middleware có xác nhận thành công từ provider: Dots `transfer.completed` / Rippling payroll clearance confirmation; cách nhận (response hay webhook) do BE xác định theo tài liệu provider	Theo A-29 (khách 2026-09-10). BA Anh Hoang: cách nhận tín hiệu là việc BE kiểm tra với tài liệu Dots / Rippling, không cần hỏi lại khách.
2026-10-13	v1	§9 Hạng mục mở #5 (A-71)	"Payout Completed" emit ngay khi `Confirmed`, hay chờ có `tx_hash`	Bắn ngay khi có xác nhận từ Dots / Rippling rồi bổ sung biên nhận sau, hay chờ có cả `tx_hash`	Viết lại theo điều kiện mới của BR_7.3.7 (`Confirmed` không còn là tín hiệu bắn thông báo). Các hạng mục khác không đổi.
2026-10-13	v1	§5 bước 1.1, API-1, §9 Hạng mục mở	API-1 "Execute Payout Routing", path chờ chốt; hạng mục mở N-01 (endpoint Middleware cho Flow 5)	API-1 "Payout Routing endpoint": path do BE đặt, build cùng khuôn `Process Severance Payout` (Flow 9). Gỡ N-01; §9 còn 5 hạng mục	BA Anh Hoang: Flow 9 và Flow 5 có cùng logic Path A/B/C → Dots / Rippling trong `Zapier Integration V7.pdf`, không cần hỏi khách endpoint riêng cho Flow 5.
2026-10-13	v1	§1, §5, §6, §7, BR_7.3.1, BR_7.3.4, BR_7.3.9, §10	API-1 "Payout Routing endpoint" (Zapier → Middleware); Path A và Path B cùng gọi API-2 Dots `POST /v2/transfers`; API-3 Rippling	Bỏ API "Payout Routing endpoint" (bước Routing là logic, không phải API). 3 API riêng theo 3 path: API-1 Dots API (Push-to-Debit/RTP) — Path A; API-2 Dots API — Path B; API-3 Rippling Off-Cycle Payroll API — Path C. Endpoint Dots do BE xác định theo tài liệu Dots	BA Anh Hoang: ghi đúng 3 API như `Zapier Integration V7.pdf` §Flow 5 Routing & Execution.
2026-10-13	v1	API-3, BR_7.3.2, BR_7.3.5, BR_7.3.7, §9	Endpoint Rippling chờ chốt (N-02); ngưỡng timeout chờ chốt (N-04); khoản treo nhiều level gửi thành một lệnh gộp; BR_7.3.7 chưa nói về việc tách 2 nấc; §9 có 5 hạng mục	Endpoint Rippling do BE xác định theo tài liệu Rippling; ngưỡng timeout do BE cấu hình; không gộp — mỗi khoản treo gửi thành lệnh riêng; BR_7.3.7 thêm: không tách 2 nấc, chấp nhận thông báo chậm khi Polygon retry; §9 còn A-73	BA Anh Hoang chốt 2026-10-13: N-02, N-04 là việc BE. Khách đã trả lời: A-71 — không tách sự kiện, certificate cần `polygon_tx_hash`; A-68 · A-96 — không gộp, trả từng khoản, 3 dòng ledger + 3 bút toán QuickBooks. A-79 đóng — `Locked` là trạng thái của Drawdown Defense, không liên quan việc gửi tiền sang Dots / Rippling; rút tiền về tài khoản cá nhân do trader tự làm trên Dots / Rippling (ngoài scope Sotatek). Lệch với UC_7.2 BR_7.2.2 ("bundle all earned bonuses into a single aggregated payout") — UC_7.2 do BA khác phụ trách, chỉ ghi nhận.
2026-10-14	v1	Toàn UC — viết lại theo khuôn UC_8.1.x	Có bảng Thuật ngữ; luồng viết dạng bảng "Ai làm / Việc gì / API / Ref"; luồng ngoại lệ tách riêng §6; mục "API & Tác vụ nền" liệt kê 4 API (API-1 Dots Push-to-Debit/RTP, API-2 Dots, API-3 Rippling, API-4 Slack Webhook)	Bỏ bảng Thuật ngữ (giải thích ngay trong bước). Basic Flow chia 3 Stage, bước đánh số, rẽ nhánh `[If …] →` ngay trong bước. Timeout / lỗi đưa vào Stage 3 bước 1. Tên API và input ghi ngay trong Stage 2. Bỏ mục "API & Tác vụ nền": chỉ còn 3 API đúng như nguồn (Dots API (Push-to-Debit/RTP), Dots API, Rippling Off-Cycle Payroll API); Slack Sev-1 alert là một hành động trong bước, không đánh số API	Theo yêu cầu BA: mô tả và thứ tự như UC_8.1.1 / UC_8.1.2; số API phải khớp `Zapier Integration V7.pdf` §Flow 5 Routing & Execution. Nội dung nghiệp vụ và BR ID giữ nguyên.
2026-10-14	v1	Trigger, Pre-conditions, Stage 1 bước 1–2, BR_7.3.9	Pre-condition chỉ ghi "bản ghi payout `payout_status = 'Pending'`", không có điều kiện `Payout_Status = 'Approved'`; ghi bản ghi payout do UC_7.2 tạo	Pre-condition thêm `Payout_Status = 'Approved'` (hồ sơ trader, UC_7.2 BR_7.2.1); ghi rõ `payout_status = 'Pending'` là trạng thái của từng lệnh trả tiền (= chưa gửi đi), không phải điều kiện được trả tiền; bản ghi trong bảng `payouts` do Flow 4 tạo lúc promotion (UC_7.2 BR_7.2.3, UC_8.1.1 Stage 4)	BA hỏi lại vì 2 trường `Payout_Status` (hồ sơ trader) và `payout_status` (lệnh trả tiền, A-26 / A-107) dễ nhầm. Không đổi nghiệp vụ.
2026-10-14	v1	Pre-conditions, Post-conditions, Stage 1, Stage 3, BR_7.3.3, BR_7.3.5, BR_7.3.9, RACI	Vòng đời `payout_status` `Pending → Sent → Confirmed / Failed`; bước kiểm tra `payout_status ≠ Pending` thì dừng; ràng buộc UNIQUE (`user_id`, promotion event); BR_7.3.9 "Vòng đời `payout_status`"	Bỏ `Pending`, `Sent`, `Confirmed`, bước kiểm tra `Pending` và ràng buộc UNIQUE. Chống trả trùng chỉ bằng idempotency key + không bao giờ tự gửi lại. `payout_status` chỉ có `'Failed'` khi provider báo lỗi. Thành công = có `provider_transaction_id`. BR_7.3.9 đổi thành "Dữ liệu UC này ghi vào bản ghi payout"	`Pending / Sent / Confirmed` và UNIQUE là đề xuất [ASSUMPTION] của BA ở A-26, khách không chốt (khách chỉ chốt idempotency key — A-26; `payout_status = 'Failed'` — A-107; timeout hold, không retry — A-25). Đưa vào UC ngày 2026-10-12 là sai.
2026-10-29	v1.1	Toàn UC — cấu trúc lại theo khuôn UC_1.8.7	Description ghi chi tiết path, API và nhánh lỗi; timeout, lỗi provider, Resign nằm trong Stage 3 của flow; bước đánh số lại từ 1 ở mỗi Stage; 9 BR viết dạng mục con, BR_7.3.1, BR_7.3.4, BR_7.3.9 có bảng riêng	Description chỉ ghi tổng quan. Mục đánh số 1 đến 9; §5 chia 5.1 chọn đường trả tiền, 5.2 gửi lệnh, 5.3 xử lý kết quả; bước đánh số liên tục 1 đến 9. Thêm bảng §6 Exceptional Flows (E_7.3.1 đến E_7.3.5: timeout, provider báo lỗi, Resign, đổi quốc gia, Polygon thử lại). 9 BR gom vào bảng §7. Overview thêm dòng API và Cron Job task. Mọi BR đều được refer từ bước hoặc exception liên quan. Giữ nguyên anchor `UC_7.3-1` đến `UC_7.3-5`, `UC_7.3-BR`, `UC_7.3-8`, `UC_7.3-9`, `BR_7.3.1` đến `BR_7.3.9`	BA yêu cầu viết dễ hiểu như UC_1.8.7, không đổi nghiệp vụ
2026-10-29	v1.2	§5.2 bước 6 · BR_7.3.2 · BR_7.3.9	Khoản bị giữ của nhiều level: không gộp, mỗi khoản 1 lệnh trả tiền riêng (A-68, A-96)	Gộp thành 1 lệnh gửi Dots hoặc Rippling với số tiền tổng; mỗi level vẫn là 1 bản ghi payout, UC_7.4 ghi sổ tách theo từng khoản. Lệnh gộp: cùng `provider_transaction_id` cho mọi bản ghi; lệnh lỗi thì mọi bản ghi `Failed`	BA chốt 2026-10-29: "gộp 1 lệnh" (UC_7.2 BR_7.2.2) là 1 lệnh gửi tổng tiền sang Dots/Rippling; phần ghi sổ ở UC của mình vẫn tách từng khoản. Hết lệch với UC_7.2
2026-10-30	v1.3	BR_7.3.5, BR_7.3.6 · E_7.3.1, E_7.3.2 · E_7.3.6 (mới) · §8 #1 · §9	Nội dung Sev-1 alert chưa chốt (A-73)	Mẫu alert `[SEV 1 - PAYOUT FAILURE] User ID: {user_id} \| Name: {first_name} {last_name} \| Rail: {Dots/Rippling} \| Amount: ${payout_amount} \| Error: {error_reason}` vào `#ops-general`, dùng cho timeout, lỗi hoặc từ chối, và khi Dots hoặc Rippling không trả `transaction_id` (E_7.3.6 mới). Không thử lại. Open Item #1 chỉ còn phần công cụ kết thúc lệnh bị giữ	Khách xác nhận bản tóm tắt cách xử lý lỗi Flow 5 của BA

UC 7.3

On this page