Hầu hết các khoản hoàn tiền ứng dụng được quyết định mà không có bạn, vì vậy cách giảm hoàn tiền ứng dụng là ngăn chặn chúng trước khi yêu cầu xuất hiện

Đây là phần khó chịu khi cố gắng giảm hoàn tiền ứng dụng. Bạn không được phê duyệt hầu hết chúng. Một khách hàng Google Play chạm một nút trong vòng 48 hours và tiền đã biến mất trước khi máy chủ của bạn nghe thấy. Một khách hàng App Store nộp đơn tại reportaproblem.apple.com và Apple tự phán quyết. Một ngân hàng đảo ngược một khoản phí nhiều tháng sau và cái đó là chung cuộc ngay khi nó xuất hiện. Chống lại hoàn tiền sau khi sự việc đã xảy ra là bản năng sai, vì trong hầu hết mọi luồng chẳng có gì để chống. Cách giảm hoàn tiền ứng dụng là dịch chuyển lên thượng nguồn, đến một số ít điều thực sự nằm trong mã và cấu hình thanh toán của bạn, và đến hai cửa sổ ngắn nơi cửa hàng có hỏi bằng chứng của bạn. Đây là tấm bản đồ đó.

Điều bạn thực sự kiểm soát khi cố gắng giảm hoàn tiền ứng dụng

Chia mọi khoản hoàn tiền thành hai đống. Ở đống thứ nhất, quyết định được đưa ra mà không có bạn: cửa hàng hoặc ngân hàng phán quyết, và bạn biết kết quả dưới dạng một thông báo sau khi tiền đã di chuyển. Ở đống thứ hai, một cửa hàng tạm dừng và hỏi bằng chứng trước khi quyết định. Đống thứ nhất lớn. Đống thứ hai đúng hai luồng. Biết một khoản hoàn tiền rơi vào đống nào cho bạn biết đòn bẩy là phòng ngừa hay phản hồi.

Những khoản hoàn tiền không ai hỏi bạn

Hầu hết các con đường hoàn tiền không bao giờ định tuyến đến bạn. Khoản hoàn tiền tự phục vụ 48 giờ của Google Play được Google quyết định với một cú chạm của khách hàng. Hoàn tiền hỗ trợ, các khoản hoàn tiền Apple cấp từ reportaproblem.apple.com, và các khoản hoàn tiền thiện chí của chính Google đều do cửa hàng quyết định. Google cũng tự động hoàn tiền một giao dịch mà ứng dụng của bạn không bao giờ xác nhận, và hủy các giao dịch mà nó cho là lạm dụng, không cần ý kiến của bạn. Một khoản bồi hoàn ngân hàng là trường hợp cực đoan: một khi ngân hàng đứng về phía khách hàng, việc đảo ngược là chung cuộc và không cửa hàng nào có thể hoàn tác. Với mọi khoản hoàn tiền trong đống này, công việc duy nhất bạn có thể làm đã xảy ra trước khi yêu cầu tồn tại.

Hai khoảnh khắc bạn có tiếng nói

Hai luồng, và chỉ hai, tạm dừng để hỏi bằng chứng của bạn. Khi một khoản hoàn tiền bị nghi vấn đối với một giao dịch Apple đủ điều kiện, Apple gửi đến máy chủ của bạn một CONSUMPTION_REQUEST và cho bạn 12 hours để trả lời qua endpoint Send Consumption Information. Khi một khách hàng Google Play tranh chấp một khoản phí với ngân hàng của họ, Google gửi một yêu cầu xem xét bồi hoàn và cho bạn 24 hours để trả lời qua API orders.reviewrefund. Cả hai đều là bằng chứng bạn nộp, không phải phán quyết bạn đưa ra. Chúng là đối tác trực tiếp của nhau, và chúng là tuyến cuối cùng nơi ý kiến của bạn vẫn được tính.

Ngăn khoản hoàn tiền trước khi cửa hàng quyết định

Vì đống lớn được quyết định mà không có bạn, công việc có đòn bẩy cao nhất là đảm bảo những khoản hoàn tiền đó không bao giờ bị kích hoạt. Bốn đòn bẩy làm phần lớn công việc, và mỗi cái ánh xạ tới một cơ chế cụ thể của cửa hàng, không phải một cảm giác mơ hồ.

Xác nhận mọi giao dịch trong vòng ba ngày

