Nhận khoản thanh toán đầu tiên: đưa tiền thật vào app làm bằng AI mà không làm sai

Có một khoảnh khắc cụ thể khi một app làm bằng AI thôi còn là món đồ chơi và trở thành một doanh nghiệp: lần đầu tiên tiền thật chảy qua nó. Cho đến thời điểm đó, sai lầm rất rẻ. Một cái nút hỏng chỉ là phiền. Một con số tổng sai trên một màn hình chẳng ai trả tiền chỉ là một lỗi gõ. Nhưng cái ngày tấm thẻ của một khách hàng thật bị tính tiền, một sai lầm sẽ tốn tiền thật — của bạn hoặc của họ — và “AI nó xây như vậy” không phải câu bạn muốn nói với một người đang khiếu nại về khoản tính phí.

Tin vui: nhận thanh toán trong một app làm bằng AI dễ tiếp cận hơn vẻ ngoài của nó, nếu bạn biết phần nào nên giao cho công cụ AI và phần nào không bao giờ được tự đụng vào. Đây là một hướng dẫn về ranh giới đó.

Một quy tắc duy nhất giữ bạn an toàn: không bao giờ lưu số thẻ

Hãy bắt đầu từ đây, vì đây là quy tắc mà mọi thứ khác bám vào. App của bạn không bao giờ nên nhìn thấy, lưu trữ, hay xử lý một số thẻ tín dụng thô. Không trong cơ sở dữ liệu, không trong một biểu mẫu bạn tự xây, không “chỉ tạm thời thôi”. Tự xử lý dữ liệu thẻ trực tiếp đổ lên đầu bạn một đống nghĩa vụ pháp lý và bảo mật mà không một người mới xây nào nên gánh.

Thay vào đó, bạn dùng một nhà cung cấp thanh toán — Stripe là cái phổ biến, và hầu hết các công cụ tạo app bằng AI đều rành nó. Nhà cung cấp đưa cho bạn một biểu mẫu thanh toán dựng sẵn, an toàn. Khách hàng gõ thông tin thẻ vào biểu mẫu của nhà cung cấp, nhà cung cấp tính tiền nó, và app của bạn chỉ nhận được một thông điệp “đã, khoản này đã thanh toán”. App của bạn biết rằng việc thanh toán đã xảy ra. Nó không bao giờ biết số thẻ.

Khi bạn bảo công cụ AI thêm thanh toán, hãy nói thẳng điều này: “Hãy dùng Stripe Checkout (hoặc biểu mẫu thanh toán được lưu trữ của Stripe) để app của tôi không bao giờ phải xử lý dữ liệu thẻ thô.” Nếu công cụ bắt đầu tạo một biểu mẫu tùy chỉnh có ô nhập số thẻ, hãy dừng nó lại. Đó là đúng cái thứ bạn không muốn nó xây.

”Thêm thanh toán” thật sự bao gồm những gì

Sẽ hữu ích nếu bạn biết các bộ phận cấu thành trước khi bắt đầu, để có thể nhận ra khi nào thiếu thứ gì đó. Một luồng thanh toán hoạt động có bốn phần:

Một mức giá. Bạn tính bao nhiêu, và là một lần hay định kỳ. Cái này nằm trong nhà cung cấp thanh toán của bạn, không phải gắn cứng trong app.
Một bước thanh toán. Cái nút mà khách hàng bấm vào, dẫn họ tới biểu mẫu an toàn của nhà cung cấp.
Một xác nhận trả về app của bạn. Sau khi thanh toán, nhà cung cấp báo cho app của bạn “người này đã trả tiền cho thứ này”. Đây là phần người mới hay bỏ qua nhất — và bỏ qua nó là cách bạn rốt cuộc có những người đã trả tiền nhưng không được cấp quyền.
Một bản ghi về ai đã trả cho cái gì. Để app của bạn mở khóa đúng thứ và để bạn trả lời được câu “người này đã trả tiền chưa?” về sau.

Nếu công cụ AI đưa cho bạn một nút Trả tiền có tính tiền thẻ nhưng app của bạn không làm gì khác đi sau đó, thì nó đã xây phần 2 và quên mất phần 3 và 4. Đó là luồng thanh toán xây-dở phổ biến nhất, và nó trông như chạy được cho đến đúng lúc một khách hàng trả tiền và chẳng nhận được gì.

