Đọc mã lý do hoàn tiền mà máy chủ của bạn đã nhận, và nó cho bạn biết nên sửa ứng dụng hay tranh luận với khách hàng

Khi Apple hoặc Google hoàn tiền cho một khách hàng của bạn, tiền thường đã đi mất trước khi bạn kịp có tiếng nói. Cái rơi vào máy chủ của bạn sau đó trông giống một biên nhận, và hầu hết các nhóm đối xử với nó như vậy. Nó còn hơn thế. Mỗi khoản hoàn tiền mang một mã lý do hoàn tiền, và đó là phần duy nhất của một khoản hoàn tiền mà bạn vẫn được đọc sau khi quyết định đã xong. Google Play cho bạn biết khoản hoàn tiền là một chargeback, hay một yêu cầu remorse, hay một giao dịch mà chính ứng dụng của bạn chưa bao giờ xác nhận. Apple cho bạn biết liệu khoản hoàn tiền có quy lỗi cho điều gì bên trong ứng dụng của bạn không. Đọc mã đó và một khoản hoàn tiền thôi là một dòng trong báo cáo mà trở thành một chỉ dẫn: sửa cái này, tranh luận cái này, hoặc bỏ qua cái này. Đây là ý nghĩa của từng mã, cách phân loại chúng, và mỗi mã tốn bao nhiêu.

Mã lý do hoàn tiền thực sự là gì

Mã lý do hoàn tiền là nhãn của chính cửa hàng cho lý do một giao dịch bị đảo ngược. Bạn không đặt nó và không thể tranh cãi với nó. Nó đến kèm khoản hoàn tiền sau khi việc đã rồi, và hai cửa hàng phơi bày nó theo những hình dạng khác nhau và với độ phân giải rất khác nhau.

Google Play đóng một lý do và một nguồn lên mỗi lần void

Voided Purchases API của Google Play trả về một bản ghi cho mỗi giao dịch bị đảo ngược, và mỗi bản ghi mang hai số nguyên quan trọng. voidedReason nói vì sao giao dịch bị void. voidedSource nói ai đã khởi động nó. Cùng nhau chúng biến một khoản hoàn tiền trần trụi thành một câu: đơn hàng này bị void vì một chargeback, do Google khởi động, hoặc bị void như remorse, do người dùng khởi động. Bạn đọc chúng bằng cách polling API hoặc bằng cách đăng ký nhận thông báo nhà phát triển thời gian thực kích hoạt khi một lần void rơi vào. Dù cách nào, hai con số đó là payload đáng giữ.

Apple cho bạn một tín hiệu hẹp hơn, nhưng sắc bén

Apple không trao cho bạn một lý do chín hướng. Trên một giao dịch được hoàn tiền, Apple đặt revocationReason thành một trong hai giá trị. Giá trị 1 nghĩa là App Store hoàn tiền giao dịch vì một vấn đề thực tế hoặc được cho là có bên trong ứng dụng của bạn. Giá trị 0 nghĩa là hoàn tiền vì lý do khác, ví dụ mua nhầm. Trường này chỉ xuất hiện trên các giao dịch được hoàn tiền hoặc bị thu hồi, cùng với một revocationDate, bên trong signed transaction info của REFUND App Store Server Notification. Hai giá trị thì không nhiều, nhưng giá trị quan trọng, tức 1, là Apple nói cho bạn biết khoản hoàn tiền là về sản phẩm của bạn, không phải sự do dự của khách hàng.

Chín lý do Google Play trao cho bạn

voidedReason của Google là cái phong phú hơn trong hai cái, và mỗi giá trị đáng biết ngay khi nhìn thấy vì mỗi cái chỉ về một nơi khác nhau. Đây là toàn bộ tập hợp, lấy thẳng từ resource VoidedPurchase, cùng với điều mỗi mã thực sự bảo bạn làm.

voidedSource cho bạn biết ai đã bóp cò

