Mọi yêu cầu hoàn tiền của Apple giờ đều kèm theo lý do, và consumptionRequestReason là cách bạn đọc nó

Apple đã thay đổi cách các yêu cầu hoàn tiền đến máy chủ của bạn, và rất nhiều nhà phát triển chưa từng để ý. Kể từ bản cập nhật App Store Server Notifications 2.11 được công bố tại WWDC24, mỗi thông báo CONSUMPTION_REQUEST đều mang theo một trường tên là consumptionRequestReason. Đó là lý do do chính khách hàng nêu ra khi đòi lại tiền. Một chuỗi đơn giản, năm giá trị khả dĩ, được gửi trong cùng payload mà bạn vốn đã có mười hai giờ để trả lời.

Lý do yêu cầu hoàn tiền của Apple tự nó không quyết định điều gì. Điều nó làm là cho bạn biết bạn đang ở trong tình huống nào trong năm tình huống rất khác nhau, để bạn ngừng gửi cùng một loại dữ liệu tiêu thụ chung chung cho khoản hoàn tiền nên chấp thuận lẫn khoản hoàn tiền nên tranh cãi. Đây là trường đó là gì, các giá trị chính xác Apple có thể gửi, mỗi giá trị báo hiệu điều gì, và nó nên thay đổi ra sao tùy chọn cùng bằng chứng bạn gửi lại.

consumptionRequestReason thực chất là gì

consumptionRequestReason là một trường chuỗi trong đối tượng data của thông báo CONSUMPTION_REQUEST. Apple đã thêm nó ở App Store Server Notifications phiên bản 2.11, cùng với những thay đổi quy trình hoàn tiền tại WWDC24. Trước đó, yêu cầu đến kèm giao dịch đã ký và không có gì về động cơ. Bạn trả lời trong mù mờ. Giờ đây lý do do khách hàng nêu ra đi cùng với yêu cầu.

Hãy đọc kỹ từ nêu ra. Đây là lý do khách hàng đã chọn khi nộp lên Apple, không phải một sự thật được Apple xác minh. UNINTENDED_PURCHASE không chứng minh giao dịch mua chưa được dùng, và UNSATISFIED_WITH_PURCHASE không chứng minh sản phẩm bị hỏng. Giá trị này là một lăng kính, không phải một phán quyết. Bạn vẫn phải ghép nó với hồ sơ giao hàng và sử dụng của chính mình.

Nó đi kèm trong thông báo bạn vốn đã xử lý

CONSUMPTION_REQUEST là quy trình duy nhất của Apple thực sự yêu cầu bằng chứng từ nhà phát triển. Bản tương ứng bên Google Play là quá trình xét duyệt chargeback qua orders.reviewrefund. Khi một yêu cầu đến, bạn có 12 giờ để trả lời bằng cách gọi Send Consumption Information, một lệnh PUT tới endpoint tiêu thụ của giao dịch. consumptionRequestReason giờ là một phần của chính thông báo đó, nên không có gì mới để đăng ký nhận. Nếu bạn đã phân tích cú pháp CONSUMPTION_REQUEST, lý do chỉ là một trường mà bạn có lẽ đã bỏ qua.

Năm lý do, và mỗi lý do đang nói với bạn điều gì

Apple ghi tài liệu đúng năm giá trị. Một giá trị đến cho mỗi yêu cầu. Đây là toàn bộ tập giá trị và cách đọc từng cái trong thực tế.

UNINTENDED_PURCHASE là nhóm chạm nhầm

Đây là lý do một phụ huynh chọn sau khi con họ mua 10,000 xu, hoặc một người lớn bấm nhầm nút xác nhận. Nó tương quan với những giao dịch mua chưa bao giờ được mở hay sử dụng. Chính vì thế mà dữ liệu của bạn quan trọng. Nếu hồ sơ của bạn cho thấy hàng tiêu hao đã được giao đầy đủ và tiêu thụ nhiều, một khiếu nại mua nhầm và một số dư đã tiêu hết không ăn khớp với nhau, và khoảng chênh đó đáng được báo cáo qua consumptionPercentage.

FULFILLMENT_ISSUE chỉ ngược về phía bạn

FULFILLMENT_ISSUE là lý do duy nhất phần nào liên quan tới ứng dụng của bạn, chứ không phải khách hàng. Nó có nghĩa họ nói không nhận hoặc không dùng được thứ họ đã trả tiền. Trước khi phản xạ tranh cãi, hãy lôi nhật ký giao hàng của bạn ra. Nếu chính máy chủ của bạn cho thấy quyền lợi chưa bao giờ được kích hoạt, hoặc tín dụng chưa bao giờ được ghi có, thì khách hàng đúng, và DECLINE là tùy chọn sai. Đấu tranh với một thất bại giao hàng có thật sẽ lãng phí khung thời gian và có thể đẩy khách hàng đến ngân hàng của họ, nơi một chargeback tốn kém hơn khoản hoàn tiền.

UNSATISFIED_WITH_PURCHASE là nơi bằng chứng quyết định

Đây là sự hối tiếc thông thường của người mua, và là lý do nơi dữ liệu tiêu thụ của bạn làm việc nhiều nhất. Sản phẩm đã hoạt động. Khách hàng đã dùng một phần hoặc toàn bộ và giờ muốn lấy lại tiền. Một consumptionPercentage cao, một deliveryStatus trung thực là DELIVERED, và một refundPreference là DECLINE hoặc GRANT_PRORATED chính là lập luận mà Apple đang yêu cầu bạn đưa ra. Hãy gửi các con số, đừng gửi lời tranh cãi.

