[Diagram] Refund & Chargeback: Khi Fintech Phải Xử Lý "Dòng Tiền Ngược"

Trong thế giới thanh toán, việc nhận tiền vào là niềm vui, nhưng việc trả tiền ra (Refund) hoặc bị ngân hàng đòi tiền (Chargeback) lại là một bài toán vận hành (Operations) phức tạp. Sơ đồ này chia làm 3 lớp nhân vật (Swimlanes) chính: Customer/Buyer , Finance Team và Approver.

Link Diagram: https://github.com/HuyHoangCoder/Diagram/blob/main/Refund %26 Chargeback.pdf, cảm ơn anh em đã đọc bài viết

1. Điểm khởi đầu: Request & Validation

Quy trình bắt đầu khi khách hàng gửi yêu cầu hoàn tiền hoặc khiếu nại qua support form hoặc cổng người bán.

• Finance Team tiếp nhận: Ngay khi có request, đội tài chính sẽ tạo một "case" (vụ việc) trên hệ thống Ticketing hoặc ERP.
• Xác thực dữ liệu: Finance Team sẽ kiểm tra chi tiết giao dịch và tính hợp lệ thông qua cổng thanh toán (Payment Gateway) hoặc ngân hàng. Đây là bước quan trọng để loại bỏ các yêu cầu rác hoặc gian lận.

2. Ngã rẽ logic: Refund vs. Chargeback

Đây là phần quan trọng nhất trong bài viết này. Hệ thống sẽ phân loại dựa trên loại tranh chấp (Dispute type):

A. Nhánh Hoàn tiền (Refund Request)

Đây là luồng "hòa bình", khi người bán chủ động trả lại tiền cho khách.

1. Tính toán: Finance Team tính toán số tiền có thể hoàn lại và các loại phí phát sinh.
2. Kiểm soát ngưỡng (Threshold): Nếu số tiền vượt quá một ngưỡng phê duyệt nhất định (Amount over approval threshold), cần phải có sự can thiệp của Approver.
3. Thực hiện: Sau khi được duyệt , giao dịch hoàn tiền được xử lý qua cổng thanh toán. Cuối cùng, thông báo xác nhận sẽ được gửi tới khách hàng.

B. Nhánh Khiếu nại (Chargeback)

Đây là luồng "xung đột", khi khách hàng đòi tiền thông qua ngân hàng phát hành thẻ.

1.Tiếp nhận thông báo: Finance Team nhận thông báo khiếu nại từ ngân hàng/cổng thanh toán. 2. Thu thập bằng chứng: Đội ngũ phải thu thập bằng chứng (vận đơn, lịch sử chat...) và phản hồi lại trước hạn chót (due date). 3. Phê duyệt chiến lược: Một Approver sẽ xem xét và phê duyệt chiến lược phản hồi khiếu nại này. Nếu không ổn, gói phản hồi sẽ phải điều chỉnh lại.

3. Các kịch bản đặc biệt: Goodwill & Escalation

Sơ đồ còn thể hiện những "góc khuất" rất thực tế trong vận hành:

• Goodwill Refund (Hoàn tiền thiện chí): Có những trường hợp dù khách hàng không hoàn toàn đúng, nhưng để giữ uy tín, hệ thống vẫn cho phép xử lý "Goodwill refund".
• Customer Escalates (Khách hàng leo thang): Nếu yêu cầu ban đầu bị từ chối, khách hàng có quyền khiếu nại lên cấp cao hơn (Submit escalation). Điều này buộc hệ thống phải đánh giá lại toàn bộ quy trình.
• Kết quả cuối cùng: Một là thắng khiếu nại (Won), hai là mất tiền và chịu thêm phí (Lost). Nếu mất, tài chính phải ghi nhận khoản lỗ và phí dịch vụ.

4. Bài học về System Design cho anh em

Từ sơ đồ này, chúng ta rút ra 3 "Pattern" quan trọng khi thiết kế hệ thống tài chính:

1. Audit Trail: Mọi bước từ nhận request đến lúc thông báo cho khách đều phải được log lại trong ERP để đối soát sau này.
2. State Machine: Một yêu cầu hoàn tiền/khiếu nại trải qua rất nhiều trạng thái (Open, Validating, Pending Approval, Approved/Rejected, Finished). Code của anh em nên quản lý bằng State Machine để tránh logic "spaghetti".
3. Asynchronous Processing: Các bước làm việc với Ngân hàng/Gateway luôn mất thời gian. Hãy thiết kế luồng xử lý bất đối xứng (Webhook/Callback) để không làm treo hệ thống.

Kết luận

Xử lý Refund & Chargeback không chỉ là code, đó là sự kết hợp giữa logic nghiệp vụ, bảo mật và khả năng phối hợp giữa các bộ phận. Hiểu rõ quy trình này sẽ giúp anh em xây dựng những hệ thống thanh toán "vững như bàn thạch

Anh em có câu hỏi nào về cách handle Webhook khi có Chargeback từ Stripe hay PayPal không? Hãy comment bên dưới nhé!