Bên cạnh lý do là voidedSource, và nó trả lời một câu hỏi khác: ai đã đảo ngược cái này. Giá trị 0 nghĩa là người dùng đã làm, qua tự phục vụ hoặc qua ngân hàng. Giá trị 1 nghĩa là nhà phát triển đã làm, tức là bạn hoặc công cụ của chính bạn phát hành khoản hoàn tiền. Giá trị 2 nghĩa là Google đã làm, theo phán đoán của riêng nó, bao gồm cả việc tự động hoàn tiền cho một giao dịch không được xác nhận. Khi bạn thấy một đợt tăng đột biến các lần void, nguồn là lát cắt đầu tiên. Một bức tường toàn source 2 là Google đang hành động trên tài khoản của bạn, và đó thường là một tín hiệu chỉ ngược về phần tích hợp của bạn chứ không phải về khách hàng của bạn.

Phân loại mỗi khoản hoàn tiền thành sửa, tranh luận, hoặc chấp nhận

Lý do một mã hữu ích là nó cho bạn biết trong ba phản ứng thì một khoản hoàn tiền xứng đáng với cái nào. Hầu hết các nhóm đối xử với mọi khoản hoàn tiền như nhau và đốt công sức vào những cái không bao giờ thắng nổi. Các mã chia tách gọn gàng.

Sửa: các khoản hoàn tiền do sản phẩm của bạn gây ra

Một số mã là báo cáo lỗi khoác áo hoàn tiền. Lỗi (3) và không nhận được (2) trên Google, và revocationReason bằng 1 trên Apple, tất cả đều nói cùng một điều: khách hàng đã trả tiền và ứng dụng của bạn không giao hàng. Giao dịch không được xác nhận (8) là mã sắc bén nhất trong số này vì lỗi hoàn toàn nằm trong mã tính tiền của bạn. Đây là những khoản hoàn tiền rẻ nhất để loại bỏ, vì bạn loại bỏ chúng bằng cách sửa một thứ bạn sở hữu, không phải bằng cách thuyết phục ai đó. Một con số tăng lên trong nhóm này là một khiếm khuyết sản phẩm có kèm một con số bằng đô la.

Tranh luận: các khoản hoàn tiền đang bị ai đó thao túng

Gian lận (5), friendly fraud (6), và chargeback (7) là các tranh chấp. Gian lận thuần túy (5) không phải khách hàng của bạn và không phải doanh thu bạn từng định giữ. Friendly fraud (6), khi người mua nhận đúng thứ họ đã trả tiền rồi tranh chấp nó, là tranh chấp duy nhất mà bằng chứng của bạn vẫn có thể lay chuyển, và chargeback (7) là nơi bằng chứng đó được nộp. Khi một trong số này rơi vào, bạn thu hồi quyền truy cập nếu chưa làm, và ở đâu có một cửa sổ xem xét đang mở thì bạn trả lời nó bằng những gì bạn biết về tài khoản đó.

Chấp nhận: các khoản hoàn tiền vốn dĩ không bao giờ do bạn ngăn được

Remorse (1) và mua nhầm (4) là sự đổi ý của chính khách hàng. revocationReason bằng 0 của Apple cũng nằm ở đây. Không tính năng nào hỏng và không có gian lận nào xảy ra. Bạn có thể làm dịu nhóm mua nhầm bằng một xác nhận mua rõ ràng hơn, nhưng bạn không thể tranh cãi để loại bỏ một khoản hoàn tiền remorse, và thời gian dành để thử là thời gian lấy đi khỏi nhóm sửa nơi tiền thực sự nằm ở đó.

Cái bẫy 30 ngày khiến mã lý do dễ mất

Có một giới hạn cứng ở phía Google biến điều này từ một tính năng báo cáo thành một hạn chót. Nếu bạn không thu thập các mã liên tục, bạn đang mất chúng.

Voided Purchases API chỉ nhìn lại 30 ngày

Google nói rõ rằng API chỉ có thể hiển thị các giao dịch bị void trong 30 ngày qua. Các lần void cũ hơn không được trả về dù bạn truyền startTime nào, và bản thân giá trị startTime không thể đặt sớm hơn 30 ngày trước. Tệ hơn cho một phần tích hợp ngây thơ, cửa sổ 30 ngày được đo bằng thời điểm hệ thống của Google nhìn thấy một giao dịch là bị void, không phải thời điểm giao dịch được thực hiện hay thậm chí bằng voidedTimeMillis trong bản ghi. Vậy nên một mã lý do hoàn tiền bạn không kéo về trong cửa sổ đó là mất, và một công việc xuất dữ liệu hàng tháng có bất kỳ khoảng trống nào sẽ âm thầm bỏ rơi các lần void nó quá chậm không bắt kịp.