LEGAL và OTHER

LEGAL nghĩa là khách hàng viện dẫn một quyền pháp lý hoặc quy định. Người hợp lý có thể bất đồng, nhưng theo nguyên tắc thì đây không phải khung thời gian để tranh tụng. Hãy chấp thuận và bỏ qua. OTHER là ô gom chung mà Apple dùng khi lý do được nêu không khớp với bất kỳ giá trị nào trong bốn cái trên. Tự nó không mang tín hiệu, nên hãy xử lý một OTHER đúng như một yêu cầu hoàn toàn không có lý do: dẫn đầu bằng trạng thái giao hàng và bằng chứng sử dụng của bạn.

Lý do thay đổi câu trả lời của bạn ra sao, từng trường một

Bạn phản hồi một CONSUMPTION_REQUEST bằng cách gọi Send Consumption Information với một body ConsumptionRequest. Lý do nên định hình ba trường trong body đó.

customerConsented phải là true

Apple chỉ chấp nhận đệ trình khi customerConsented là true, nghĩa là khách hàng đã đồng ý chia sẻ dữ liệu tiêu thụ. Nếu bạn không có sự đồng ý đó, bạn không thể gửi dữ liệu gì cả, bất kể lý do là gì. Không đồng ý, không bằng chứng, và yêu cầu được quyết định mà không có con số nào của bạn.

deliveryStatus và consumptionPercentage mang các sự thật

deliveryStatus cho biết bạn có giao một giao dịch mua hoạt động được hay không. Nếu nó là bất cứ giá trị nào khác DELIVERED, Apple yêu cầu consumptionPercentage phải là 0. Khi bạn thực sự đã giao, consumptionPercentage là một số nguyên tính bằng milliunits từ 0 đến 100,000, trong đó 100,000 nghĩa là khách hàng đã dùng toàn bộ giao dịch mua. Cặp giá trị này là lõi sự thật của bạn, và đó là thứ nên mang một tình huống FULFILLMENT_ISSUE hay UNSATISFIED_WITH_PURCHASE, chứ không phải bản thân lý do.

refundPreference là đòn bẩy duy nhất của bạn

refundPreference là nơi bạn nêu điều mình muốn. Apple ghi tài liệu ba giá trị: GRANT_FULL, GRANT_PRORATED, và DECLINE. Đọc lý do, cân nhắc nó với dữ liệu của bạn, rồi chọn. FULFILLMENT_ISSUE với một giao hàng thất bại trong nhật ký của bạn nghiêng về GRANT_FULL. UNSATISFIED_WITH_PURCHASE trên một sản phẩm đã tiêu thụ hết nghiêng về DECLINE hoặc GRANT_PRORATED. LEGAL nghiêng về GRANT_FULL.

Một khoản hoàn tiền thực sự khiến bạn tốn gì

Trường lý do quan trọng vì một khoản hoàn tiền hiếm khi chỉ là một giao dịch bán bị gạch khỏi sổ cái của bạn. Với một hàng tiêu hao đã chạy xong, bạn đã trả tiền để thực hiện nó. Một gói tín dụng gọi một API suy luận trả phí, một lô ảnh được tạo đốt thời gian GPU, một bản xuất lưu trữ nằm trên hóa đơn lưu trữ của bạn, một khoản chi trả cho nhà sáng tạo bạn đã gửi: những chi phí đó vẫn mất đi khi giao dịch mua bị đảo ngược. Cửa hàng trả lại tiền cho khách hàng. Nó không trả lại phần tính toán của bạn.

Đó là lý do vì sao lý do đáng đọc. Giả sử một khách hàng mua 5,000 tín dụng mà mỗi tín dụng kích hoạt một lệnh gọi API trả phí, tiêu 4,000 trong số đó, rồi nộp đơn dưới UNSATISFIED_WITH_PURCHASE. deliveryStatus của bạn là DELIVERED, consumptionPercentage của bạn là 80,000 milliunits, và một tùy chọn DECLINE hoặc GRANT_PRORATED là ranh giới giữa việc gánh hóa đơn API và thu hồi phần lớn nó. Giờ đổi lý do thành FULFILLMENT_ISSUE với nhật ký cho thấy tín dụng chưa bao giờ được ghi có, thì bước đi trung thực và rẻ hơn là GRANT_FULL trước khi khách hàng leo thang lên ngân hàng của họ.

Đọc lý do mà không phản ứng thái quá

Cái bẫy là coi lý do như bằng chứng. UNINTENDED_PURCHASE không phải lời thú nhận rằng sản phẩm chưa được dùng, và LEGAL không phải lúc nào cũng là một khiếu nại pháp lý thực sự. Lý do thu hẹp tình huống. Nhật ký giao hàng và hồ sơ tiêu thụ của bạn mới giải quyết nó. Khi chúng đồng thuận với khách hàng, hãy chấp thuận sớm và rẻ. Khi chúng mâu thuẫn với khách hàng, mâu thuẫn đó, được thể hiện dưới dạng deliveryStatus và consumptionPercentage, là thứ mạnh nhất bạn có thể gửi. RefundHalt đọc consumptionRequestReason trên mỗi CONSUMPTION_REQUEST và tự động ghép nó với dữ liệu sử dụng thực của bạn, để mỗi lý do nhận được phản hồi xứng đáng trong khung thời gian 12 giờ.

Thay đổi này nhỏ và dễ bỏ lỡ, nhưng nó đã chuyển cuộc trao đổi hoàn tiền về phía có lợi cho bạn. Apple giờ đang cho bạn biết lý do, trước khi bạn trả lời. Hãy tận dụng nó.