Kiến trúc nền tảng
Một lõi, nhiều bề mặt — nền tảng thực sự vận hành như thế nào.
Hành trình xuyên suốt nền tảng, từ sổ cái trở lên: tài khoản, KYC, thẻ và crypto cùng dùng chung một lõi bút toán kép; cách một giao dịch thanh toán đi từ lúc tạo đến khi đối soát; và vị trí của lớp ứng dụng, bảng điều khiển vận hành cùng ranh giới được cấp phép.
Lõi hệ thống
Một sổ cái cho mọi thứ.
Trung tâm của nền tảng là một sổ cái tài khoản duy nhất. Mỗi tài khoản — ví khách hàng, số dư merchant, tài khoản phí, tài khoản quyết toán — là một nút trên sổ cái đó, và mọi biến động giá trị đều là một bút toán kép: một tài khoản ghi nợ, một tài khoản ghi có, hai vế luôn bằng nhau. Sổ cái chỉ ghi thêm (append-only). Bút toán không bao giờ bị sửa hay xóa; một điều chỉnh là một bút toán đối ứng mới, nên toàn bộ lịch sử hình thành số dư hiện tại luôn có thể dựng lại. Tài khoản, trạng thái KYC, thẻ đã phát hành và địa chỉ crypto đều gắn vào cùng một mô hình tài khoản, vì vậy một giao dịch ủy quyền thẻ, một lệnh chuyển khoản ngân hàng và một khoản nạp on-chain có thể hạch toán vào cùng một số dư mà không cần lớp đối soát để chắp nối các hệ thống riêng lẻ.
- 01Bút toán kép: mọi bút toán đều cân, tổng nợ bằng tổng có
- 02Append-only: điều chỉnh là bút toán mới, không bao giờ sửa
- 03Một mô hình tài khoản cho tiền pháp định, thẻ và crypto
- 04Trạng thái KYC đi cùng tài khoản, không nằm ở bảng phụ
Một giao dịch thanh toán, từ đầu đến cuối
Một giao dịch thanh toán, từ tạo đến đối soát.
Một giao dịch thanh toán không phải một lệnh gọi mà là một vòng đời ngắn, và mỗi giai đoạn là một trạng thái mà cả sổ cái lẫn hệ thống của bạn đều thấy. Mỗi thay đổi trạng thái đều phát một webhook, và mọi thao tác ghi đều idempotent — cùng một key luôn cho cùng một kết quả, nên yêu cầu gửi lại không bao giờ trừ tiền hai lần.
- 01
Tạo
Một intent được mở: số tiền, loại tiền tệ, các tài khoản liên quan. Chưa có gì được chuyển — sổ cái ghi một bút toán chờ xử lý.
- 02
Ủy quyền
Rail kiểm tra số dư và rủi ro rồi đặt giữ tiền. Với thẻ, đây là bước ủy quyền; với chuyển khoản, khoản ghi nợ được giữ chỗ.
- 03
Capture
Số tiền đang giữ được chốt. Sổ cái hạch toán bút toán kép thực sự chuyển giá trị giữa hai tài khoản.
- 04
Quyết toán
Tiền được thanh khoản qua rail nền tảng — card scheme, ngân hàng hoặc chain — và các tài khoản quyết toán đối soát với tiền thật.
- 05
Đối soát
Nền tảng đối chiếu các bút toán của mình với báo cáo quyết toán của rail; khoản nào không khớp sẽ được gắn cờ, không bị che giấu.
Webhook và idempotency hiện diện ở mọi điểm biên của luồng này. Hệ thống của bạn biết một khoản thanh toán đã chuyển nhờ nhận được sự kiện, không phải polling, và mọi yêu cầu bạn gửi lại sau khi timeout đều được xử lý — qua idempotency key — về cùng một kết quả, nên lần lặp lại không bao giờ trừ tiền hai lần. Dịch vụ chạy authorize và capture là payment gateway.
Lớp ứng dụng
Ứng dụng whitelabel ở trên, một nền tảng duy nhất bên dưới.
Lõi cung cấp các năng lực; lớp ứng dụng biến chúng thành sản phẩm. Mỗi ứng dụng hướng đến khách hàng — web và di động — là một client whitelabel hiển thị cùng các tài khoản, thanh toán và thẻ theo thương hiệu riêng. Giao diện được điều khiển bằng token: màu sắc, kiểu chữ, độ bo góc và khoảng cách đều đến từ một hệ thống design token (PDS), nên nhà vận hành đổi toàn bộ giao diện chỉ bằng cách thay token, không cần fork ứng dụng. Cùng một nền tảng có thể đi theo những hướng rất khác nhau — neobank cho người dùng cá nhân, ứng dụng acquiring cho merchant, chương trình phát hành thẻ, on/off-ramp crypto hay công cụ vận hành nội bộ — mà không trở thành năm sản phẩm riêng biệt. Đó là một nền tảng khoác nhiều diện mạo, mỗi diện mạo được cấu hình chứ không phải xây lại.
- 01Client whitelabel web + di động trên API dùng chung
- 02Theme theo token (PDS): đổi giao diện bằng cấu hình, không cần fork
- 03Năm hướng minh họa — neobank, acquiring, issuing, ramp, ops
- 04Bề mặt mới được cấu hình, không phải xây lại
Vận hành
Điều hành từ console, mỗi thao tác đều có lý do được ghi lại.
Đằng sau mỗi ứng dụng là một bảng điều khiển vận hành. Đây là nơi nhân viên hỗ trợ tra cứu tài khoản, chuyên viên rủi ro đóng băng thẻ, hay trưởng bộ phận vận hành đảo một bút toán. Quyền xem rộng; quyền thao tác đặc quyền thì không. Mọi hành động liên quan đến chuyển tiền, thay đổi hạn mức hoặc chạm vào tiền của khách hàng đều yêu cầu nêu lý do trước khi thực thi và ghi một bản kiểm toán bất biến — ai thực hiện, trên đối tượng nào, khi nào và vì sao. Quyền truy cập tuân theo nguyên tắc đặc quyền tối thiểu, nên mỗi nhân viên vận hành chỉ thấy và làm được những gì vai trò của họ cho phép. Đây là mô hình trong Protocore Center, bảng điều khiển vận hành, và cùng nguyên tắc ấy được xây vào mọi hệ thống trên nền tảng: các hành động nhạy cảm đều có chủ đích, truy vết được và có thể rà soát lại sau đó.
- 01Xem rộng, ghi có kiểm soát — thao tác đặc quyền là ngoại lệ
- 02Bắt buộc nêu lý do trước mọi thao tác liên quan đến tiền
- 03Nhật ký kiểm toán bất biến: ai, việc gì, khi nào, vì sao
- 04Đặc quyền tối thiểu theo từng vai trò vận hành
Cầu nối crypto
Crypto và tiền pháp định trên cùng một sổ cái.
Crypto không phải một silo tách biệt trên nền tảng; địa chỉ crypto chỉ là một tài khoản khác trên cùng sổ cái. On/off-ramp chuyển đổi giữa tiền pháp định và tài sản số ở biên — khách hàng nạp số dư bằng thẻ hoặc chuyển khoản rồi nhận crypto, hoặc bán crypto và rút về tài khoản ngân hàng. Giá trị on-chain có thể được quyết toán xuyên sang kênh ngân hàng: một khoản thanh toán on-chain đến được ghi có vào tài khoản, quy đổi, rồi chi trả về một IBAN, nên người nhận thấy tiền thông thường trong một tài khoản ngân hàng thông thường. Vì cả hai chặng đều hạch toán vào một sổ cái bút toán kép, một giao dịch bắt đầu on-chain và kết thúc bằng chuyển khoản ngân hàng là một lịch sử đối soát liền mạch, chứ không phải hai hệ thống phải đối soát thủ công.
- 01Địa chỉ crypto là một tài khoản như mọi tài khoản khác
- 02On/off-ramp: chuyển đổi tiền pháp định và tài sản số ở biên
- 03Quyết toán on-chain xuyên đến chi trả về IBAN
- 04Một lịch sử đối soát xuyên suốt cả hai chặng
Bề mặt tích hợp
API, webhook và sandbox để bạn xây dựng.
Mọi việc các ứng dụng làm đều thực hiện qua một API có tài liệu — tạo tài khoản, mở thanh toán, phát hành thẻ, khởi tạo ramp. Các lệnh gọi minh họa như POST /v1/wallets hay POST /v1/payments; kiểu REST với idempotency key trên mọi thao tác ghi. Thay đổi trạng thái được gửi qua webhook, để hệ thống của bạn phản ứng theo sự kiện thay vì phải polling. Việc phát triển diễn ra trên một sandbox tenant — bản sao biệt lập của nền tảng với các rail thử nghiệm, nơi bạn có thể chạy trọn luồng từ tạo đến đối soát mà không di chuyển tiền thật. Mỗi sản phẩm mở ra những gì cho bạn, ở cấp nào, do access band của sản phẩm đó quy định; trang của từng sản phẩm nêu rõ mỗi band bao gồm những gì.
- 01REST API có tài liệu, thao tác ghi idempotent
- 02Webhook cho mọi thay đổi trạng thái — hướng sự kiện, không polling
- 03Sandbox tenant với rail thử nghiệm, tách biệt khỏi production
- 04Phạm vi và hạn mức do access band của từng sản phẩm quy định
Ranh giới rõ ràng
Protocore xây phần mềm. Giấy phép nắm giữ ranh giới được quản lý.
Một sản phẩm thanh toán là hai thứ gắn liền với nhau: quyền được cấp phép để nắm giữ và chuyển tiền, và phần mềm chỉ đạo, ghi nhận và đối soát việc đó. Protocore xây phần mềm. Hoạt động được quản lý — nắm giữ tiền khách hàng, phát hành tài khoản, chuyển tiền trên một scheme — thuộc về giấy phép của chính nhà vận hành hoặc một đối tác được cấp phép: ngân hàng, EMI hoặc tổ chức thanh toán. Nền tảng được xây để khớp với bất kỳ rail được cấp phép nào bạn mang đến, và giữ dữ liệu thẻ trên rail để không bao giờ chạm vào máy chủ của bạn; nó không phải, và không phần mềm nào có thể thay thế, quyền được cấp phép đó. Ranh giới được quản lý nằm ở đâu là quyết định bạn đưa ra cùng đối tác, và kiến trúc được thiết kế để đặt gọn ở cả hai phía của ranh giới ấy.
- 01Một lớp phần mềm, không phải giấy phép
- 02Hoạt động được quản lý thuộc về nhà vận hành hoặc đối tác được cấp phép
- 03Dữ liệu thẻ ở lại trên rail, không qua máy chủ của bạn
- 04Xây để khớp với các rail được cấp phép bạn mang đến
Các liên kết
Lần theo từng mạch kiến thức.
Mỗi khái niệm trên trang này đều có một nơi trình bày đầy đủ hơn — các định nghĩa, sản phẩm và access band nêu rõ mỗi cấp bao gồm những gì.
Idempotency, webhook, settlement, virtual IBAN, SCA — được định nghĩa.
Dịch vụ chạy authorize và capture.
Thao tác đặc quyền bắt buộc nêu lý do và được kiểm toán.
Giá trị on-chain được quyết toán xuyên đến IBAN.
Tiền pháp định và tài sản số được chuyển đổi ở biên.
Mỗi sản phẩm bao gồm những gì, theo từng cấp.
Cần kiến trúc cho dự án của bạn?
Hãy cho chúng tôi biết bạn đang xây dựng gì. Chúng tôi sẽ phản hồi bằng thiết kế hệ thống và vị trí của ranh giới được cấp phép — không phải một bản pitch deck.