Google Play yêu cầu ứng dụng của bạn xác nhận một giao dịch sau khi bạn cấp quyền. Theo lời của chính Google: việc xác nhận phải được thực hiện trong three days để giao dịch không bị tự động hoàn tiền và quyền bị thu hồi. Đó là một khoản hoàn tiền do chính bạn gây ra, một cách âm thầm, bởi một lỗi. Một sự cố crash giữa việc cấp món hàng và gọi acknowledgePurchase, một lệnh gọi máy chủ bị rớt, một giao dịch đang chờ mà bạn xác nhận quá sớm, bất kỳ cái nào cũng có thể bỏ rơi một giao dịch thật và Google sẽ đòi lại nó ở mốc ba ngày. Đây là khoản hoàn tiền rẻ nhất để loại bỏ vì nó hoàn toàn nằm trong mã của bạn.

Giao đúng thứ họ đã trả tiền, mọi lần

Khoản hoàn tiền trung thực nhất là khi việc giao hàng thất bại. Một khách hàng đã trả tiền, xu không bao giờ đến, các tính năng pro không bao giờ mở khóa, và giờ họ muốn tiền lại và họ đúng. Tính phí kép, các quyền không đồng bộ giữa các thiết bị của khách hàng, và nội dung không bao giờ tải xuống đều là những khoản hoàn tiền do chính bạn tạo ra. Giao hàng đáng tin cậy, xử lý giao dịch idempotent, và khôi phục quyền khi cài đặt mới sẽ loại bỏ cả một loại yêu cầu chính đáng trước khi có ai mở biểu mẫu hoàn tiền.

Làm cho mô tả thanh toán của bạn dễ nhận ra

Một khách hàng không nhận ra một mục hàng trên sao kê của họ không nộp một yêu cầu hoàn tiền thân thiện, họ gọi cho ngân hàng. Google tuyên bố có thể hành động với các tranh chấp thẻ hoặc PayPal không nhận ra tới 120 days kể từ giao dịch, và các tranh chấp thanh toán qua nhà mạng trong 60 days. Một mô tả thanh toán rõ ràng, có thể tìm kiếm và một tên ứng dụng rõ ràng trên biên nhận biến một khoản bồi hoàn tiềm tàng thành, tệ nhất là, một email hỗ trợ. Xét chi phí bồi hoàn hiện nay trên Android, đây là mức hoàn vốn cao nhất trên mỗi giờ làm việc trong danh sách này.

Gắn thẻ mọi giao dịch vào một tài khoản

Bạn không thể phản hồi một tranh chấp bạn không thể truy vết, và bạn không thể thu hồi quyền truy cập từ một khách hàng bạn không thể nhận diện. Gắn thẻ mọi giao dịch bằng định danh tài khoản của riêng bạn tại thời điểm mua. Trên iOS, appAccountToken phải là một UUID. Trên Android, setObfuscatedAccountId nhận một hash gồm 64 characters trở xuống, và nó không bao giờ được chứa dữ liệu cá nhân dạng văn bản rõ, vì Google chặn các giao dịch mang thông tin nhận dạng trong trường đó. Thói quen này là điều làm cho mọi bước về sau, bằng chứng, thu hồi, và phát hiện lạm dụng, thực sự trở nên khả thi.

Cắt bỏ sự lạm dụng bạn có thể thấy trước

Một số khoản hoàn tiền không trung thực cũng không phải vô tình. Một khách hàng mua một món tiêu hao, tiêu hết từng đơn vị của nó, rồi đòi lại tiền. Các diễn đàn nhà phát triển của chính Apple đầy rẫy câu hỏi chính xác này về các giao dịch trong ứng dụng tiêu hao, vì cửa hàng không thể hoàn tác việc tiêu dùng mà khách hàng đã sử dụng. Bạn không thể ngăn khoản hoàn tiền, nhưng bạn có thể đảm bảo nó không đồng thời để họ giữ lại hàng hóa.

Thu hồi quyền truy cập ngay khi khoản hoàn tiền xuất hiện

Khi một khoản hoàn tiền hoặc bồi hoàn được giải quyết, cắt quyền. Trên Android, Voided Purchases API liệt kê các đơn hàng đã được hoàn tiền, bị bồi hoàn, hoặc bị thu hồi để bạn có thể lấy lại món hàng. Trên iOS, một thông báo REFUND trên máy chủ của bạn là tín hiệu để thu hồi. Nếu bạn bỏ qua điều này, một kẻ lạm dụng có hệ thống giữ lại từng xu, cấp độ, hoặc mở khóa cao cấp mà họ đã trả tiền để đảo ngược, và ứng dụng của bạn trở thành cửa hàng rẻ nhất trong thành phố. Thu hồi không lấy lại giao dịch, nhưng nó loại bỏ lý do để chạy lại chiêu trò đó.

