Apple có thể đảo ngược một khoản hoàn tiền đã cấp, và một khoản hoàn tiền bị đảo ngược mà máy chủ của bạn bỏ qua sẽ khóa quyền truy cập của một khách hàng đã trả tiền

Một khoản hoàn tiền không phải lúc nào cũng là phán quyết cuối cùng. App Store có thể đảo ngược một khoản hoàn tiền đã cấp, sau khi khách hàng khiếu nại, và khi khoản hoàn tiền bị đảo ngược đó đến máy chủ của bạn, nó mang theo một chỉ dẫn: hãy trả lại quyền truy cập. Hầu hết các nhóm chỉ đấu nối thông báo REFUND đơn giản, cắt quyền của khách hàng, rồi dừng ở đó. Họ không bao giờ xây dựng nửa còn lại. Vì vậy khi việc đảo ngược đến, không có gì chạy, và một khách hàng đang trả tiền lần nữa vẫn bị khóa khỏi thứ họ đã mua. Đây là cách toàn bộ tập hợp thông báo hoàn tiền hoạt động trên App Store và Google Play, cùng cái giá của mỗi thông báo khi bạn bỏ qua nó.

App Store gửi ba thông báo hoàn tiền, không phải một

Hầu hết việc xử lý hoàn tiền được xây dựng cho một sự kiện duy nhất: tiền đã được trả lại, cắt quyền khách hàng. Luồng App Store Server Notifications V2 thực ra mang theo ba kết quả hoàn tiền riêng biệt, và chúng yêu cầu ba thứ khác nhau. Hai trong số đó thay đổi những gì khách hàng có thể truy cập. Một trong số đó hoàn tác thứ đầu tiên. Đây là toàn bộ tập hợp, bằng chính lời của Apple.

REFUND, thông báo mà mọi nhóm đều xử lý

Khi App Store xử lý một khoản hoàn tiền, nó gửi một thông báo REFUND đến URL bạn cấu hình, và định nghĩa của Apple rất rõ ràng: nó 'cho biết App Store đã hoàn tiền thành công một giao dịch cho một In-App Purchase tiêu hao, một In-App Purchase không tiêu hao, một gói đăng ký tự động gia hạn, hoặc một gói đăng ký không gia hạn.' Bạn lưu giao dịch được hoàn tiền, thu hồi bất cứ thứ gì nó đã mua, và Apple yêu cầu bạn cho khách hàng biết điều gì đã thay đổi bằng thông điệp theo ngữ cảnh trong ứng dụng. Đây là thông báo mà mọi người đấu nối đầu tiên, và thường là thông báo duy nhất.

REFUND_DECLINED, thông báo không cần gì từ bạn

REFUND_DECLINED có nghĩa đúng như tên gọi: 'App Store đã từ chối một yêu cầu hoàn tiền.' Khách hàng đã hỏi, Apple nói không, và giao dịch vẫn có hiệu lực. Không có gì về quyền truy cập của khách hàng thay đổi, nên logic quyền lợi của bạn không làm gì ở đây. Giá trị của thông báo này là việc ghi sổ. Nó khép lại một yêu cầu hoàn tiền mà bạn có thể đã trả lời bằng một CONSUMPTION_REQUEST, và xác nhận khách hàng vẫn có những gì họ đã trả tiền. Hãy coi nó là một bản ghi, không phải một hành động.

REFUND_REVERSED, thông báo khiến các nhóm bất ngờ

Đây là thông báo mà hầu hết các pipeline hoàn tiền không bao giờ xử lý. Định nghĩa của Apple rõ ràng không mập mờ: REFUND_REVERSED 'cho biết App Store đã đảo ngược một khoản hoàn tiền được cấp trước đó do một khiếu nại mà khách hàng nêu ra. Nếu ứng dụng của bạn đã thu hồi nội dung hoặc dịch vụ do khoản hoàn tiền liên quan, nó cần khôi phục lại chúng.' Hãy đọc điều đó hai lần. Apple đã cấp cho khách hàng một khoản hoàn tiền, bạn đã thu hồi quyền truy cập, rồi Apple quyết định khoản hoàn tiền không nên có hiệu lực và rút nó lại. Khoản phí lại hoạt động. Khách hàng đã trả tiền, và nếu máy chủ của bạn chỉ biết cách thu hồi, họ vẫn bị khóa. Một khoản hoàn tiền bị đảo ngược là sự kiện hoàn tiền duy nhất thêm quyền truy cập trở lại, và đó là sự kiện gần như không ai xây dựng để xử lý.