Cách mô tả nó cho công cụ AI

Đây là một câu lệnh bao quát các phần ở trên:

Thêm quyền truy cập trả phí cho app này bằng Stripe Checkout. Có một gói: 19 đô/tháng.

Khi một người dùng đã đăng nhập bấm “Nâng cấp”, hãy đưa họ tới trang thanh toán được lưu trữ của Stripe. Đừng xây một biểu mẫu thẻ tùy chỉnh — app của tôi không bao giờ được xử lý số thẻ.

Sau một lần thanh toán thành công, hãy đánh dấu người dùng đó là “đã trả tiền” trong cơ sở dữ liệu và mở khóa trang Báo cáo cho họ. Sau một lần thanh toán thất bại hoặc bị hủy, hãy đưa họ về trang định giá kèm một thông báo.

Hãy dùng một Stripe webhook để xác nhận khoản thanh toán từ phía máy chủ trước khi mở khóa bất cứ thứ gì — đừng mở khóa chỉ dựa vào việc người dùng đáp về một trang thành công.

Đoạn cuối cùng đó là thứ tách một luồng thanh toán thật khỏi một luồng mong manh. Để cho trang thành công mở khóa quyền truy cập nghĩa là bất kỳ ai biết được địa chỉ của trang thành công đều có thể mở khóa nó miễn phí. Webhook — một thông điệp trực tiếp, đã được xác minh từ Stripe đến phần phía sau của app — mới là tín hiệu đáng tin. Công cụ AI của bạn biết cách thiết lập cái này; bạn chỉ cần gọi đúng tên mà yêu cầu nó.

Kiểm thử bằng tiền giả trước khi dùng tiền thật

Stripe (và hầu hết các nhà cung cấp) cho bạn một chế độ kiểm thử với những số thẻ giả hành xử như thẻ thật — gồm cả thẻ thanh toán thành công, thẻ bị từ chối, và thẻ kích hoạt lỗi. Hãy dùng nó. Trước khi một tấm thẻ thật chạm vào app, hãy chạy qua mọi tình huống:

Một lần thanh toán thành công. Có mở khóa đúng thứ không? Trạng thái của người dùng có đổi thành “đã trả tiền” không?
Một thẻ bị từ chối. App có xử lý nhẹ nhàng không, hay nó để người dùng kẹt lại trên một màn hình hỏng?
Một lần thanh toán bị hủy — người dùng bấm “quay lại” thay vì trả tiền. Họ có kết thúc ở một nơi hợp lý, vẫn chưa được nâng cấp không?
Trả tiền, rồi đăng xuất và đăng nhập lại. Họ có còn “đã trả tiền” không? (Cái này bắt được những app chỉ mở khóa quyền truy cập cho phiên hiện tại rồi quên béng mất vào hôm sau.)

Hãy hỏi công cụ AI các số thẻ kiểm thử, hoặc tra chúng trong tài liệu của nhà cung cấp. Một thẻ kiểm thử phổ biến cho tình huống “khoản thanh toán này thành công” là thứ mà công cụ có thể cung cấp khi bạn yêu cầu. Hãy chạy cả bốn tình huống. Đường thẻ-bị-từ-chối và thanh-toán-bị-hủy là những đường mà các công cụ AI hay để hỏng nhất, vì đường suôn sẻ là đường chúng tối ưu cho.

Những sai lầm tốn tiền thật

Một vài kiểu lỗi cụ thể xuất hiện đi xuất hiện lại với những luồng thanh toán đầu tiên:

Mở khóa ở trang thành công thay vì ở webhook. Đã nói ở trên, nhưng đáng nhắc lại vì đây là cái tốn kém. Nếu app của bạn mở khóa các tính năng trả phí ngay khoảnh khắc người dùng đáp xuống /success, thì bạn đang tin rằng trình duyệt của người dùng trung thực về việc họ đã trả tiền hay chưa. Họ không phải lúc nào cũng vậy. Hãy mở khóa ở webhook.

