Lạm dụng hoàn tiền hàng loạt khiến bạn tốn kém gấp đôi, đây là cách các cửa hàng cho phép bạn phản công

Một lần hoàn tiền là chi phí của việc kinh doanh. Cùng một tài khoản hoàn tiền lần thứ tư, sau khi đã dùng thứ nó mua mỗi lần, là lạm dụng hoàn tiền, và đó là một mô hình bạn chỉ có thể thấy nếu mọi giao dịch mua mang theo một danh tính bạn kiểm soát. Cả Apple và Google đều trao cho bạn danh tính đó, và cả hai đều cho bạn một cửa sổ hẹp để đưa nó ra trước cửa hàng trước khi một lần hoàn tiền hoặc bồi hoàn được quyết định. Bỏ lỡ cửa sổ, hoặc không bao giờ đính kèm danh tính, và một kẻ hoàn tiền hàng loạt trông y hệt một khách hàng không hài lòng lần đầu. Đây là cách phân biệt họ, và sự khác biệt đó đáng giá bao nhiêu tiền.

Vì sao lạm dụng hoàn tiền là vấn đề danh tính, không phải vấn đề hoàn tiền

Cửa hàng quyết định việc hoàn tiền. Bạn không thể ngăn khách hàng yêu cầu, và trên hầu hết các luồng bạn không thể ngăn cửa hàng chấp thuận. Điều bạn có thể làm là quyết định liệu một tài khoản nhất định đã làm việc này trước đây chưa, và liệu nội dung nó mua có thực sự được giao và được sử dụng hay không. Cả hai điều đó đều là câu hỏi về danh tính: người dùng nào của bạn đứng sau giao dịch này, và lịch sử của họ ra sao. Nếu các giao dịch mua của bạn không mang theo một định danh ổn định trỏ về hồ sơ người dùng của chính bạn, bạn không thể trả lời câu hỏi nào, và mọi lần hoàn tiền đều đến mà không có ngữ cảnh.

Đó là khoảng trống thực sự. Cơ chế hoàn tiền được cố định bởi chính sách. Bằng chứng bạn mang đến cho nó hoàn toàn thuộc về bạn để xây dựng, và nó bắt đầu vào thời điểm mua, không phải thời điểm hoàn tiền.

Hai cửa sổ nơi bằng chứng làm thay đổi kết quả

Có đúng hai luồng nơi bất cứ thứ gì bạn gửi có thể làm lay chuyển một quyết định. CONSUMPTION_REQUEST của Apple kích hoạt khi một khách hàng yêu cầu hoàn tiền cho một sản phẩm tiêu hao hoặc một gói đăng ký tự động gia hạn, và bạn có 12 hours để trả lời. Quá trình xem xét bồi hoàn của Google Play kích hoạt khi một người dùng tranh chấp một khoản phí với ngân hàng của họ, và bạn có 24 hours để phản hồi qua Review Refund API. Mọi lần hoàn tiền khác, hoàn tiền tự phục vụ 48-hour của Play, một lần hoàn tiền do bộ phận hỗ trợ cấp, một lần hoàn tiền tự động cho giao dịch mua chưa được xác nhận, đều được quyết định mà không có bạn.

Cả hai kênh bằng chứng đó đều mạnh hơn nhiều khi giao dịch đã mang theo định danh của bạn. Thông tin tiêu thụ của Apple có thể bao gồm appAccountToken cùng với lịch sử và mức chi tiêu của tài khoản, và quá trình xem xét của Google có thể dựa vào ID tài khoản đã che giấu mà nó đã theo dõi kể từ lúc mua. Một tài khoản không có định danh là một tài khoản không có lịch sử để nộp.

Hai trường danh tính, đặt cạnh nhau

Apple và Google giải quyết cùng một vấn đề theo cách gần như giống hệt, với những cái tên khác nhau và những quy tắc khác nhau. Cả hai đều cho phép bạn đóng dấu một giao dịch mua bằng một giá trị trỏ về hồ sơ người dùng của chính bạn. Không cái nào bật theo mặc định. Cả hai đều vô dụng nếu bạn không đặt chúng vào thời điểm mua.

