Bỏ qua menu, vào nội dung chính

Webhook là gì? Ứng dụng trong tích hợp hệ thống doanh nghiệp

Webhook là cách một hệ thống chủ động báo tin cho hệ thống khác ngay khi có sự kiện xảy ra, thay vì phải hỏi đi hỏi lại. VNPay báo thanh toán thành công, Zalo OA báo tin nhắn mới, e-invoice báo hoá đơn đã ký, đều chạy qua webhook. Giải thích cơ chế, khác gì với API thông thường, và những điều đội kỹ thuật cần làm đúng khi nhận webhook.

9 phút đọc

Nếu từng đọc tài liệu kỹ thuật của VNPay, Zalo OA hay một nhà cung cấp hoá đơn điện tử, gần như chắc chắn đã gặp từ "webhook" ở phần cấu hình tích hợp. Với người không làm kỹ thuật, đây thường là mục bị bỏ qua hoặc giao thẳng cho đội IT xử lý mà không hiểu nó làm gì. Bài này giải thích webhook theo cách một người quản lý cần biết: nó là gì, vì sao hệ thống hiện đại gần như bắt buộc phải dùng, và rủi ro nếu đội kỹ thuật làm sai.

Webhook là gì

Webhook là một cơ chế để hệ thống A tự động gửi thông báo tới hệ thống B ngay khi có một sự kiện xảy ra, bằng cách gọi tới một địa chỉ URL do B cung cấp trước. Ví dụ dễ hình dung nhất: khi khách hàng thanh toán thành công qua VNPay, VNPay sẽ tự gọi tới một URL trên website của doanh nghiệp (URL này gọi là "webhook endpoint") kèm thông tin đơn hàng, để website biết ngay lập tức mà cập nhật trạng thái đơn thành "đã thanh toán".

Điểm mấu chốt để hiểu webhook là so sánh với cách làm cũ: polling, tức là hệ thống B chủ động hỏi đi hỏi lại hệ thống A "có gì mới không" theo chu kỳ cố định, ví dụ mỗi 30 giây. Polling vừa tốn tài nguyên (hỏi hàng nghìn lần mà phần lớn câu trả lời là "không có gì mới"), vừa có độ trễ (phải chờ tới lượt hỏi tiếp theo mới biết tin). Webhook đảo ngược chiều: thay vì B đi hỏi, A chủ động báo ngay khi có chuyện, gần như tức thời.

Webhook khác API thông thường ở đâu

Webhook thực ra vẫn là một dạng gọi API, chỉ khác về chiều gọi và ai là người khởi xướng. Với API thông thường, doanh nghiệp là bên chủ động gọi sang hệ thống khác để lấy hoặc gửi dữ liệu khi cần, giống như việc nhấc điện thoại gọi hỏi. Với webhook, doanh nghiệp là bên ngồi chờ, và hệ thống đối tác sẽ chủ động gọi tới khi có tin, giống như việc để lại số điện thoại và chờ người ta gọi lại khi có kết quả.

  • API thông thường (outbound): doanh nghiệp chủ động hỏi, ví dụ gọi API tra cứu số dư ví điện tử.
  • Webhook (inbound): đối tác chủ động báo, ví dụ VNPay báo giao dịch thành công, Zalo OA báo có tin nhắn mới từ khách, nhà cung cấp e-invoice báo hoá đơn đã được cơ quan thuế cấp mã.
  • Nhiều tích hợp dùng cả hai chiều cùng lúc: doanh nghiệp gọi API để tạo giao dịch, rồi chờ webhook báo kết quả cuối cùng của giao dịch đó.

Vì sao doanh nghiệp cần biết webhook tồn tại, dù không code

Người quản lý không cần biết viết code xử lý webhook, nhưng nên biết ba điều để không bị động khi làm việc với vendor hoặc đội kỹ thuật nội bộ.

1. Webhook là lý do hệ thống "tự cập nhật" mà không cần ai bấm nút