Không có bản ghi về cái gì họ đã trả. Nếu app của bạn chỉ lật một cờ “đã trả: có” mang tính toàn cục, bạn sẽ chật vật ngay khi có hơn một gói, hoặc khi ai đó hủy, hoặc khi bạn cần hoàn tiền. Hãy lưu thứ cụ thể: gói nào, vào lúc nào, và mã của nhà cung cấp cho khoản thanh toán đó. Bạn sẽ cần nó cho các câu hỏi hỗ trợ về sau.

Quên rằng các gói thuê bao sẽ kết thúc. Một khoản thanh toán một lần thì đơn giản: trả là trả. Một gói thuê bao định kỳ có thể lụi tàn — thẻ hết hạn, tháng sau thanh toán thất bại. Nếu app của bạn chỉ lắng nghe tín hiệu “họ đã trả tiền” mà không bao giờ lắng nghe “gói thuê bao của họ đã kết thúc”, bạn sẽ có những người giữ quyền truy cập miễn phí sau khi họ ngừng trả tiền. Hãy bảo công cụ xử lý cả thông điệp “gói thuê bao bị hủy hoặc thanh toán thất bại”, không chỉ thông điệp thành công.

Tính sai số tiền vì giá nằm ở hai nơi. Nếu giá được viết vào màn hình của app và được đặt trong nhà cung cấp thanh toán, rốt cuộc chúng sẽ lệch nhau, và một khách hàng sẽ thấy 19 đô nhưng bị tính 29 đô. Hãy giữ giá ở một nơi — nhà cung cấp của bạn — và để app hiển thị bất cứ con số nào nhà cung cấp báo. Một nguồn sự thật duy nhất.

Một danh sách kiểm tra ngắn trước khi bạn vận hành thật

Trước khi bạn chuyển từ chế độ kiểm thử sang tiền thật:

App của tôi không có ô nào để ai đó gõ số thẻ thô vào.
Thanh toán được xác nhận bằng một webhook từ nhà cung cấp, chứ không phải bằng việc người dùng đến được một trang thành công.
Tôi đã kiểm thử một lần thanh toán thành công, một thẻ bị từ chối, và một lần thanh toán bị hủy — cả ba đều hành xử hợp lý.
Sau khi trả tiền, quyền truy cập vẫn mở khóa sau khi đăng xuất và vào ngày hôm sau.
App của tôi ghi lại cái gì mỗi người đã trả, chứ không chỉ là họ đã trả.
Nếu một gói thuê bao lụi tàn, quyền truy cập bị gỡ bỏ tự động.
Tôi đã đổi khóa của nhà cung cấp từ chế độ kiểm thử sang chế độ thật (dễ quên — khách hàng thật đầu tiên của bạn đụng phải khóa kiểm thử sẽ nhận một lỗi khó hiểu).

Nếu mọi ô đều được tích, bạn đã sẵn sàng cho một tấm thẻ thật. Nếu chưa, đó là cuộc trò chuyện tiếp theo của bạn với công cụ AI — trước khi bạn chia sẻ đường link, chứ không phải sau lần khiếu nại đầu tiên.

Tư duy giúp ích cho bạn

Tiền bạc là phần của app mà ở đó “trông như chạy được” và “thật sự chạy được” cách nhau xa nhất. Một bố cục hỏng, bạn thấy ngay. Một luồng thanh toán mở khóa quyền truy cập mà không xác minh việc trả tiền thì trông hoàn hảo — cho đến khi ai đó nhận ra và mách lại cho bạn bè của họ.

Vậy nên hãy đối xử với luồng thanh toán như là cái phần duy nhất của app làm bằng AI mà bạn kiểm thử với thái độ hoài nghi. Hãy cố vào trong mà không trả tiền. Hãy cố làm nó hỏng. Hãy trả tiền rồi cố làm mất quyền truy cập của mình. 30 phút bạn bỏ ra để cố lừa chính app của mình là khoản bảo hiểm rẻ nhất bạn từng mua cho nó.

Sắp thêm thanh toán vào thứ bạn đã xây? Hãy mở phiên làm việc tiếp theo với công cụ AI bằng cách mô tả toàn bộ luồng — mức giá, bước thanh toán, xác nhận qua webhook, và những gì được mở khóa — trong một lần, thay vì chỉ xin một cái nút Trả tiền. Cái nút Trả tiền là 10% dễ dàng. 90% còn lại mới là thứ giữ cho dòng tiền được sòng phẳng.