Thu Hồi Quyền Truy Cập Sau Khi Hoàn Tiền: Bước Mà Apple và Google Không Tự Làm Thay Bạn

Chấp thuận hoàn tiền và thu hồi quyền truy cập là hai bước tách biệt, và chỉ một trong hai bước đó diễn ra tự động. Các nhà phát triển cho rằng một khoản hoàn tiền đã xử lý đồng nghĩa với việc quyền truy cập đã bị thu hồi đều sai trên cả hai nền tảng lớn, theo những cách khác nhau và vì những lý do khác nhau. Biết chính xác nơi tự động hóa dừng lại chính là điều cần thiết để thu hồi quyền truy cập sau một khoản hoàn tiền, thay vì phát hiện ra nhiều tháng sau rằng điều đó chưa từng xảy ra.

Vì sao hoàn tiền không mặc định thu hồi quyền truy cập

Cả Apple và Google đều xem tiền và quyền truy cập là hai hoạt động khác nhau. Phía tiền bạc là chính sách của cửa hàng, một khi khoản hoàn tiền được duyệt, nó là quyết định cuối cùng và sổ sách được cập nhật. Phía quyền truy cập là tùy chọn, hoặc là việc của nhà phát triển, hoặc cả hai, tùy thuộc vào nền tảng và loại giao dịch mua. Không cửa hàng nào mặc định cho rằng bạn muốn quyền truy cập biến mất ngay khi khoản hoàn tiền hoàn tất, vì rất nhiều trường hợp hợp lệ (hoàn tiền một phần, tín dụng thiện chí, cử chỉ hỗ trợ khách hàng) vốn không nhằm mục đích lấy lại sản phẩm.

Google Play: ô đánh dấu mà không ai để ý

Trong Play Console, hoàn tiền một đơn hàng là một biểu mẫu gồm hai phần, chọn số tiền hoàn, rồi quyết định riêng biệt có đánh dấu "Remove entitlement" hay không. Để trống ô đó là lựa chọn mặc định mà hầu hết nhân viên hỗ trợ thực hiện, vì phần lớn yêu cầu hoàn tiền là cử chỉ thiện chí, nơi khách hàng vẫn giữ những gì họ đã mua. Vấn đề là không có gì trên màn hình xác nhận hoàn tiền cho bạn biết rằng đây cũng là cách một khách hàng vẫn giữ được subscription hoặc vật phẩm trong ứng dụng sau một khoản hoàn tiền mà bạn muốn là quyết định cuối cùng.

Đường dẫn API cũng mắc phải cạm bẫy tương tự

Lựa chọn tương tự cũng tồn tại trong mã nguồn. Endpoint orders.refund nhận một tham số truy vấn revoke không bắt buộc, khi giá trị đó là true, quyền truy cập vào vật phẩm bị chấm dứt ngay lập tức, và đối với một subscription định kỳ, mọi khoản thanh toán trong tương lai cũng bị hủy theo. Nếu bỏ qua tham số này, giá trị mặc định sẽ là false, khoản hoàn tiền vẫn được ghi nhận, bản ghi giao dịch mua được cập nhật, và người dùng vẫn tiếp tục sử dụng sản phẩm y như trước.

Chính hàng cuối cùng đó là điều khiến các tích hợp mắc bẫy. Voided Purchases API tồn tại để bạn có thể xây dựng một pipeline thu hồi mà không cần kiểm tra Play Console thủ công, nhưng nó chỉ liệt kê những đơn hàng thực sự bị hủy kèm thu hồi. Một khoản hoàn tiền được xử lý mà không có ô đánh dấu đó, hoặc không có revoke=true, vốn được thiết kế để vô hình với nguồn dữ liệu đó, đây không phải là lỗi.

Đọc trường voidedReason Khi một giao dịch mua thực sự xuất hiện là đã hủy, trường voidedReason cho bạn biết lý do, theo thang chín giá trị: other, remorse, not_received, defective, accidental_purchase, fraud, friendly_fraud, chargeback, và unacknowledged_purchase. Đó không chỉ đơn thuần là ghi sổ. Remorse và accidental_purchase là những khoản hoàn tiền thông thường. Fraud, friendly_fraud, và chargeback là những giá trị đáng để chuyển đến hàng đợi xét duyệt gian lận thay vì một quy trình thu hồi rồi bỏ qua đơn giản, vì cùng một tài khoản đó về mặt thống kê có nhiều khả năng lặp lại hành vi này hơn.

Có một chi tiết vận hành quan trọng nếu bạn xây dựng trực tiếp dựa trên nguồn dữ liệu này: purchases.voidedpurchases.list bị giới hạn ở mức 6.000 truy vấn mỗi ngày và 30 truy vấn trong bất kỳ khoảng thời gian 30 giây nào. Một thiết kế thăm dò liên tục trong một vòng lặp gấp gáp sẽ nhanh chóng chạm ngưỡng đó. Mô hình được khuyến nghị là kéo dữ liệu theo lịch trình với pagination token, không phải thăm dò liên tục.

