# Collection  Payment

Bài viết này nhằm note lại cách tiếp cận **có hệ thống** để bắt đầu tìm hiểu toàn diện về **mảng Thu – Chi hộ (Collection & Payment Services)** mà các ngân hàng hiện nay đang triển khai cho doanh nghiệp và tổ chức.

# Thu – Chi hộ là gì? (Khái niệm cốt lõi)

**Thu hộ**: Ngân hàng thay mặt doanh nghiệp thu tiền từ khách hàng cuối.  
**Chi hộ**: Ngân hàng thay mặt doanh nghiệp chi tiền đến người thụ hưởng.

→ Bản chất: *Ngân hàng đóng vai trò trung gian thanh toán + đối tác vận hành (outsourced operation) cho doanh nghiệp*.

→ Mục tiêu của doanh nghiệp: giảm chi phí vận hành, thu tiền nhanh, đối soát tự động, tăng trải nghiệm khách hàng.

# 1\. Thu hộ

**Thu hộ là gì? Tổng quan toàn cảnh**, viết theo chuẩn **nghiệp vụ ngân hàng + kỹ thuật hệ thống**, đảm bảo Boss có một nền tảng vững chắc để bước vào các bài tiếp theo.

# **Thu hộ là gì? Tổng quan toàn cảnh**

## 1\. Thu hộ là gì? (Định nghĩa chuẩn ngân hàng)

**Thu hộ (Collection Service)** là dịch vụ trong đó **ngân hàng đứng ra thu tiền thay mặt doanh nghiệp**, sau đó chuyển thông tin giao dịch và báo cáo đối soát về cho doanh nghiệp.

Nói ngắn gọn: **Doanh nghiệp không cần tự vận hành việc thu tiền ngân hàng làm thay một phần hoặc toàn bộ quy trình thu và đối soát.**

Thu hộ thường được dùng cho:

* Công ty tài chính (thu tiền trả góp hàng tháng)
    
* Điện lực – nước – viễn thông
    
* Trường học (học phí, phí dịch vụ)
    
* Công ty bảo hiểm
    
* Bán lẻ, thương mại điện tử
    
* Doanh nghiệp có hàng nghìn – hàng triệu khách hàng phải thu định kỳ
    

## 2\. Tại sao doanh nghiệp cần thu hộ?

Doanh nghiệp thường có 3 vấn đề lớn:

### **Tốn công vận hành thu tiền**

* Nhận chứng từ
    
* Kiểm tra chuyển khoản
    
* Gán đúng khách hàng
    
* Nhập liệu thủ công
    
* Đối chiếu công nợ
    

→ Dễ sai, mất thời gian, chậm dòng tiền.

### **Giao dịch quá nhiều → doanh nghiệp không tự xử lý kịp**

Nhiều công ty tài chính có **hàng trăm nghìn – hàng triệu giao dịch/ngày**.

### **Trải nghiệm khách hàng kém**

* Chuyển khoản sai nội dung
    
* Nhầm tài khoản
    
* Gửi chứng từ rườm rà
    
* Chờ vài ngày mới được cập nhật công nợ
    

Vì vậy, họ muốn ngân hàng đứng ra xử lý **tự động – nhanh – chính xác**.

## 3\. Lợi ích của thu hộ

### Đối với doanh nghiệp

* **Tiền về nhanh**, cập nhật công nợ realtime
    
* **Giảm sai sót** khi khách hàng chuyển khoản sai nội dung
    
* **Giảm chi phí vận hành** (kế toán, nhập liệu, đối soát)
    
* **Dễ mở rộng quy mô**
    
* Hỗ trợ **đa kênh nộp tiền**: chuyển khoản, ATM, mobile banking, QR Pay, quầy…
    

### Đối với ngân hàng

* **Tăng CASA** (tiền gửi không kỳ hạn)
    
* **Tăng fee-based income** (thu phí trên mỗi giao dịch thu hộ)
    
* Tạo **ràng buộc dài hạn** với doanh nghiệp
    
* Tăng **vol giao dịch**, từ đó tăng dữ liệu phục vụ phân tích, scoring
    

## 4\. Các đối tượng tham gia vào hệ thống thu hộ

### **Doanh nghiệp (Biller)**

* Đưa danh sách khách hàng và mã tham chiếu cho ngân hàng
    
* Tiếp nhận báo cáo và reconcile từ ngân hàng
    