Khi thấy đơn hàng tự chuyển trạng thái "đã thanh toán" mà không ai thao tác gì, hoặc thấy đơn hàng trên Zalo OA tự đồng bộ về hệ thống bán hàng, phần lớn trường hợp đó là webhook đang chạy phía sau. Nếu tính năng "tự động" này đột nhiên ngừng hoạt động, nguyên nhân thường không phải phần mềm bị lỗi ngẫu nhiên, mà là webhook endpoint bị gián đoạn, ví dụ do đổi domain, đổi hosting, hoặc chứng chỉ bảo mật (SSL) hết hạn.

2. Webhook là điểm cần bảo mật, không phải chỉ cần "chạy được"

Vì webhook endpoint là một URL công khai chờ nhận request, về lý thuyết bất kỳ ai biết địa chỉ đó cũng có thể gửi request giả tới, ví dụ giả một thông báo "thanh toán thành công" để lừa hệ thống giao hàng miễn phí. Đội kỹ thuật đúng chuẩn phải xác thực chữ ký (signature) hoặc mã bí mật (secret token) mà bên gửi webhook đính kèm, để chắc chắn request đến từ đúng VNPay, đúng Zalo, chứ không phải giả mạo. Khi làm việc với vendor phần mềm, đây là câu hỏi nên đặt ra: "webhook có xác thực chữ ký không, hay chỉ nhận và tin luôn".

3. Webhook có thể gửi trùng, hệ thống phải xử lý được

Do mạng có thể chập chờn, bên gửi webhook thường gửi lại (retry) nếu không nhận được phản hồi xác nhận kịp thời, dẫn tới khả năng cùng một sự kiện được báo hai, ba lần. Hệ thống nhận đúng chuẩn phải nhận diện được "sự kiện này đã xử lý rồi" để không cộng tiền hai lần, không gửi hàng hai lần. Đây là lỗi thực tế từng xảy ra ở nhiều doanh nghiệp làm tích hợp thanh toán vội, không lường trước trường hợp gửi trùng.

Phía kỹ thuật, cách phổ biến để không mất và không xử lý trùng sự kiện là đưa việc vào hàng đợi rồi xử lý dần với cơ chế thử lại; bài so sánh các hệ thống hàng đợi trên trancongthang.vn giúp đội phát triển chọn công cụ.

Webhook xuất hiện ở đâu trong hệ thống doanh nghiệp Việt Nam

  • Cổng thanh toán (VNPay, Momo, ZaloPay): báo kết quả giao dịch thành công hoặc thất bại.
  • Hoá đơn điện tử: báo hoá đơn đã được ký số và cấp mã từ cơ quan thuế.
  • Zalo OA: báo tin nhắn mới từ khách, báo trạng thái gửi ZNS thành công hoặc thất bại.
  • Đơn vị vận chuyển (GHN, GHTK, Viettel Post): báo trạng thái đơn hàng thay đổi, ví dụ đã lấy hàng, đang giao, giao thành công.
  • Công cụ nội bộ: hệ thống chấm công báo sự kiện check-in, hệ thống CI/CD báo build thành công để tự động deploy.

Tóm lại

Webhook không phải một sản phẩm để mua, mà là một cơ chế nằm bên trong hầu hết tích hợp hiện đại giữa doanh nghiệp và đối tác công nghệ (ngân hàng, ví điện tử, mạng xã hội, đơn vị vận chuyển). Hiểu đúng webhook giúp người quản lý đặt đúng câu hỏi khi nghiệm thu một hệ thống tích hợp, thay vì chỉ kiểm tra "có chạy được không" mà bỏ qua phần bảo mật và xử lý lỗi phía sau.

Nhận bài mới

Để lại email để nhận bài mới của series Khái niệm nền tảng, hoặc theo dõi bằng RSS.

RSS Khái niệm nền tảng

Email chỉ dùng để gửi bài mới, xem Chính sách bảo mật.

Trao đổi về dự án