Apple: App Store có thể thu hồi giấy phép, nhưng không thể với consumable

App Store Server Notifications V2 của Apple gửi một thông báo REFUND ngay khi khoản hoàn tiền hoàn tất, áp dụng như nhau cho consumable, non-consumable, subscription auto-renewable, và subscription non-renewing. Điều gì xảy ra sau thông báo đó hoàn toàn phụ thuộc vào loại giao dịch mua, vì cơ chế thu hồi riêng của StoreKit chỉ bao phủ hai trong bốn loại đó.

Vì sao consumable là ngoại lệ

Một non-consumable hoặc một subscription có một quyền sở hữu cố định mà hệ thống của Apple có thể tắt đi. Một consumable thì không, một khi đã được sử dụng, nó được xem là đã giao, và không còn gì trong StoreKit để thu hồi. Nếu một khách hàng mua 500 coins, tiêu hết chúng, rồi được hoàn tiền, số coins đó đã biến mất theo quan điểm của Apple. Sổ sách duy nhất còn ghi nhận chúng là sổ sách của bạn. Thông báo REFUND là tín hiệu duy nhất để bạn tìm original transaction ID tương ứng và trừ số dư đó khỏi hồ sơ của chính mình; không có gì ở phía Apple sẽ làm việc đó thay bạn.

Thông báo mà hầu như không ai xử lý

REFUND_REVERSED là thông báo mà hầu hết các tích hợp bỏ qua hoàn toàn, vì nó mô tả việc Apple hủy chính quyết định của mình, một trường hợp mà ít nhà phát triển thiết kế sẵn ngay từ đầu. Khi thông báo này đến, revocationDate trên giao dịch trở về null, theo quan điểm của Apple, giao dịch mua đó lại hợp lệ. Nếu máy chủ của bạn đã xóa một entitlement, hủy một bản ghi subscription, hoặc đưa số dư consumable về 0 khi REFUND ban đầu đến, thì REFUND_REVERSED chính là tín hiệu để khôi phục lại tất cả.

Cách khắc phục khoảng trống này, từng bước một

• Trên Google Play, đặt revoke=true làm mặc định cho mọi luồng hoàn tiền, dù đi qua Play Console hay API, trừ khi có một trường hợp hỗ trợ cụ thể yêu cầu khách hàng được giữ lại quyền truy cập.
• Thăm dò purchases.voidedpurchases.list theo lịch trình với pagination token, không phải trong một vòng lặp gấp gáp, và giữ dưới mức 6.000 yêu cầu mỗi ngày và 30 yêu cầu trong mỗi 30 giây.
• Chuyển các giá trị voidedReason là fraud, friendly_fraud, và chargeback đến một hàng đợi xét duyệt thay vì thu hồi rồi đóng lại tự động.
• Trên Apple, đăng ký App Store Server Notifications V2 và thu hồi quyền truy cập non-consumable cùng subscription ngay khi một thông báo REFUND nêu tên chúng.
• Lưu original transaction ID cho mỗi giao dịch mua consumable để một thông báo REFUND có thể tìm ra chính xác số dư cần trừ mà không cần tra cứu thủ công.
• Xử lý REFUND_REVERSED một cách rõ ràng và ghi lại mỗi lần thu hồi theo transaction hoặc order ID của nó, để một lần đảo ngược có thể khôi phục chính xác những gì đã bị xóa.

Cái giá thực sự của khoảng trống này

Tất cả những điều này không phải là chuyện công bằng với khách hàng, mà là chuyện điều gì vẫn tiếp tục vận hành sau khi tiền đã mất. Một subscription đã hoàn tiền nhưng vẫn tiếp tục gọi API, lưu trữ dữ liệu, và tiêu tốn compute không phải là một vấn đề đạo đức, đó là một khoản chi phí, bạn đang trả tiền hạ tầng cho một giao dịch mà bạn đã hoàn lại doanh thu. Các cửa hàng không theo dõi chi phí đó thay bạn, vì từ phía họ, khoản hoàn tiền đã hoàn tất ngay khi tiền được chuyển đi. Phía quyền truy cập hoàn toàn là hóa đơn mà bạn phải tự kiểm soát.

Đây cũng là lý do RefundHalt xem việc thu hồi là một phần của pipeline hoàn tiền, chứ không phải một suy nghĩ muộn màng, một sự kiện REFUND và một thay đổi quyền truy cập được ghi nhận như một hành động duy nhất, và một sự kiện REFUND_REVERSED tự động khôi phục trạng thái thay vì chờ ai đó nhận ra khách hàng vẫn đang bị khóa khỏi thứ mà Apple đã trả lại.