* Cập nhật công nợ cho khách hàng
    

### **Khách hàng cuối**

* Thực hiện thanh toán (nhập mã tham chiếu, scan QR, nộp tại quầy…)
    

### **Ngân hàng**

Gồm 3 vai trò chính:

* **Thu tiền :** Nhận tiền qua nhiều kênh.
    
* **Gán giao dịch đúng khách hàng:** Đây là yếu tố sống còn của thu hộ.
    
* \*\*Đối soát & báo cáo (\*\*Gửi thông báo giao dịch realtime qua callback hoặc API, gửi file đối soát cuối ngày)
    

## 5\. Các mô hình thu hộ phổ biến

### **Thu hộ qua tài khoản doanh nghiệp**

* Khách hàng chuyển khoản thẳng vào tài khoản của doanh nghiệp
    

### **Thu hộ qua tài khoản ảo – Virtual Account (VA)**

* Mỗi khách hàng/đơn hàng có 1 số tài khoản riêng.
    
* Đây là mô hình **chuẩn – phổ biến nhất** hiện nay.
    

### **Thu hộ tại quầy**

* Khách ra bất kỳ chi nhánh nào để nộp tiền chuyển khoản vào tài khoản doanh nghiệp, sau đó ngân hàng báo có cho doanh nghiệp.
    

### **Thu hộ qua QR**

* QR static/dynamic embedded mã tham chiếu
    
* Giao dịch realtime, đối soát tức thì
    

### **Thu hộ qua Partner/Payment Gateway**

* Ví điện tử (Momo, ZaloPay, ShopeePay…)
    
* Napas Bill Payment
    
* Payment Gateway
    

## 6\. Quy trình thu hộ tổng quát (End-to-End Flow)

Dưới đây là luồng chuẩn nhất mà đa số ngân hàng áp dụng:

Các bước:

1. Khách hàng thanh toán (chuyển khoản/QR/nộp quầy).
    
2. Ngân hàng nhận giao dịch, xác thực, hạch toán vào Core.
    
3. Hệ thống thu hộ (Collection Engine) ánh xạ giao dịch → đúng khách hàng/đơn hàng.
    
4. Gửi thông báo thu thành công cho doanh nghiệp (realtime).
    
5. Cuối ngày đối soát và gửi file reconciliation.
    
6. Doanh nghiệp xác nhận → đóng ngày/thu hoàn tất.
    

## 7\. Vai trò chiến lược của thu hộ trong ngân hàng

### **Tăng CASA – yếu tố sống còn của ngân hàng**

Dòng tiền thu hộ luôn chảy vào tài khoản doanh nghiệp → nâng CASA (tiền gửi không kỳ hạn) đáng kể.

### **Tạo ràng buộc hệ thống**

Doanh nghiệp khó rời bỏ ngân hàng vì đã tích hợp:

* API thu hộ
    
* Đối soát
    
* VA
    
* Báo cáo tùy biến
    

### **Tăng trưởng fee-based income**

Ngân hàng thu phí trên mỗi giao dịch hoặc theo gói dịch vụ.

### **Tạo nền tảng để cross-sell**

Từ dữ liệu giao dịch, ngân hàng đề xuất cung cấp thêm các dịch vụ:

* Chi hộ
    
* Khoản vay
    
* Quản lý dòng tiền
    
* Cash pooling
    

---

# **Các mô hình thu hộ phổ biến**

Các ngân hàng hiện nay triển khai 5 mô hình thu hộ chính:

1. Thu hộ qua tài khoản thanh toán (current account collection)
    
2. Thu hộ qua Tài khoản ảo (Virtual Account – VA)
    
3. Thu hộ tại quầy ngân hàng (OTC Collection)
    
4. Thu hộ qua QR (Static/Dynamic QR Collection)
    
5. Thu hộ qua Payment Gateway (PG) / ví điện tử / Napas Bill Payment
    

Dưới đây là phần phân tích chi tiết.

## 1\. Thu hộ qua **tài khoản thanh toán** của doanh nghiệp

Doanh nghiệp cung cấp cho khách hàng **số tài khoản thật** của mình để khách chuyển tiền.

Ngân hàng sẽ:

* Nhận tiền
    
* Ánh xạ giao dịch đến đúng khách hàng dựa trên **nội dung chuyển khoản**
    