Một khoản hoàn tiền bị đảo ngược thực sự khiến bạn tốn bao nhiêu

Một lần đảo ngược bị bỏ lỡ không phải là sai số làm tròn. Hãy lần theo dòng tiền theo cả hai hướng, vì làm sai nửa nào cũng có cái giá.

Bỏ lỡ việc đảo ngược và bạn giữ một khách hàng đang trả tiền bị khóa. Apple đã khôi phục khoản phí, nên khách hàng lại mất tiền, và ứng dụng của bạn đang từ chối cho họ thứ họ đã mua. Chi phí trước mắt là thời gian hỗ trợ và một khoản hoàn tiền thiện chí mà giờ bạn có thể phải tự cấp, lần này không có hoa hồng cửa hàng nào trả lại để giảm nhẹ. Chi phí chậm hơn là đánh giá và tỷ lệ rời bỏ, và trên Google Play chính sự bực bội vì bị khóa đó là thứ biến thành một khoản chargeback.

Bỏ lỡ khoản hoàn tiền ban đầu và bạn tiếp tục phục vụ một khách hàng không trả gì cả. Sai lầm phản chiếu là không bao giờ thu hồi. Một khách hàng đã được hoàn tiền mà vẫn tạo hình ảnh, gọi các API của bạn, và làm đầy bộ lưu trữ của bạn sẽ tích lũy chi phí thực đối với một giao dịch bán hàng đã bị đảo ngược. Tính toán, các lệnh gọi bên thứ ba, và lưu trữ là tiền bạn đã chi, và không khoản nào quay lại cùng với khoản hoàn tiền.

• Chi phí hỗ trợ: một con người trả lời một phiếu về quyền truy cập mà chính mã của bạn đã gỡ bỏ và không bao giờ khôi phục.
• Hoàn tiền thiện chí: cấp lại tiền cho một khách hàng bạn khóa nhầm, không có hoa hồng cửa hàng nào được trả lại cho một cử chỉ thủ công.
• Chi tiêu lãng phí: tính toán, các lệnh gọi API, và lưu trữ bị tiêu thụ bởi một tài khoản đã được hoàn tiền mà bạn không bao giờ cắt quyền.
• Rủi ro chargeback: trên Google Play, một khách hàng cảm thấy bị tính phí hai lần có thể khiếu nại, và một khiếu nại bị thua giờ đây rơi vào bạn.

Khoản hoàn tiền bị đảo ngược và khoản hoàn tiền đơn giản là cùng một luồng webhook chỉ theo hai hướng ngược nhau. Xử lý cái này và bỏ qua cái kia thì bạn trả giá ở cả hai đầu.

Vì sao Apple đảo ngược một khoản hoàn tiền, và cách đọc revocationReason

Một lần đảo ngược không phải ngẫu nhiên. Apple gắn nó với 'một khiếu nại mà khách hàng nêu ra', tức là khách hàng phản đối quyết định hoàn tiền sau khi việc đã rồi. Khi khoản hoàn tiền được cấp lần đầu, giao dịch mang theo một revocationDate và một revocationReason, và lý do đó đáng để đọc trước khi bất cứ thứ gì phía sau hành động dựa trên nó.

• revocationReason 1: App Store hoàn tiền 'do một vấn đề thực tế hoặc được cảm nhận bên trong ứng dụng của bạn.' Đó là một tín hiệu về sản phẩm của bạn, không chỉ về khách hàng này.
• revocationReason 0: App Store hoàn tiền 'vì các lý do khác, ví dụ như mua nhầm.' Không có tín hiệu chất lượng ứng dụng nào kèm theo.

Khi một REFUND_REVERSED đến cho giao dịch đó, việc thu hồi đang được hoàn tác. Logic khôi phục của bạn nên tra cứu id giao dịch gốc, xác nhận rằng bạn đã thu hồi nó, và đặt quyền lợi trở lại đúng như trước.

Google Play không gửi một lần đảo ngược, nên thay vào đó bạn đối soát