Các mã lý do đáng giá bao nhiêu tiền

Hai mã mang một cái giá cụ thể, và đọc chúng là cách bạn đặt một con số lên những vấn đề nếu không sẽ ẩn bên trong một tỷ lệ hoàn tiền tổng hợp.

Một mã là hóa đơn bạn tự viết cho mình

voidedReason 8, unacknowledged purchase, là ví dụ sạch nhất về một khoản hoàn tiền do bạn gây ra. Google Play yêu cầu ứng dụng của bạn xác nhận một giao dịch trong ba ngày kể từ khi cấp quyền, và nếu bạn không làm, Google tự động hoàn tiền đơn hàng và thu hồi mục đó. Mỗi lần void đóng dấu 8 là một lượt bán thực, từ một khách hàng muốn sản phẩm, bị trả lại vì một lệnh gọi để xác nhận giao dịch chưa bao giờ kích hoạt. Số tiền mất là toàn bộ giá bán cộng với tính toán, lệnh gọi API, và lưu trữ mà bạn đã bỏ ra để giao nó. Đây không phải khoản hoàn tiền bạn đàm phán. Đây là một lỗi bạn đóng lại, và mã là cách bạn tìm ra nó.

Mã chargeback nay kèm một khoản phí

voidedReason 7, chargeback, đã đổi chi phí vào ngày 3 tháng 8, 2026. Với các đơn hàng Google Play đặt vào hoặc sau ngày đó, một chargeback thua khiến nhà phát triển mất giá mua trừ đi phí dịch vụ của Play, cộng thêm phí chargeback của ngân hàng, trong khi Google chỉ bù phí dịch vụ của riêng mình. Vì phí chargeback là cố định còn giá sản phẩm thì không, trên một giao dịch trong ứng dụng rẻ tiền thì riêng khoản phí có thể vượt quá số khách hàng đã trả. Đếm các lần void mã 7 của bạn nay là đếm một mục chi phí, không chỉ một lượt bán bị mất, và đó chính xác là lý do nhóm chargeback xứng đáng có hàng riêng của nó trong bất kỳ báo cáo hoàn tiền nào bạn dựng.

Apple và Google xếp hàng thế nào

Hai cửa hàng trả lời cùng một câu hỏi ở các độ phân giải khác nhau, nên một báo cáo hoàn tiền liên cửa hàng phải chuẩn hóa chúng thay vì mong chúng khớp nhau.

Hai cửa hàng sẽ không bao giờ cho bạn cùng một mã cho cùng một khoản hoàn tiền, và điều đó không sao. Điều quan trọng là cả hai đều trao cho bạn một lý do máy đọc được, và cả hai đều tưởng thưởng một nhóm chịu đọc nó. Một bit duy nhất của Apple cho bạn biết khi nào một khoản hoàn tiền là lỗi của sản phẩm bạn. Chín lý do của Google và cờ nguồn của nó cho bạn biết lỗi sản phẩm nào, tranh chấp nào, và khoảng trống tính tiền tự gây ra nào bạn đang nhìn thấy. Không mã nào ngăn được một khoản hoàn tiền. Cả hai cho bạn biết phải làm gì để lần sau không xảy ra.

RefundHalt bắt lấy mã lý do trên mỗi khoản hoàn tiền ngay khoảnh khắc nó đến, trên cả hai cửa hàng, và giữ nó thật an toàn bên trong cửa sổ 30 ngày của Google để không gì lọt mất. Nó phân loại mỗi lần void thành sửa, tranh luận, hoặc chấp nhận, để một đợt tăng mã 3 lỗi đến với bạn như một cảnh báo sản phẩm và một đợt tăng mã 8 không được xác nhận đến với bạn như một lỗi tích hợp, chứ không phải như một sự sụt giảm doanh thu mơ hồ. Nó trả lời CONSUMPTION_REQUEST của Apple trong 12 giờ và cuộc xem xét chargeback của Google Play trong 24, và nó thu hồi quyền truy cập ngay khi một khoản hoàn tiền hoặc chargeback rơi vào. Bạn không thể thay đổi mã mà một cửa hàng đóng lên một khoản hoàn tiền. Bạn có thể chắc chắn rằng bạn đọc mọi mã, và hành động trên những cái thực sự thuộc về bạn để sửa.