* Gửi dữ liệu về doanh nghiệp qua:
    
    * file đối soát EOD, hoặc
        
    * callback realtime nếu có tích hợp
        

**Quy trình E2E**

```yaml
Khách hàng → chuyển khoản → TK doanh nghiệp
↓
Ngân hàng → hạch toán → phân tích nội dung CK
↓
Mapping Engine → xác định mã KH/hợp đồng
↓
Callback/API → doanh nghiệp → cập nhật công nợ
```

**Ưu điểm**

* Triển khai *rất nhanh* (không cần phát hành VA)
    
* Phù hợp doanh nghiệp nhỏ, ít giao dịch (< 1,000 txn/ngày)
    
* Chi phí tích hợp thấp
    

**Nhược điểm**

* **Phụ thuộc vào nội dung chuyển khoản** → sai nội dung → sai đối tượng
    
* Mapping khó, sai sót nhiều
    
* Không scale cho doanh nghiệp lớn (> 10k txn/ngày)
    
* Thời gian xử lý thường không realtime
    

**Phù hợp cho:**

* Trường học
    
* Căn hộ / chung cư thu phí dịch vụ
    
* Doanh nghiệp nhỏ & SME
    

## 2\. Thu hộ qua **Tài khoản ảo (Virtual Account – VA)**

Ngân hàng phát hành **một số tài khoản riêng biệt cho từng khách hàng / từng hợp đồng / từng hóa đơn**.

Khách hàng chuyển tiền vào VA → giao dịch tự động mapping 100% chính xác.

**Các loại VA thông dụng:**

* VA cố định theo khách hàng (1 khách = 1 VA)
    
* VA theo hợp đồng
    
* VA theo hóa đơn (mỗi lần thu một VA khác nhau)
    

**Quy trình E2E**

```yaml
Doanh nghiệp → tạo VA cho KH/hóa đơn
↓
Khách hàng → chuyển tiền vào VA
↓
Ngân hàng → hạch toán → match VA = khách hàng
↓
Callback realtime → doanh nghiệp → cập nhật công nợ
```

**Ưu điểm**

* **Độ chính xác gần như 100%**
    
* Realtime callback trong 2–5 giây
    
* Không phụ thuộc nội dung CK
    
* Phù hợp doanh nghiệp có **rất nhiều giao dịch**
    
* Dễ tự động hóa → giảm chi phí vận hành
    

**Nhược điểm**

* Cần tích hợp API với doanh nghiệp
    
* Doanh nghiệp phải quản lý vòng đời VA (create/deactivate)
    
* Ngân hàng phải duy trì VA mapping engine → phức tạp hơn
    

**Phù hợp cho:**

* Công ty tài chính (FE, Home Credit, Shinhan Finance…)
    
* Bảo hiểm
    
* Điện/nước/viễn thông
    
* Logistics
    
* E-commerce
    
* Bất kỳ doanh nghiệp có > 5,000 giao dịch/ngày
    

## 3\. Thu hộ **tại quầy ngân hàng** (Over-The-Counter Collection – OTC)

Khách hàng đến trực tiếp chi nhánh/phòng giao dịch của ngân hàng nộp tiền mặt hoặc chuyển khoản tại quầy tới tài khoản của doanh nghiệp.

Giao dịch viên nhập **mã tham chiếu / mã khách hàng** trên hệ thống thu hộ.

**Quy trình E2E**

```yaml
Khách hàng → đến quầy → cung cấp mã KH/hợp đồng
↓
Giao dịch viên → nhập lên hệ thống thu hộ
↓
Core banking → ghi nhận tiền
↓
API/Callback → gửi doanh nghiệp
```

**Ưu điểm**

* Hỗ trợ khách hàng không có ngân hàng điện tử
    
* Giảm sai sót vì GDV nhập liệu
    
* Phù hợp khu vực nông thôn/khách hàng lớn tuổi
    

**Nhược điểm**

* Tốn chi phí vận hành quầy
    
* Không thể scale lớn (giới hạn theo số quầy)
    
* Không phù hợp nghiệp vụ thu hộ số lượng lớn
    

**Phù hợp cho:**

* Công ty tài chính ở vùng không phổ cập mobile banking
    
* Điện/nước vùng nông thôn
    
* Tổ chức yêu cầu nộp tiền mặt
    

## 4\. Thu hộ qua **QR Code (Static/Dynamic QR)**

### 4.1 QR Static (cố định)