Apple: appAccountToken

appAccountToken là một UUID bạn tạo ra và truyền vào khi một giao dịch mua bắt đầu. StoreKit liên kết nó với giao dịch phát sinh, và nó xuất hiện trong dữ liệu giao dịch mà máy chủ của bạn xác minh và trong thông tin tiêu thụ bạn gửi lại trong một CONSUMPTION_REQUEST. Vì đó là giá trị của bạn, nó ánh xạ một giao dịch cửa hàng trực tiếp lên tài khoản trong cơ sở dữ liệu của bạn, không liên quan đến email hay tên. Nó phải là một UUID thực, và bất cứ thứ gì khác đều bị từ chối. Apple sau đó đã thêm một endpoint Set App Account Token có thể đính kèm hoặc cập nhật token trên các giao dịch trước đây, bao gồm cả các giao dịch mua được thực hiện bên ngoài ứng dụng của bạn như đổi mã ưu đãi.

Google Play: ID tài khoản đã che giấu

Tương đương của Google là setObfuscatedAccountId, một chuỗi tùy chọn gắn với tài khoản mua hàng. Tài liệu riêng của Google nói thẳng về mục đích của nó: Google Play dùng nó để phát hiện hoạt động bất thường, như nhiều thiết bị thực hiện giao dịch mua trên cùng một tài khoản trong một khoảng thời gian ngắn, và để chặn một số giao dịch gian lận trước khi chúng hoàn tất. Nó bị giới hạn ở 64 characters, và không được mang dữ liệu cá nhân ở dạng văn bản rõ. Lưu một email thô ở đó và Google chặn thẳng giao dịch mua, vì trường này mong đợi một giá trị đã mã hóa hoặc một hàm băm một chiều. Một trường anh em, setObfuscatedProfileId, tồn tại cho các ứng dụng nơi một tài khoản giữ nhiều hồ sơ.

Một lần hoàn tiền từ kẻ lạm dụng hàng loạt thực sự tốn kém bao nhiêu

Bản thân lần hoàn tiền là phần nhỏ nhất của hóa đơn. Khi một cửa hàng chấp thuận hoàn tiền, bạn trả lại doanh thu, và chừng đó hiện rõ trên sổ cái. Thứ không nằm trên dòng hoàn tiền là tất cả những gì bạn đã chi để giao sản phẩm mà giờ đây đã miễn phí.

Hãy hình dung một sản phẩm tiêu hao kích hoạt công việc thực sự: một lần tạo ảnh, một loạt lệnh gọi API tới một nhà cung cấp mô hình, một lần xuất video, một khoản chi trả cho nhà sáng tạo. Bạn đã trả cho phần tính toán đó ngay khoảnh khắc khách hàng sử dụng nó. Lần hoàn tiền lấy lại giá bán, nhưng nó không lấy lại hóa đơn của nhà cung cấp. Một kẻ hoàn tiền hàng loạt là người đã học được rằng nội dung vẫn còn sau khi hoàn tiền, nên họ chạy lại vòng lặp: mua, tiêu thụ, hoàn tiền, lặp lại. Mỗi chu kỳ, bạn gánh chi phí giao hàng thêm một lần nữa.

Rồi còn có sự dịch chuyển chi phí của chính cửa hàng. Kể từ August 3 2026, Google Play chuyển giá mua và các khoản phí bồi hoàn của ngân hàng sang nhà phát triển đối với những đơn hàng được đặt sau ngày đó. Một khoản bồi hoàn từng chủ yếu là vấn đề của Google trở thành doanh thu của bạn cộng với một khoản phí, và một kẻ tranh chấp lặp lại nâng con số đó lên mỗi lần. Các trường danh tính là thứ cho phép bạn cấp cho Review Refund API bằng chứng để phản đối một tranh chấp bất hợp pháp trong cửa sổ 24 hours.

Google diễn đạt quy mô một cách rõ ràng: họ nói đã chặn hơn $2 billion giao dịch gian lận và lạm dụng trong 2022. Con số đó tồn tại vì các tín hiệu, trong đó có ID tài khoản đã che giấu, đã được điền vào. Một ứng dụng gửi các giao dịch mua với các trường danh tính trống rỗng là tự chọn bỏ khỏi sự bảo vệ đó.

