Chào bạn — mình đã thấy tin nhắn của bạn sáng nay, ảnh chụp màn hình ai đó hỏi "làm sao để trả tiền cho cái này" trong hộp thư hỗ trợ của ứng dụng bạn. Chúc mừng thật lòng nhé. Đó chính là khoảnh khắc một dự án cá nhân không còn là bản demo nữa. Đó cũng là lúc hàng trăm quyết định nhỏ mà bạn từng có thể trì hoãn giờ cùng ập đến trong một buổi tối thứ Ba. Bạn nhờ mình chỉ cần nói cho bạn biết phải làm gì. Mình sẽ làm điều đó, nhưng mình muốn giải thích lý do trước, vì chính cái "lý do" đó sẽ giúp bạn không phải hỏi lại mình sau ba tháng nữa khi đó là Lemon Squeezy thay vì Stripe, hoặc thuê bao thay vì mua một lần.
Quyết định thực sự bạn đang đưa ra
Bạn đặt câu hỏi này là "nên dùng nhà cung cấp thanh toán nào," nhưng thực ra đó là hai quyết định chồng lên nhau. Thứ nhất: bạn muốn tự làm bên bán chính thức (merchant of record), hay muốn để bên khác đảm nhận việc đó? Thứ hai: hình thức thanh toán của bạn là gì — mua một lần, thuê bao, hay theo mức sử dụng? Chọn sai câu đầu tiên, sáu tháng sau bạn sẽ mất cả cuối tuần để đăng ký VAT ở một quốc gia mà bạn chưa từng đặt chân tới. Chọn sai câu thứ hai chỉ là một lần chuyển đổi phiền phức, chứ không phải vấn đề pháp lý, nên nó ít đáng sợ hơn.
Là bên bán chính thức (merchant of record) nghĩa là bạn chính là người bán sản phẩm về mặt pháp lý. Bạn thu tiền, bạn chịu trách nhiệm tính thuế bán hàng và VAT ở mọi khu vực pháp lý nơi khách hàng của bạn sinh sống, và bạn phải kê khai nộp thuế. Stripe sẵn sàng tính toán thuế đó giúp bạn (Stripe Tax), nhưng tính toán không đồng nghĩa với nộp thuế — bạn vẫn phải đăng ký và kê khai ở mỗi nơi bạn vượt ngưỡng quy định. Một dịch vụ bên bán chính thức như Lemon Squeezy hay Paddle sẽ giải quyết toàn bộ vấn đề đó thay bạn: về mặt pháp lý họ là người bán, họ thu và nộp thuế ở mọi nơi, rồi trả lại cho bạn phần thực nhận. Đổi lại, bạn phải nhường một phần biên lợi nhuận cho họ.
| Lựa chọn | Ai là người bán | Tỷ lệ phí điển hình | Xử lý thuế | Phù hợp nhất cho |
|---|---|---|---|---|
| Stripe (trực tiếp) | Bạn | ~2,9% + 0,30 USD/giao dịch, +0,5% cho Stripe Tax | Bạn đăng ký và kê khai, Stripe chỉ tính toán | Bạn kỳ vọng mở rộng vượt mức vài nghìn đô mỗi tháng và muốn phí thấp hơn về lâu dài |
| Lemon Squeezy | Lemon Squeezy | ~5% + $0.50/giao dịch | Được xử lý toàn bộ, họ là bên bán chính thức | Người xây dựng đơn lẻ, sản phẩm đầu tay, không muốn nghĩ đến thuế chút nào |
| Paddle | Paddle | ~5% + phí thay đổi theo khu vực | Được xử lý toàn bộ, thiên về doanh nghiệp lớn | SaaS có đăng ký thuê bao và một số nhu cầu xuất hóa đơn |
| PayPal | Bạn | ~3,5-4,5%, tranh chấp thân thiện với người mua | Bạn tự xử lý | Khách hàng đặc biệt tin tưởng PayPal, không phải lựa chọn mặc định |
Với tình huống hiện tại của bạn — một khách hàng, một sản phẩm đơn giản, chưa biết liệu điều này có trở thành một doanh nghiệp hay không — tôi sẽ khuyên bạn chọn Lemon Squeezy hoặc Paddle thay vì dùng Stripe trực tiếp. Khoản phí thêm hai điểm phần trăm đó là một khoản bảo hiểm rẻ để tránh việc bạn vô tình trở thành người phải kê khai thuế ở một bang mà bạn chưa từng đặt chân đến. Bạn hoàn toàn có thể chuyển sang Stripe trực tiếp sau này, khi khối lượng giao dịch đủ lớn để việc chuyển đổi là xứng đáng và bạn sẵn sàng đối mặt với giấy tờ thủ tục. Chẳng ai chuyển đổi nhà cung cấp thanh toán vì vui cả, nhưng đó là việc có thể giải quyết trong một ngày, không phải một năm.
Tôi từng mắc lỗi này trong một dự án trước đây — chọn thẳng Stripe vì "ai cũng dùng Stripe", thu vài trăm đô mỗi tháng từ một số khách hàng châu Âu, rồi mười tám tháng sau nhận được một email rất lịch sự nhưng cực kỳ khó hiểu về việc đăng ký VAT MOSS. Nó tốn của tôi cả một buổi chiều với kế toán và bốn mươi phút hoảng loạn tra Google "mình có nợ tiền Hà Lan không". Không thảm khốc, nhưng hoàn toàn có thể tránh được.
Trước khi đụng vào key thực
Dù bạn chọn cái nào, đừng thiết lập nó ở chế độ production ngay từ đầu. Mỗi nhà cung cấp này đều có chế độ thử nghiệm/sandbox với các số thẻ giả để kích hoạt những kết quả cụ thể — thanh toán thành công, thẻ bị từ chối, yêu cầu 3D Secure, không đủ số dư. Hãy chạy qua tất cả các trường hợp đó trước khi đụng vào key thật. Những đường lỗi đó mới chính là thứ bạn sẽ thực sự gặp phải trong tuần đầu tiên, và chúng khó gỡ lỗi hơn nhiều khi đang chạy thật với thẻ của một người thật.
Trong chat build của bạn, hãy nói rõ ràng rằng bạn muốn việc này được thực hiện theo từng giai đoạn: yêu cầu kết nối tích hợp ở chế độ thử nghiệm trước, kèm một banner hoặc cờ hiển thị rõ ràng để không ai — kể cả chính bạn sau này — vô tình tính phí một thẻ thật trong lúc thử nghiệm. Sau đó thực hiện một bước riêng, có chủ đích, để thay bằng key thật. Hai lệnh nhắc, không phải một, dù nói "thêm thanh toán" rồi để nó tự đoán chế độ nào sẽ nhanh hơn. Sự cọ xát đó chính là mục đích.
Bạn cũng cần quyết định điều gì xảy ra khi một webhook được kích hoạt trong lúc server của bạn đang tắt, chạy chậm, hoặc sự kiện đến hai lần. Đây không phải là giả thuyết — nó chắc chắn sẽ xảy ra trong tuần đầu tiên. Các sự kiện bạn thực sự cần xử lý, tối thiểu là:
checkout.session.completed(hoặc tương đương) — cấp quyền truy cập, đây là khoảnh khắc khách hàng thực sự trở thành khách hànginvoice.payment_failed— với các gói thuê bao, hãy quyết định ngay bây giờ xem đó là khóa truy cập ngay lập tức hay có thời gian gia hạn, vì "khóa ngay lập tức" thực sự là một ấn tượng đầu tiên tệ hại đối với một thẻ chỉ gặp trục trặc tạm thờicustomer.subscription.deleted— có người đã hủy, thu hồi quyền truy cập vào cuối kỳ, không phải ngay lập tức, trừ khi điều khoản của bạn quy định khác- Một sự kiện hoàn tiền — hãy tự quyết định trước, bằng văn bản cho chính mình, chính sách hoàn tiền thực sự của bạn là gì, trước khi yêu cầu hoàn tiền đầu tiên buộc bạn phải quyết định ngay tại chỗ
Tính idempotent quan trọng ở đây hơn hầu hết mọi nơi khác trong ứng dụng của bạn. Nếu một webhook đến hai lần — và điều này sẽ xảy ra, vì các nhà cung cấp sẽ thử lại khi nhận phản hồi không phải 200 — bạn không được cấp quyền truy cập hai lần hoặc, tệ hơn, tính phí trùng trạng thái nội bộ. Hãy lưu lại ID sự kiện và kiểm tra xem bạn đã xử lý nó chưa trước khi hành động.
Câu hỏi về giá mà bạn đang né tránh
Bạn có nhắc trong tin nhắn rằng chưa chắc nên tính $9/tháng hay một lần $49. Tôi không nghĩ cách nào sai cả, nhưng hãy để ý điều bạn thực sự đang né tránh: cuộc trò chuyện với khách hàng về giá trị lặp lại thực sự là gì. Một mức giá trả một lần dễ được đồng ý hơn và cũng dễ xây dựng hơn cho bạn (không cần xử lý dunning, không cần xử lý gia hạn thất bại, không cần luồng hủy). Một gói thuê bao là một canh bạc rằng bạn sẽ tiếp tục cải thiện sản phẩm đủ để người dùng không rời bỏ — đó là một cam kết thực sự, không chỉ là một ô tick trên trang giá. Nếu bạn không chắc mình sẽ vẫn còn tích cực phát triển thứ này trong sáu tháng nữa, mức giá trả một lần là lời đề nghị trung thực hơn. Bạn luôn có thể thêm gói thuê bao sau này khi đã có điều gì đó liên tục để đăng ký.
Một điều nữa, rồi tôi sẽ để bạn quay lại công việc: hãy đưa một chính sách hoàn tiền và hủy bỏ thực sự lên trang trước khi nhận đồng đô la đầu tiên, dù chỉ là ba câu. Không phải vì ai đó sẽ kiện bạn vì khoản phí $9, mà vì việc viết ra buộc bạn phải thực sự quyết định nó, và "tôi sẽ tính sau khi có ai đó hỏi" là cách bạn sẽ phải đưa ra quyết định chính sách giữa lúc đọc một email giận dữ thay vì trong một buổi chiều bình yên.
Hãy đi kết nối sandbox trước đã. Nhắn cho tôi khi bạn đã chạy thử một thẻ bị từ chối giả — đó mới là phiên bản "nó hoạt động" thực sự quan trọng.
