Khách đến MONA đặt CRM, ERP hoặc phần mềm bán hàng thường chốt rất kỹ đơn, kho và công nợ, rồi tới lúc tiền vào lại để kế toán mở ứng dụng ngân hàng và gõ từng khoản. API ngân hàng lấp đúng chỗ hở đó: ngân hàng báo giao dịch cho hệ thống, phần mềm tự tìm đơn, đổi trạng thái và lưu dấu đối soát. Tụi em đã nhúng API ngân hàng nhận biến động ACB vào phần mềm giao khách từ năm 2022, nên bài này đi thẳng từ kiến trúc, code, phí tới các lỗi đội kỹ thuật phải chặn. Anh chị đọc xong sẽ biết đường nào đáng nối, chỗ nào tự làm được và cách thử MONA Pay mà chưa cần chuyển tiền thật. Luồng API ngân hàng này đã chạy 4 năm, bản viết kiểm ngày 03/09/2026. Đọc xong là bắt tay làm được.
API ngân hàng đóng khoảng trống giữa tiền vào và phần mềm
Trong một phần mềm bán hàng, đơn DH10234 đã có khách, sản phẩm, số tiền và trạng thái “chờ thanh toán”. Khách chuyển 2.500.000 đồng, điện thoại kế toán sáng lên, nhưng CRM vẫn đứng yên vì tin báo đó chưa thành dữ liệu mà phần mềm đọc được. Nhân viên phải nhìn số tiền, dò nội dung, bấm vào đơn rồi ghi thêm một dòng công nợ. Khoảng trống nằm ở đó, nên một API ngân hàng đúng việc phải biến tin báo đó thành sự kiện có cấu trúc.
API ngân hàng đưa sự kiện tiền vào tới máy chủ thay vì dừng ở màn hình của một người, vì vậy cùng một giao dịch có thể đổi trạng thái đơn, đẩy lệnh xuống kho, ghi sổ thu và báo nhóm kế toán trong vài giây. Khi tụi em làm phần mềm CRM theo quy trình riêng, câu hỏi phải chốt sớm là hệ thống sẽ tin dữ liệu nào: ảnh bill khách gửi, tin nhân viên nhập hay bản ghi từ ngân hàng. Với tiền thật, câu trả lời phải là bản ghi API ngân hàng. Ảnh bill chỉ để tham khảo. Bản ghi API ngân hàng mới là căn cứ.
MONA Pay là API ngân hàng và dịch vụ xác nhận thanh toán tự động của The MONA Group, giúp doanh nghiệp Việt Nam nhận và xác nhận tiền chuyển khoản theo thời gian thực qua tài khoản ảo (VA), VietQR, webhook và Telegram, thiết kế để cả lập trình viên lẫn AI agent tích hợp trong vài phút. Tiền đi từ tài khoản khách vào thẳng tài khoản đứng tên anh chị; API ngân hàng MONA Pay nhận thông báo giao dịch rồi chuyển dữ liệu sang phần mềm. Hệ thống không cần mật khẩu ngân hàng và không có quyền rút tiền. Đây là ranh giới tụi em giữ suốt 4 năm chạy thật, vì quyền ít thì rủi ro ít.
Phần nhận webhook cần làm chắc từ đầu: tụi em viết riêng bài webhook thanh toán và cách tích hợp cho web, phần mềm với code PHP, Node, Python và 5 lỗi hay gặp.
Giá trị của API ngân hàng không nằm ở tiếng “ting ting”. Một phần mềm quản lý đơn hàng chỉ thật sự bớt việc khi sự kiện tiền vào kéo được cả chuỗi phía sau: khóa transaction_code được lưu, số tiền được so với đơn, sai lệch đi vào hàng chờ, khoản đúng mới cho phép xuất hàng. Tụi em luôn tách “đã nhận thông báo” khỏi “đủ điều kiện hoàn tất đơn”, bởi hai trạng thái đó khác nhau về trách nhiệm. Máy báo, quy tắc quyết.
Ba đường lấy dữ liệu ngân hàng không có cùng chi phí và thời gian
Một đội kỹ thuật tìm API ngân hàng để đọc biến động số dư thường gặp ba đường. Đường đầu là làm việc trực tiếp với ngân hàng, hợp với công ty có hồ sơ pháp nhân, quy mô giao dịch lớn và người theo tới cùng các vòng pháp lý, bảo mật, kiểm thử. Đường thứ hai dùng một cổng nhận tiền hộ, hợp khi phần mềm cần thẻ, trả góp hoặc ngoại tệ. Đường thứ ba giữ tiền trong tài khoản của anh chị, còn API ngân hàng chỉ chuyển tin báo có sang hệ thống. Ba lựa chọn này thường tạo lịch triển khai chênh nhau từ vài ngày tới nhiều tháng.
Ba đường tạo ba cái giá, từ 0% trên số tiền tới phí tính theo phần trăm doanh thu. Hồ sơ API ngân hàng trực tiếp có lợi thế là quan hệ nằm giữa doanh nghiệp với ngân hàng, nhưng thời gian thường tính bằng tháng và mỗi ngân hàng có chuẩn kết nối riêng. Cổng nhận tiền hộ giải nhiều phương thức trong một hợp đồng, song phần mềm phải theo lịch đối soát và chịu phí trên giá trị giao dịch. API ngân hàng MONA Pay chọn việc hẹp hơn: chuyển khoản nội địa, tiền vào thẳng, 0% trên số tiền và một chuẩn dữ liệu cho nhiều ngân hàng.
| Đường tích hợp | Việc làm tốt | Chỗ phải trả giá | Khi tụi em khuyên chọn |
|---|---|---|---|
| Xin API trực tiếp từ ngân hàng | Quan hệ trực tiếp, điều khoản riêng theo quy mô | Hồ sơ doanh nghiệp, kiểm thử và thời gian chờ; thêm ngân hàng thường phải làm thêm tích hợp | Công ty lớn có người phụ trách ngân hàng và kế hoạch dài hạn |
| Cổng nhận tiền hộ | Thẻ, trả góp, ngoại tệ và nhiều phương thức | Phí phần trăm, lịch rút tiền, thêm một sổ đối soát | Sản phẩm thật sự cần thẻ hoặc bán ra nước ngoài |
| MONA Pay | VA, VietQR, webhook, Telegram; tiền về tài khoản của anh chị | Tập trung vào chuyển khoản nội địa; ngân hàng được nối theo lộ trình công khai | CRM, ERP và phần mềm bán hàng cần tự nhận tiền, tự khớp đơn |
Quan điểm của MONA là chọn đúng dụng cụ cho đúng việc. Anh chị thu 10 khoản mỗi tháng thì ứng dụng ngân hàng đã đủ, chưa cần API ngân hàng. Nếu khách quốc tế cần thẻ, hãy dùng cổng quốc tế đúng nghề. Khi một hệ thống ERP phải nhận 800 khoản chuyển khoản trong nước, API ngân hàng mới bắt đầu trả lại thời gian cho kế toán và giảm điểm gõ lại dữ liệu. Lúc đó số lần nhập tay đã thành chi phí vận hành.
Tụi em cũng không khuyên một đội mới dành 3 tháng xin API ngân hàng trực tiếp chỉ để chứng minh năng lực kỹ thuật. Phần tạo lợi thế cho phần mềm nằm ở quy tắc sau khi tiền tới: phân bổ công nợ, giữ tồn kho, mở quyền học, gia hạn dịch vụ, cảnh báo chuyển thiếu. API ngân hàng là hạ tầng. Hãy dành sức cho nghiệp vụ mà khách trả tiền.
MONA thiết kế API ngân hàng từ VA của từng đơn tới một dashboard nhiều ngân hàng
Từ năm 2022, tụi em tự xây API ngân hàng nhận biến động ACB để thu tiền cho chính MONA và nhúng vào phần mềm giao khách. Khách hàng mới của MONA đã đi qua luồng này từ trước; tới ngày 29/08/2026, sản phẩm mới mở public cho mọi doanh nghiệp dưới tên MONA Pay. Bốn năm đó cho tụi em đủ ca lỗi để kể. Đây cũng là lý do tụi em hiểu một bản tin tiền vào phải sống được qua lúc nhân viên đổi ca, máy chủ triển khai lại và đơn hàng bị gửi lại.
Ngày 03/09/2026, tụi em tạo một tài khoản API ngân hàng mới với vai chủ tiệm hoa, đi đủ wizard webhook 5 bước, tạo secret HMAC 48 ký tự, nối một nhóm Telegram, bật xác thực 2 lớp rồi hủy hóa đơn nâng gói vừa tạo. Chi tiết ngoài lề là màn hình lúc đó còn trống trơn, chẳng có giao dịch nào để nhìn cho vui; đổi lại, chính cái trống ấy buộc tụi em đọc từng lời nhắc giống hệt người đăng ký lần đầu. Trước khi chỉ anh chị bấm ở đâu, tụi em phải tự đi hết đường.
Tài khoản ảo, gọi tắt là VA, là số phụ gắn với tài khoản ngân hàng chính. Phần mềm bán hàng gán một VA cho đơn hoặc khách, tạo VietQR đúng số tiền và nội dung, sau đó lấy account_number trong webhook API ngân hàng để tìm bản ghi tương ứng. Cách này chắc hơn việc đoán từ nội dung chuyển khoản, vì khách hay bỏ dấu, viết thiếu mã hoặc dán nhầm ghi chú. Tụi em ưu tiên VA khi nghiệp vụ cho phép.
MONA Pay thiết kế API ngân hàng cho nhiều ngân hàng, nối nhiều tài khoản ở nhiều ngân hàng về một dashboard; ACB đang chạy trực tiếp, tụi em chạy thật với ACB từ 2022, các ngân hàng khác đang nối thêm theo lộ trình, bảng trạng thái tại trang ngân hàng MONA Pay. Payload chung vẫn có bank_name, account_number, amount và transaction_code, vì vậy thêm nguồn ngân hàng không bắt CRM sửa cả luồng. Không viết lại từ đầu.
Một dự án triển khai ERP thường sống lâu hơn hợp đồng ngân hàng ban đầu, nên lớp API ngân hàng phải tránh gắn chặt nghiệp vụ với tên một nhà cung cấp. Adapter ngân hàng đổi ở ngoài, cấu trúc giao dịch giữ ổn định ở trong. Đây là lựa chọn kiến trúc tụi em dám chốt: phần mềm đọc chuẩn API ngân hàng chung của MONA Pay, còn lịch nối từng ngân hàng nằm ở lớp hạ tầng.
VA, webhook HMAC và transaction_code tạo thành một chuỗi đối soát
Một khoản tiền 2.500.000 đồng đi qua chuỗi API ngân hàng rõ ràng: ngân hàng ghi có, MONA Pay lưu giao dịch, cấu hình webhook đúng phạm vi được chọn, máy chủ CRM nhận JSON rồi kiểm chữ ký. Payload API ngân hàng có 7 trường chính gồm số tiền, nội dung, thời gian, mã giao dịch, tài khoản nhận, tên ngân hàng và loại giao dịch. Sau bước kiểm, phần mềm trả HTTP 200, 201 hoặc 202 trong 10 giây. Thứ tự này rất quan trọng. Sai thứ tự, log sẽ đẹp mà đơn vẫn hỏng.
Wizard API ngân hàng trên dashboard chia cấu hình thành 5 bước: tên và URL, phạm vi tài khoản, kiểu bảo mật, định dạng payload, kiểm lại rồi lưu. Tụi em khuyên trỏ thẳng tới URL HTTPS cuối; một địa chỉ còn chuyển hướng từ HTTP sang HTTPS hoặc tự thêm dấu gạch chéo sẽ bị ghi nhãn HTTP_3XX. Sau khi lưu, nút gửi thử cho biết mã HTTP, thời gian phản hồi và nhãn lỗi. Đừng chờ tiền thật để thử.
Với HMAC-SHA256, API ngân hàng MONA Pay đặt mốc unix giây vào X-Mona-Timestamp và chữ ký vào X-Mona-Signature. Server tính HMAC trên timestamp, một dấu chấm và raw body, so bằng hàm thời gian cố định rồi từ chối gói lệch quá 300 giây. Raw body nghĩa là đúng từng byte vừa nhận; parse JSON rồi tạo chuỗi lại dễ đổi khoảng trắng hoặc thứ tự khóa. Đây là lỗi tụi em soi đầu tiên khi chữ ký cứ sai dù secret nhìn đúng. Mỗi cấu hình dùng một secret riêng.
| Lớp dữ liệu | Khóa dùng | Quy tắc xử lý | Điều cần tránh |
|---|---|---|---|
| Định danh người trả | account_number của VA | Tìm đơn, khách hoặc hợp đồng đã gán VA | Chỉ đoán bằng tên trong nội dung |
| Xác nhận nguồn gửi | X-Mona-Signature | Tính HMAC-SHA256 trên raw body | Parse JSON trước khi kiểm |
| Chống phát lại | X-Mona-Timestamp | Chấp nhận trong cửa sổ 300 giây | Để giờ máy chủ lệch |
| Chống ghi trùng | transaction_code | Đặt UNIQUE trong cơ sở dữ liệu | Dùng số tiền cộng thời gian làm khóa |
| Hoàn tất đơn | amount và trạng thái đơn | So tiền, loại giao dịch rồi mới cập nhật | Giao hàng ngay khi vừa nhận JSON |
transaction_code của API ngân hàng giữ nguyên qua mọi lần gửi lại, nên cột này phải có ràng buộc UNIQUE. Hai khách chuyển cùng 500.000 đồng trong 1 phút là chuyện bình thường; ghép số tiền với thời gian sẽ đụng nhau. Khi tụi em nối API ngân hàng vào phần mềm kế toán bán hàng, webhook và tác vụ đối soát gọi chung một hàm xử lý, nhờ vậy cùng mã giao dịch gửi 3 lần vẫn chỉ ghi doanh thu một lần. Một khóa, một lần ghi.
Code PHP và Node cần ngắn, còn đường xử lý lỗi phải đủ
Đội dev không cần dựng cả thư viện mới để nhận webhook API ngân hàng. PHP thuần chỉ việc đọc php://input, kiểm cửa sổ 300 giây, tính chữ ký rồi trả 200; Node.js 18 trở lên dùng @monapay/node phiên bản 0.3.0 để kiểm raw body. Code ngắn chưa đủ. Phần quan trọng của API ngân hàng nằm ở ràng buộc dữ liệu, hàng đợi, nhật ký và tác vụ đối soát khi server vắng mặt đúng lúc tiền vào.
<?php
$raw = file_get_contents('php://input');
$headers = getallheaders();
$ts = $headers['X-Mona-Timestamp'];
$sig = $headers['X-Mona-Signature'];
$key = getenv('MONA_WEBHOOK_SECRET');
if (abs(time() - (int) $ts) > 300) { http_response_code(400); exit; }
$exp = 'sha256=' . hash_hmac('sha256', $ts . '.' . $raw, $key);
if (!hash_equals($exp, $sig)) { http_response_code(401); exit; }
http_response_code(200); echo 'OK';
// Đẩy JSON sang hàng đợi; INSERT IGNORE theo transaction_code.
import express from 'express';
import { expressWebhook } from '@monapay/node';
const app = express();
app.post('/webhooks/monapay', express.raw({ type: 'application/json' }),
expressWebhook(process.env.MONA_WEBHOOK_SECRET, async (payload, req, res) => {
res.status(200).json({ ok: true });
await queue.add('monapay', payload); // upsert theo transaction_code
})
);
Gói Python monapay trên PyPI cũng ở phiên bản 0.3.0 và có hàm verify_webhook(raw_body, headers, secret) dành cho API ngân hàng. Chọn SDK theo nền hiện có, đừng thêm một dịch vụ riêng chỉ vì ví dụ trên mạng dùng ngôn ngữ khác. Tụi em thích để route nhận tiền càng mỏng càng tốt: kiểm, ghi nhận đã nhận, đẩy hàng đợi. Mọi email, cập nhật kho và gọi dịch vụ khác chạy phía sau.
| Dấu hiệu | Nguyên nhân hay gặp | Cách xử lý dứt điểm |
|---|---|---|
TIMEOUT | Route làm việc nặng trước khi trả lời, chạm mốc 10 giây | Trả 200 trước, đẩy cập nhật đơn sang hàng đợi |
HTTP_3XX | URL chuyển hướng sang HTTPS hoặc thêm dấu gạch chéo | Dùng thẳng URL đích cuối |
| Chữ ký sai | Framework đã parse JSON hoặc giờ máy lệch hơn 300 giây | Đọc raw body, bật NTP, so chữ ký bằng hàm timing-safe |
| Đơn cập nhật hai lần | Không có UNIQUE trên transaction_code | Upsert hoặc INSERT IGNORE trước mọi nghiệp vụ |
| Tiền có trên ngân hàng, CRM chưa có | Server bảo trì lúc webhook gửi | Chạy đối soát mỗi 15 phút hoặc mỗi giờ, tối đa 100 giao dịch mỗi trang |
Đối soát API ngân hàng là lưới đỡ, không phải công việc cuối tháng mới nhớ. API trả tối đa 100 giao dịch mỗi trang; tác vụ đi từ trang 1, chèn mã chưa có, dừng khi gặp trang không còn mã mới và ghi lại số khoản bổ sung. Với hệ thống bán hàng online giao ngay, lịch API ngân hàng 15 phút hợp lý hơn một lần cuối ngày. Tụi em không giao phần mềm nhận tiền nếu thiếu đường kéo lại dữ liệu.
AI agent nối API ngân hàng qua MCP mà không cầm mật khẩu
Luồng API ngân hàng dành cho agent bắt đầu ở dashboard, mục API Keys, rồi bấm Tạo key. Màn hình hiện client_id, client_secret và sẵn lệnh cài MCP; secret chỉ hiện một lần nên đội kỹ thuật phải đưa thẳng vào biến môi trường. Agent không cầm mật khẩu. Nó dùng POST /api/v1/oauth/token để đổi client credentials ra Bearer token hạn 3.600 giây, hết hạn thì tự lấy token khác. TOTP của người vận hành vẫn được giữ nguyên.
claude mcp add monapay -e MONAPAY_CLIENT_ID=client_xxx -e MONAPAY_CLIENT_SECRET=xxx -- npx -y monapay-mcp
MCP 0.3.0 có 22 tool API ngân hàng, đủ để kiểm tài khoản, xem gói, liệt kê VA, tạo QR, cấu hình webhook, đọc log, gửi lại giao dịch và sinh code mẫu. Từ bản này, agent còn nối ngân hàng bằng OTP ngay trong khung chat: nó hỏi số tài khoản, số điện thoại, loại chủ tài khoản và phần định danh VA; ngân hàng gửi OTP về máy của anh chị, anh chị nhập mã để agent gọi bước xác minh. Quy trình lặp lại một lần nữa cho đăng ký thông báo. OTP vẫn ở phía chủ tài khoản.
Cách làm đó hợp với trưởng nhóm kỹ thuật muốn đưa API ngân hàng vào cùng phiên code, vì agent đọc llms.txt, openapi.json và tài liệu xác thực API ngân hàng trước khi sửa dự án. Nó tạo route webhook, thêm UNIQUE cho transaction_code, đăng ký URL rồi gọi sandbox. Lập trình viên vẫn review phần tiền và bảo mật trước khi lên production. Agent làm nhanh phần lặp, người giữ quyết định.
Prompt giao API ngân hàng cho agent
Tích hợp MONA Pay vào CRM hiện có. Đọc https://monapay.vn/llms-full.txt và openapi.json. Tạo endpoint POST /webhooks/monapay, kiểm X-Mona-Signature trên raw body, từ chối timestamp lệch quá 300 giây, đặt transaction_code UNIQUE, trả HTTP 200 trước khi cập nhật đơn. Lấy client_id, client_secret và secret HMAC từ biến môi trường; không ghi khóa vào mã nguồn.
Sau khi endpoint chạy, đăng ký webhook HMAC_SHA256 bằng API, bắn thử payload DUMMY123 và đọc webhook log. Tiếp theo gọi POST /api/v1/sandbox/transactions với amount 10000, description DH10234 test sandbox. Không tạo đơn từ DUMMY123 và báo lại mã HTTP, duration_ms, error_label.
Nối tài khoản ngân hàng bằng tool MCP trong cuộc trò chuyện. Hỏi từng dữ liệu cần thiết, dừng để tôi nhập OTP ở hai bước xác minh, không tự đoán hoặc lưu OTP. Sau khi nối xong, tạo VA cho đơn thử, gửi sandbox và đối soát transaction_code giữa MONA Pay với bảng giao_dich.
Trang MONA Pay cho AI agent ghi trọn lệnh cài, prompt và bản đồ tài liệu API ngân hàng. Sandbox dùng POST /api/v1/sandbox/transactions, tạo giao dịch giả rồi bắn webhook cùng Telegram như tiền thật nhưng không tính hạn mức gói. Tụi em khuyên chạy ít nhất ba ca API ngân hàng: tiền đúng, tiền thiếu và cùng transaction_code gửi lại. Thử cho ra lỗi trước.
Đừng để phần nhận tiền đứng ngoài bản thiết kế phần mềm
Nếu CRM hoặc ERP đang chuẩn bị bàn giao mà kế toán vẫn phải gõ lại 800 khoản mỗi tháng, hãy mở một key miễn phí, cho agent dựng endpoint và chạy sandbox 10.000đ trước. Chưa cần chuyển tiền thật, anh chị đã nhìn được chữ ký, log và cách đơn đổi trạng thái.
Phí API ngân hàng phải tính theo đường tiền, không nhìn mỗi giá gói
Chữ “miễn phí” dễ làm người đọc bỏ qua phần tốn tiền thật. Chuyển khoản VietQR vốn là đường tiền 0đ ở phía khách theo chính sách ngân hàng phổ biến; bài của Báo Điện tử Chính phủ ngày 05/02/2024 cũng ghi giao dịch chuyển mạch dưới 1 triệu đồng đã được NAPAS miễn phí toàn bộ, chiếm khoảng 65% số lượng giao dịch qua hệ thống tại thời điểm công bố. MONA Pay thu phí phần mềm theo số khoản nhận, không cắt phần trăm doanh thu. Phần trăm mới đáng sợ.
Biểu phí thương mại điện tử VietinBank hiệu lực 22/04/2026, chưa VAT, cho thấy thẻ nội địa nối trực tiếp ở mức 0,5–0,7%; đường gián tiếp là 1,09% + 1.818đ mỗi giao dịch. Visa hoặc Mastercard phát hành trong nước ở mức 1,818–2,182% + 4.200đ; thẻ phát hành nước ngoài là 3,7–3,8% + 4.500đ, kèm 700.000đ mỗi tháng duy trì cổng quốc tế. Đây là giá của đường thẻ, có chức năng khác chuyển khoản.
Với PayPal, trang phí người bán kiểm ngày 28/05/2026 ghi giao dịch thương mại quốc tế 4,40% + 0,30 USD, rút về tài khoản ngân hàng Việt Nam 60.000đ mỗi lần và nhóm quy đổi tiền tệ ở mức 4%. PayPal hợp khi nhận tiền quốc tế bằng hệ sinh thái của hãng. Một phần mềm chỉ thu tiền đồng trong nước mà gánh phí đó là dùng sai đường.
| Đường tiền | Phí công bố | Khoản khác | Việc đúng |
|---|---|---|---|
| Thẻ nội địa, nối trực tiếp | 0,5–0,7% | Theo hợp đồng ngân hàng | Đơn vị đã có kết nối thẻ trực tiếp |
| Thẻ nội địa, nối gián tiếp | 1,09% + 1.818đ/GD | Chưa VAT | Thu thẻ nội địa qua cổng |
| Visa/Mastercard trong nước | 1,818–2,182% + 4.200đ/GD | Chưa VAT | Khách cần trả bằng thẻ |
| Visa/Mastercard nước ngoài | 3,7–3,8% + 4.500đ/GD | 700.000đ/tháng duy trì cổng, chưa VAT | Bán quốc tế qua thẻ |
| PayPal quốc tế | 4,40% + 0,30 USD | Rút 60.000đ/lần; quy đổi 4% | Nhận tiền quốc tế qua PayPal |
| Chuyển khoản qua MONA Pay | 0% + 0đ trên giá trị tiền | Gói phần mềm tính theo số khoản | Phần mềm tự xác nhận chuyển khoản nội địa |
Lấy ví dụ một phần mềm bán hàng thu 200 triệu đồng qua 800 giao dịch mỗi tháng, trung bình 250.000đ một khoản. Thẻ nội địa qua cổng gián tiếp tốn khoảng 3.634.400đ; Visa/Mastercard trong nước theo mức 1,818% tốn khoảng 6.996.000đ; thẻ nước ngoài mức 3,7% tốn khoảng 11.700.000đ khi cộng phí xử lý và duy trì. MONA Pay dùng gói Khởi nghiệp 99.000đ cho 2.000 khoản. Chênh lệch này không nói thẻ xấu; nó nói phần mềm thu chuyển khoản đừng trả tiền cho đường thẻ chưa dùng.
Bảng giá MONA Pay ngày 03/09/2026 gồm 0đ cho 500 khoản mỗi tháng; 99.000đ cho 2.000 khoản; 299.000đ cho 10.000 khoản; 799.000đ cho 50.000 khoản; 1.990.000đ cho 300.000 khoản. Trả năm bằng 10 tháng. Khách đang làm web, phần mềm hoặc hosting tại MONA được miễn phí hoàn toàn, nên khi đặt phần mềm viết theo yêu cầu, anh chị hãy đưa đầu việc nhận tiền vào phạm vi bàn giao ngay từ đầu.
Từ bán lẻ, F&B tới giáo dục và SaaS, mỗi phần mềm khớp tiền bằng một khóa khác
Cùng một API ngân hàng báo có, nghiệp vụ sau đó không giống nhau. Shop online quan tâm mã đơn và tồn kho; nhà hàng cần giữ bàn hoặc xác nhận cọc; trung tâm đào tạo nhìn học viên, kỳ thu và loại phí; SaaS gia hạn tài khoản theo hóa đơn. Mỗi ngành một khóa, nhưng transaction_code phải bảo đảm giao dịch gửi lại 3 lần vẫn chỉ ghi doanh thu 1 lần. Nếu đội phát triển chỉ viết “có tiền thì chuyển đơn sang hoàn tất”, phần mềm sẽ chạy đẹp trong bản thử rồi vướng ngay ca chuyển thiếu, chuyển gộp hoặc chuyển sai kỳ.
| Ngành | Khóa khớp tiền | Việc phần mềm tự làm | Ca để người duyệt |
|---|---|---|---|
| Bán lẻ | VA hoặc mã đơn | Đổi trạng thái, giữ tồn, phát lệnh đóng gói | Thiếu tiền, thừa tiền, đơn đã hủy |
| F&B | Mã bàn, phiếu cọc, đơn giao | Xác nhận bàn hoặc đơn, báo thu ngân | Khách đổi giờ, gộp nhiều bàn |
| Giáo dục | VA học viên và kỳ thu | Ghi học phí, phát biên nhận, mở quyền học | Chuyển sai kỳ hoặc gộp anh em |
| Spa | Mã lịch và số tiền cọc | Giữ khung giờ, báo lễ tân theo topic | Cọc thấp hơn quy định, đổi dịch vụ |
| SaaS | Mã hóa đơn tháng | Gia hạn tài khoản, ghi ngày hết hạn mới | Chuyển gộp nhiều hóa đơn |
| CRM/ERP B2B | Hợp đồng, đợt thanh toán, VA khách | Phân bổ công nợ, báo sale và kế toán | Tiền không khớp đợt nghiệm thu |
Trong phần mềm quản lý bán hàng, tụi em thường tách ba trạng thái “ngân hàng đã ghi có”, “đơn khớp đủ tiền” và “được phép xuất kho”. Một giao dịch vào là sự thật tài chính; quyền xuất hàng còn phải xét số tiền, đơn có còn hiệu lực và kho có giữ đúng món hay không. Cách tách này làm báo cáo sạch hơn khi khách chuyển thừa 20.000đ hoặc chuyển vào đơn đã hủy. Đừng ép một cờ gánh ba nghĩa.
Với phần mềm quản lý nhà hàng, Telegram theo topic hữu ích vì thu ngân, quản lý ca và kế toán cùng thấy khoản cọc mà không phải chia mật khẩu ứng dụng ngân hàng. Với phần mềm trung tâm ngoại ngữ, VA cố định theo học viên giúp khoản thu tháng sau vẫn về đúng hồ sơ, rồi phần mềm hỏi thêm kỳ học và loại phí. Tụi em để giao dịch mơ hồ vào hàng chờ, không cho máy tự đoán.
Ở hệ thống quản lý spa, webhook giữ lịch ngay sau khi cọc đủ, trong khi lễ tân nhận tin để xử lý yêu cầu đổi giờ. Một phần mềm shop hoa lại cần đẩy đơn sang khâu bó hoa và giao vận trước giờ hẹn. SaaS thì gia hạn quyền dùng, nhưng giao dịch gộp hai hóa đơn phải chờ tách. API ngân hàng đưa cùng một tín hiệu sạch; phần mềm theo ngành quyết định hành động.
Bảo mật API ngân hàng bắt đầu từ quyền không chạm tới tiền
Kiến trúc an toàn bắt đầu bằng việc giảm quyền. Tiền nằm ở tài khoản ngân hàng đứng tên anh chị; MONA Pay nhận thông báo, không giữ tiền, không xin mật khẩu và không có lệnh chuyển hoặc rút. API key cho máy chủ chỉ mở quyền gọi API trong phạm vi tài khoản, còn secret HMAC chỉ dùng để xác minh payload gửi sang CRM. Quyền phải được chia nhỏ: webhook từ chối bản tin lệch quá 300 giây và phần mềm trả HTTP 200 trong 10 giây rồi mới xử lý nghiệp vụ.
Tài khoản dashboard bật được xác thực hai lớp TOTP bằng QR và sinh 10 mã dự phòng. Máy chủ hoặc agent gọi API ngân hàng bằng client credentials vẫn đổi token được mà không cần OTP, vì đây là danh tính máy tách khỏi phiên đăng nhập của người. Tụi em khuyên mỗi môi trường có key riêng, secret nằm trong kho biến môi trường, key lộ thì thu hồi và tạo lại. Đừng chụp màn hình secret gửi vào nhóm chat.
Ở lớp webhook, HMAC-SHA256, cửa sổ 300 giây, HTTPS và UNIQUE trên transaction_code xử lý bốn rủi ro khác nhau: giả nguồn, phát lại gói cũ, nghe lén đường truyền và ghi trùng. Với giao dịch giá trị lớn, phần mềm còn gọi API đối soát trước khi giao hàng. Tụi em không xem IP whitelist là lớp xác thực chính, vì proxy và cấu hình header có thể làm địa chỉ nguồn bị hiểu sai. HMAC mới xác nhận nội dung.
Có ba lúc tụi em khuyên đừng dùng MONA Pay làm đường chính. Anh chị cần thẻ, trả góp hoặc ngoại tệ thì hãy dùng cổng thẻ; ngân hàng đang dùng chưa có trạng thái hoạt động trên bảng công khai và công ty không muốn mở thêm tài khoản nhận tiền thì chờ lộ trình; hệ thống chỉ có vài khoản thu mỗi tháng thì Telegram hoặc ứng dụng ngân hàng đã đủ. Tư vấn kỹ thuật phải nói rõ cả lúc không cần mua.
MONA cũng không khuyên ráp công cụ kéo thả thành đường tiền production. Bản thử cá nhân làm rất nhanh, nhưng luồng thật cần log, hàng đợi, cảnh báo, đối soát và người chịu trách nhiệm khi API đổi. Một mắt xích cấu hình sai là đơn dừng cập nhật, trong khi người dựng luồng ban đầu đã chuyển sang việc khác. Phần mềm viết riêng gắn với quản lý thu chi phải tự động hóa tới gốc, không chắp thêm lớp ngoài rồi để kế toán canh.
Câu hỏi thường gặp về API ngân hàng cho phần mềm
API ngân hàng khác webhook thanh toán ở đâu?
API ngân hàng là tập hợp endpoint để phần mềm chủ động tạo VA, tạo QR, đọc giao dịch hoặc cấu hình. Webhook là chiều ngược lại: MONA Pay chủ động POST tin báo có tới URL của anh chị ngay khi ngân hàng gửi dữ liệu. Một hệ thống chắc tay dùng webhook cho thời gian thực và API cho đối soát định kỳ, vì hai chiều bổ sung nhau.
Một dashboard nối nhiều tài khoản ngân hàng được không?
Có, kiến trúc API ngân hàng MONA Pay gom nhiều tài khoản ở nhiều ngân hàng về cùng dashboard và giữ payload chung cho phần mềm. ACB đang chạy trực tiếp từ nền tụi em dùng thật năm 2022; các ngân hàng khác nối thêm theo lộ trình tại trang trạng thái. Khi nguồn mới hoạt động, CRM đọc trường bank_name mà không đổi cấu trúc xử lý. Một dashboard là đủ.
Không có website thì nhận tự động báo có được không?
Được. Anh chị nối ngân hàng qua API ngân hàng MONA Pay, thêm bot vào nhóm Telegram, chọn nhóm hoặc topic rồi bấm gửi thử; khi tiền vào, người phụ trách thấy số tiền, thời gian và nội dung. Website hoặc phần mềm chỉ cần khi muốn tự đổi đơn, phân bổ công nợ hay mở quyền. Bắt đầu bằng Telegram vẫn là chạy thật.
Webhook hụt thì giao dịch có mất không?
Giao dịch vẫn nằm trong dashboard. Đội kỹ thuật xem lịch sử gửi, bấm gửi lại và chạy tác vụ đối soát qua API mỗi 15 phút, mỗi giờ hoặc cuối ngày theo độ gấp của nghiệp vụ. transaction_code giữ nguyên qua các đường, nên bảng có UNIQUE sẽ nhận bổ sung mà không ghi trùng. Sổ ngân hàng vẫn là gốc.
Đưa việc gõ tiền vào ra khỏi CRM, ERP từ một giao dịch thử
Một tích hợp gọn bắt đầu bằng phạm vi nhỏ: tạo API key, nối tài khoản bằng 2 lượt OTP, cho Telegram nhận tin, dựng endpoint theo wizard 5 bước rồi chạy sandbox 10.000đ. Bắt đầu bằng giao dịch thử. Khi log trả HTTP 200 dưới 10 giây, đội kỹ thuật kiểm tiếp chữ ký sai, tiền thiếu và gói gửi lại. Tụi em muốn lỗi xuất hiện ở bản thử, trước lúc kế toán chờ một khoản thật.
Nếu anh chị đang tự xây CRM, đọc cách CRM tổ chức dữ liệu khách hàng rồi đặt VA vào đúng hồ sơ; với SaaS, phần quản lý thuê bao và gia hạn phải dùng mã hóa đơn riêng. Nếu phần mềm do MONA làm, tụi em gắn API ngân hàng MONA Pay vào phạm vi bàn giao và cấp gói miễn phí hoàn toàn trong thời gian anh chị còn dùng dịch vụ MONA. Không cần để một nhân viên gõ lại thứ máy đã biết.
800 khoản tiền vào mỗi tháng không nên thành 800 lần gõ lại
Anh chị đã trả tiền làm CRM hoặc ERP để dữ liệu chạy xuyên bộ phận, vậy đừng chừa riêng khâu nhận tiền cho kế toán dò sao kê. Với ví dụ 200 triệu đồng và 800 khoản thu, MONA Pay chỉ cần gói 99.000đ; khách phần mềm MONA được miễn phí hoàn toàn và tụi em nối thẳng vào luồng đơn hiện có.
Tạo tài khoản ngay, chạy một giao dịch sandbox và đem log cho đội kỹ thuật xem. Nếu muốn tụi em ngồi cùng để chốt VA, webhook và quy tắc đối soát, gọi 1900 636 648.
Qua hơn 14.000 dự án của The MONA Group từ năm 2016, MONA thấy một phần mềm chỉ đáng bàn giao khi nó bớt được một việc thật, có log để lần lại và có người chịu trách nhiệm lúc lỗi. API ngân hàng biến tiền vào thành dữ liệu để CRM, ERP và phần mềm bán hàng tự xác nhận chuyển khoản, còn tiền vẫn nằm trong tài khoản của anh chị. Hãy mở tài liệu webhook MONA Pay, chạy sandbox ngay hôm nay; cần cùng thiết kế luồng thì gọi 1900 636 648 hoặc viết tới [email protected].





















