Mô hình của Google Play thì khác, và sự khác biệt này quan trọng nếu bạn chạy cả hai cửa hàng qua một trình xử lý webhook. Không có thứ tương đương của Google cho REFUND_REVERSED. Thông báo dành cho nhà phát triển theo thời gian thực của Google chia các sự kiện hoàn tiền thành hai thông điệp, và việc đảo ngược được xử lý bằng đối soát, không phải bằng push.

Thông báo giao dịch mua bị hủy

Khi một giao dịch mua trên Google Play bị hủy, máy chủ của bạn nhận được một VoidedPurchaseNotification. Nó nêu purchaseToken và orderId, một productType là subscription hoặc one-time, và một refundType là một lần hủy toàn bộ hoặc một khoản hoàn tiền một phần dựa trên số lượng đối với các giao dịch mua nhiều số lượng. Google nói dữ liệu đó đủ để tìm đúng giao dịch mua và điều chỉnh quyền lợi. Với bất cứ điều gì hơn thế, nó chỉ bạn đến Voided Purchases API, một mô hình kéo liệt kê các đơn hàng bị hủy trong một khoảng thời gian bạn truy vấn.

Việc xem xét chargeback, và bộ đếm 24 giờ của nó

Các khoản chargeback đến qua một thông điệp khác, PendingRefundReviewNotification. Khi một khách hàng khiếu nại một khoản phí với ngân hàng của họ, Google Play gửi thông báo này và bắt đầu một bộ đếm. Bạn có 24 hours để gọi orders.reviewrefund với một tùy chọn hoàn tiền và bất kỳ bằng chứng sử dụng nào, để Google có thể phản bác một khoản chargeback bất hợp pháp thay mặt bạn. Google ghi nhận lần gọi đầu tiên của bạn và bỏ qua phần còn lại. Đây là tương đương của Google với CONSUMPTION_REQUEST của Apple, cửa sổ duy nhất mà phía của bạn trong một tranh chấp được tính đến.

Vì không có push đảo ngược, một khoản chargeback mà Google phản bác và thắng không đến dưới dạng một sự kiện khôi phục gọn gàng. Bạn đối soát nó với Voided Purchases API và hồ sơ của riêng bạn. Bài học giống như trên App Store: một đơn hàng bị hủy không phải lúc nào cũng vĩnh viễn, và trạng thái quyền lợi của bạn phải có khả năng lùi lại, không chỉ tiến lên.

Cách xử lý mọi thông báo hoàn tiền mà không khóa quyền của ai

Bạn không cần các pipeline riêng cho từng cửa hàng. Bạn cần một trình xử lý có thể di chuyển một quyền lợi theo cả hai hướng và coi mọi thông điệp là có thể bị trùng lặp.

• Xây dựng khôi phục, không chỉ thu hồi. Với mỗi đường dẫn gỡ bỏ quyền truy cập khi có REFUND, hãy viết đường nghịch đảo khôi phục nó khi có REFUND_REVERSED, gắn với cùng một id giao dịch.
• Làm cho nó idempotent. Cả hai cửa hàng đều có thể gửi cùng một thông báo hơn một lần, nên hãy gắn mỗi lần thu hồi và khôi phục với id giao dịch hoặc đơn hàng và làm cho một lần lặp lại không có tác động gì.
• Đọc lý do trước khi hành động. Dùng revocationReason để phân biệt một khoản hoàn tiền vì chất lượng ứng dụng với một khoản mua nhầm, và chuyển những khoản vì chất lượng ứng dụng đến người phụ trách chất lượng sản phẩm.
• Trả lời các cửa sổ bằng chứng đúng hạn. Gửi dữ liệu tiêu thụ của Apple trong vòng 12 hours kể từ một CONSUMPTION_REQUEST, và gọi orders.reviewrefund trong vòng 24 hours kể từ một PendingRefundReviewNotification.
• Lưu mọi sự kiện. Giữ lại REFUND_DECLINED và các thông báo thô, để một lần đảo ngược đến sau này có thể được khớp với khoản hoàn tiền mà nó hoàn tác.

Không điều nào trong số này thay đổi việc một khoản hoàn tiền có xảy ra hay không. Nó thay đổi việc liệu khách hàng ở phía bên kia của một khoản hoàn tiền bị đảo ngược có bao giờ nhận ra máy chủ của bạn đã xử lý sai hay không.