* Một mã QR cố định → chứa thông tin ngân hàng đích, số tài khoản nhận, nội dung mẫu
    
* Khách phải nhập lại số tiền, nội dung chuyển khoản, mã khách hàng, …
    

**Ưu điểm**

* Tạo dễ, in trên hóa đơn
    
* Không cần backend phức tạp
    

**Nhược điểm**

* Khách sai nội dung → mismatch
    
* Không xác định được chính xác 100%
    

### 4.2 QR Dynamic (thông minh)

* Mỗi hóa đơn được tạo **một QR riêng**
    
* QR chứa đầy đủ:
    
    * Ngân hàng đích
        
    * Số tài khoản nhận (VA hoặc tài khoản quy định)
        
    * Số tiền
        
    * Mã tham chiếu (reference number)
        
    * Nội dung chuyển tiền
        

**Quy trình E2E**

```yaml
Doanh nghiệp → tạo QR dynamic
↓
Khách scan → thanh toán
↓
Ngân hàng → parse QR → mapping chính xác
↓
Callback realtime → doanh nghiệp
```

**Ưu điểm**

* Độ chính xác rất cao (gần VA)
    
* Tích hợp tốt với mobile banking
    
* Hỗ trợ NAPAS 247 QR (liên ngân hàng)
    

**Nhược điểm**

* Doanh nghiệp cần backend để generate QR
    
* Ngân hàng cần hệ thống QR parsing & routing
    

**Phù hợp cho:**

* E-commerce
    
* Bán lẻ
    
* Bệnh viện, trường học
    
* Vận tải, logistics
    

## 5\. Thu hộ qua **Payment Gateway / Ví điện tử / Napas Bill Payment**

**Đây là mô hình “thu hộ gián tiếp”.** Khách hàng thanh toán tại:

* Ví điện tử (MoMo, ZaloPay, ShopeePay…)
    
* Payment Gateway (VNPay, Payoo, OnePay…)
    
* Hệ thống Napas Bill Payment
    

→ PG/Wallet thu tiền  
→ Chuyển tiền lại về ngân hàng (tài khoản doanh nghiệp)  
→ Gửi file đối soát

**Ưu điểm**

* **Mở rộng kênh thanh toán → tăng tỉ lệ thu**
    
* Trải nghiệm KH tốt, nhất là e-wallet
    
* Có thể thu hộ 24/7
    

**Nhược điểm**

* Không realtime 100% (có độ trễ từ PG → ngân hàng → doanh nghiệp)
    
* Phí cao hơn VA
    
* Phụ thuộc cổng thanh toán
    

**Phù hợp cho:**

* Thương mại điện tử
    
* Dịch vụ thu hộ công cộng
    
* Đơn vị cần đa kênh thanh toán
    

## 6\. **So sánh 5 mô hình thu hộ**

| **Mô hình** | **Độ chính xác** | **Realtime** | **Chi phí tích hợp** | **Khả năng scale** | **Phù hợp** |
| --- | --- | --- | --- | --- | --- |
| Tài khoản thanh toán | Thấp (phụ thuộc NDCK) | Trung bình | Rất thấp | Thấp | Doanh nghiệp nhỏ, SME |
| Tài khoản ảo (VA) | **Rất cao (≈100%)** | **Cao (2–5 giây)** | Trung bình | **Rất cao** | Công ty tài chính, bảo hiểm, điện/nước |
| Thu hộ tại quầy | Cao | Trung bình | Không cần tích hợp | Rất thấp | Nông thôn, khách hàng mặt tiền |
| QR Static | Trung bình | Cao | Thấp | Trung bình | Trường học, bệnh viện |
| QR Dynamic | **Cao** | **Cao** | Trung bình | Cao | E-commerce, doanh nghiệp vừa và lớn |
| Payment Gateway / Ví | Cao | Không 100% realtime | Trung bình | Cao | E-commerce, thu công cộng |

---

* **Tài khoản thanh toán**: dễ làm → nhưng không scale
    
* **VA**: mô hình mạnh nhất, chính xác nhất, phù hợp mọi ngành có số lượng giao dịch lớn
    
* **Quầy**: hữu ích nhưng không scale
    
* **QR payment**: xu hướng hiện nay, bổ sung/hoàn thiện VA
    
* **Payment Gateway**: đa kênh, tiện lợi, nhưng không realtime 100%