How we built Stripe Credits: A programmable, auditable way to pay your Stripe fees

Stripe · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài về một tính năng tài chính; phần kế toán và thuế chỉ tóm tắt ngắn, giữ phần kiến trúc: dựng tính năng mới trên primitive của nền tảng có sẵn thay vì làm hệ riêng.

Bối cảnh

• Trước đây Stripe thu mọi phí từ số dư thanh toán chính của user; chương trình ưu đãi làm bằng giảm giá tuỳ biến hay điều chỉnh tiền bằng tay. Giảm giá chỉ áp cho phí xử lý thẻ; user trả đủ phí trước rồi mới được hoàn lại sau, không thấy ưu đãi áp lúc nào hay còn bao nhiêu.

Thay đổi chính

• Ba lớp:
  • Credits engine: service gRPC độc lập, là nguồn sự thật cho metadata, chính sách, vòng đời và lịch sử audit của credit. Vòng đời là máy trạng thái hữu hạn, mỗi lần đổi trạng thái ghi vào "papertrail" với quy trình hai người duyệt.
  • Logical financial account: nhận ra credit không phải tiền của user theo nghĩa pháp lý mà là tiền của công ty, nên không cần bảo quản, chuyển về ngân hàng hay đối soát với tiền mặt. Thay vì làm hệ số dư riêng, họ mở rộng nền tảng Money Movement and Storage (MMS) sẵn có: thêm một biến thể financial account chỉ là logic, có số dư trong sổ cái nội bộ nhưng không gắn tài khoản ngân hàng thật nào.
  • Fee settlement: áp credit ngay lúc tính phí, trước khi phí chạm số dư chính, thay cho giảm giá hồi tố.
• Rào chắn chống rò từ logic sang tiền thật (lỗi nguy hiểm nhất: một bút toán logic kích hoạt dịch chuyển tiền mặt):
  • Giới hạn dịch chuyển: mọi chuyển giá trị đi qua Originated Money Transfer (OMT), quy trình có sẵn của MMS với ba pha submitted → prepared → disbursed. MMS chặn ở tầng nền tảng mọi OMT giữa tài khoản logic và tài khoản thật.
  • Cách ly sweep: MMS tự động chuyển tiền giữa các pháp nhân dựa trên sổ cái; nếu tính cả tài khoản logic thì sẽ thử chuyển 100 USD tiền thật không tồn tại. Phối hợp với team quản lý tiền mặt để loại bút toán logic khỏi phép tính sweep.
• Hai luồng tiền, một trải nghiệm: credit do user trả trước (doanh thu hoãn lại lúc nạp, thu thuế lúc dùng, hết hạn không dùng thì ghi nhận doanh thu) và credit do Stripe cấp (chi phí của Stripe, thuế được xoá). Gộp chung một luồng kế toán sẽ là "ác mộng audit"; theo Stripe, phần trùng lặp đáng giá.
• Mỗi bước sinh cùng loại sự kiện sổ cái mà hệ kế toán, báo cáo, data warehouse đã quen, nên không phải dựng pipeline báo cáo song song.

Kết quả (theo Stripe)

• Một primitive thay cho mớ ưu đãi tiền mặt, điều chỉnh tay và giảm giá; chạy nhiều chương trình (ưu đãi trong hợp đồng, trả trước theo năm, credit cho startup, credit bồi thường sau sự cố) mà mở chương trình mới không cần làm riêng. Có ở hơn 26 nước. Credit do Stripe cấp thành loại dùng nhiều nhất dù ban đầu chỉ định làm cho trả trước.

Vì sao

• Dùng lại primitive đã được kiểm nghiệm của nền tảng tiền (financial account, OMT, sổ cái) được luôn tính audit và tích hợp downstream; phần việc mới chỉ còn logic riêng của credit (Nền tảng nội bộ cho service (đường ray chung)).
• Chuyển giá trị qua quy trình nhiều pha có trạng thái tường minh, và chặn kết hợp nguy hiểm ở tầng nền tảng chứ không trông vào từng caller (Giao dịch phân tán và nhất quán xuyên service).

Bài học cho SWE

• Phân loại lại bản chất dữ liệu (tiền công ty, không phải tiền user) có thể mở ra kiến trúc đơn giản hơn nhiều.
• Khi thêm một biến thể "giả" vào hệ xử lý thứ thật, liệt kê mọi luồng downstream đọc sổ cái (sweep, đối soát) và chặn rò ở nền tảng.
• Audit là yêu cầu kỹ thuật từ commit đầu: mỗi lần đổi trạng thái có người làm, thời gian, link phê duyệt.
• Hai thứ trông giống nhau với user nhưng khác bản chất thì giữ hai luồng; gộp lại để tránh trùng lặp là sai chỗ.

Liên quan

• Stripe 2025 · Stripe 2026 · Grammarly 2023
• Nền tảng nội bộ cho service (đường ray chung) · Giao dịch phân tán và nhất quán xuyên service