Cách bắt những kẻ hoàn tiền lặp lại trước khi cửa hàng quyết định

Gắn thẻ mọi giao dịch mua bằng một danh tính bạn sở hữu

Đặt appAccountToken trên mọi giao dịch mua StoreKit và setObfuscatedAccountId trên mọi giao dịch mua Play Billing, cả hai đều được tạo từ hồ sơ người dùng của chính bạn. Trên Apple, dùng một UUID thực được ánh xạ tới tài khoản. Trên Google, băm khóa tài khoản để không có dữ liệu cá nhân nào di chuyển ở dạng văn bản rõ. Hãy làm điều này vào thời điểm mua, vì trên Google đây là bước duy nhất bạn không thể khôi phục về sau.

Duy trì một sổ cái được khóa theo danh tính đó

Lưu mọi giao dịch mua, giao hàng, sự kiện tiêu thụ và hoàn tiền theo định danh. Khi một CONSUMPTION_REQUEST hoặc một lần xem xét bồi hoàn đến, toàn bộ lịch sử của tài khoản, bao gồm các lần hoàn tiền trước, chỉ cách một truy vấn. Thông tin tiêu thụ của Apple có các trường rõ ràng đúng cho việc này: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased, và refundPreference của bạn.

Đọc voidedReason và định tuyến những kẻ lạm dụng khác đi

Khi một giao dịch mua trên Google bị hủy, trường voidedReason cho bạn biết lý do, và friendly_fraud cùng fraud là những giá trị tách biệt với một lần hoàn tiền remorse thông thường. Hãy định tuyến chúng vào một hàng đợi xem xét và một chính sách nghiêm ngặt hơn, không phải cùng con đường tự động như một lần hoàn tiền lần đầu. Hướng dẫn riêng của Google là một mô hình nhiều lần cảnh cáo: cảnh báo kẻ vi phạm lần đầu, có hành động cứng rắn hơn với những kẻ lặp lại, và vô hiệu hóa việc mua hàng đối với một tài khoản cứ tiếp tục.

Trả lời cửa sổ mỗi lần

Bằng chứng chỉ được tính bên trong hai cửa sổ. Hãy tự động hóa phản hồi CONSUMPTION_REQUEST để nó kích hoạt sớm gọn trong 12 hours, và quá trình xem xét bồi hoàn để nó kích hoạt trong 24 giờ. Một lịch sử hoàn hảo mà bạn nộp muộn là một lịch sử cửa hàng không bao giờ đọc.

Những gì các cửa hàng sẽ và sẽ không làm cho bạn

Đáng để nói cho chính xác về sự phân chia công việc, vì rất dễ giả định rằng các cửa hàng xử lý việc lạm dụng, và họ phần lớn không nói cho bạn biết khi họ không làm. Google chủ động dùng ID tài khoản đã che giấu để chặn một số gian lận trước khi một giao dịch mua hoàn tất, và các hệ thống của họ bắt được một phần lớn ở cấp nền tảng. Apple tự quyết định mọi lần hoàn tiền và xem thông tin tiêu thụ của bạn như một đầu vào, không bao giờ như một lá phiếu. Không cửa hàng nào duy trì danh sách kẻ lạm dụng của bạn hộ bạn, trừ một sản phẩm tiêu hao đã hoàn tiền khỏi số dư của bạn, hay nói không với một kẻ hoàn tiền lặp lại thay mặt bạn. Danh tính là của cửa hàng để hành động ở các mép và của bạn để hành động ở mọi nơi khác.

Đây cũng chính là lý do RefundHalt khóa mọi thứ theo danh tính giao dịch mua: một lần hoàn tiền, một lần xem xét bồi hoàn, và một yêu cầu tiêu thụ cho cùng một tài khoản đều phân giải về một lịch sử, nên một kẻ hoàn tiền hàng loạt lộ ra như một mô hình ngay lần đầu họ lặp lại, không phải sau hóa đơn thứ tư mà bạn đã trả.