Trả lời hai cửa sổ bằng chứng đúng hạn

Với hai luồng có hỏi, việc xuất hiện chính là toàn bộ công việc. 12 hours của Apple và 24 hours của Google là những hạn chót cứng, và chúng mở theo lịch của cửa hàng, không phải của bạn, thường vào giữa đêm. Một CONSUMPTION_REQUEST mà bạn trả lời bằng trạng thái giao hàng và dữ liệu sử dụng là thứ Apple cân nhắc so với một khoản hoàn tiền. Một phản hồi orders.reviewrefund với chi tiết giao hàng và tiêu dùng là dữ liệu Google dùng để phản đối một khoản bồi hoàn bất hợp pháp thay mặt bạn. Một cửa sổ không được trả lời là một thất bại mặc định. Những cái này không thể xử lý bằng tay ở bất kỳ khối lượng thực tế nào, đó chính là toàn bộ lý do để tự động hóa chúng.

Một khoản hoàn tiền được ngăn chặn đáng giá bao nhiêu tiền

Phòng ngừa có lợi vì một sự đảo ngược không bao giờ chỉ là giá bán chảy ngược ra. Đến lúc một khoản hoàn tiền hoặc bồi hoàn xuất hiện, bạn đã giao xong giao dịch, và khoản chi đó không trở lại cùng với nó.

Giá bán là phần nhỏ nhất

Khi một khoản hoàn tiền được giải quyết, bạn mất khoản thu ròng sau hoa hồng của cửa hàng. Nhưng phần tính toán đã chạy, các lệnh gọi API của bên thứ ba đã bị tính phí, phần lưu trữ đã được ghi, và bất kỳ khoản chi trả cho nhà sáng tạo nào đã ra khỏi cửa đều mất luôn, và không có cái nào trở lại cùng với sự đảo ngược. Một khoản hoàn tiền được ngăn chặn giữ lại giá và toàn bộ chi phí giao hàng đó. Cửa sổ hoàn tiền mà khách hàng dùng càng dài, càng nhiều chi phí đó bạn đã chồng chất trước khi tiền rời đi.

Thay đổi ngày 3 tháng 8 khiến việc phòng ngừa trên Android có lợi hơn

Với các đơn hàng Google Play đặt vào hoặc sau ngày 3 tháng 8 năm 2026, một khoản bồi hoàn bị thua cũng khiến nhà phát triển mất phí bồi hoàn của ngân hàng, cộng thêm vào giá mua trừ đi phí dịch vụ của Play. Google tiếp tục chỉ chịu phí dịch vụ của riêng mình. Vì phí bồi hoàn là cố định còn giá sản phẩm thì không, với một giao dịch trong ứng dụng giá rẻ, riêng phí thôi có thể vượt quá số tiền khách hàng đã trả. Mỗi tranh chấp phí không nhận ra mà bạn chặn được bằng một mô tả rõ ràng nay đáng giá cả giao dịch cộng một khoản phí, không chỉ giao dịch.

RefundHalt được xây dựng cho phần này mà bạn không thể làm bằng tay. Nó theo dõi CONSUMPTION_REQUEST của Apple trong cửa sổ 12 giờ và việc xem xét bồi hoàn của Google Play trong cửa sổ 24 giờ, tập hợp bằng chứng giao hàng và tiêu dùng, và trả lời đúng hạn mà không cần ai trong đội của bạn thức để bắt một thông báo lúc 3 giờ sáng. Nó truy vết các khoản hoàn tiền và bồi hoàn trở lại tài khoản đã tạo ra chúng, để sự lạm dụng bạn có thể thấy trước trở nên hiện rõ thay vì bị chôn vùi. Bạn sẽ không bao giờ giảm hoàn tiền ứng dụng về không, vì hầu hết chúng không thuộc quyền quyết định của bạn. Bạn có thể đảm bảo những cái đáng lẽ bạn có thể ngăn chặn không bao giờ xảy ra, và hai cái bạn có thể tranh luận không bao giờ bị bỏ ngỏ.