Hỏi mười nhóm phát triển iOS về cách họ quản lý hoàn tiền của Apple, chín trong số đó sẽ mô tả cùng một cách làm. Một file CSV, được tải xuống từ App Store Connect vào khoảng ngày mùng 5 hàng tháng. Đọc một lần, thở dài, rồi đóng lại.
Đó không phải là quản lý. Đó là khám nghiệm tử thi.
Apple đưa ra mọi quyết định hoàn tiền và bạn không có quyền biểu quyết. Những gì bạn nhận được là một loạt sự kiện, một khoảng thời gian ngắn để phản hồi một trong số đó, và một ngày thu hồi mà bạn cần hành động theo. Các nhóm thiết lập hệ thống xử lý những việc này sẽ giữ lại được số tiền mà những người chỉ đọc file CSV không bao giờ thấy. Về phía ghi nhận trước tiên, hãy bắt đầu với Cách theo dõi yêu cầu hoàn tiền của Apple và phản hồi đúng hạn. Bài viết đó bao quát toàn bộ công việc.
Những điểm chính
Quản lý yêu cầu hoàn tiền của Apple là công việc phía server. Không có hàng đợi hoàn tiền nào trong App Store Connect.
Chính sách hoàn tiền của Apple cho phép khách hàng tự thực hiện yêu cầu tại reportaproblem.apple.com. Bạn chỉ biết về việc này nếu bạn đã yêu cầu nhận thông báo.
Bốn loại thông báo bao quát toàn bộ vòng đời: CONSUMPTION_REQUEST, REFUND, REFUND_DECLINED, REFUND_REVERSED.
Khung thời gian phản hồi 12 giờ là nơi duy nhất mà ý kiến của bạn có thể thay đổi kết quả. Mọi thứ còn lại chỉ là dọn dẹp hậu quả.
Hầu hết các nhóm đều bỏ sót REFUND_REVERSED. Sự kiện này trả lại quyền truy cập, và việc quên xử lý nó sẽ khiến một khách hàng trung thực bị thiệt.
Quản lý yêu cầu hoàn tiền của Apple thực sự là gì
Đó là hệ thống bắt lấy một sự kiện hoàn tiền, phản hồi nếu cần, cập nhật những gì người dùng được phép làm, và ghi nhận số tiền. Bốn công việc. Không việc nào là tùy chọn, và chỉ một trong số đó xuất hiện trên dashboard mà Apple cung cấp cho bạn.
Chính sách hoàn tiền của Apple nghe có vẻ như phải có sự tham gia của bạn. Nhưng phần lớn thì không. Media Services Terms của Apple quy định mọi giao dịch đều là cuối cùng, vì vậy mỗi lần hoàn tiền là một ngoại lệ mà Apple tự quyết định cấp. Không có nút phê duyệt. Không có địa chỉ email khách hàng. Bạn thậm chí không thể biết ai đã gửi yêu cầu.
Điều bạn có thể làm là gửi bằng chứng trong khi Apple vẫn đang xem xét. Chính đòn bẩy đó là lý do tồn tại của quy trình này.
Quy trình yêu cầu hoàn tiền của Apple dành cho nhà phát triển, từ đầu đến cuối
Dưới đây là toàn bộ quy trình, theo thứ tự, từ phía khách hàng đến phía bạn.
Khách hàng truy cập reportaproblem.apple.com, đăng nhập, tìm một giao dịch mua trong 90 ngày qua, chọn lý do, rồi gửi yêu cầu. Kể từ iOS 15, bạn có thể hiển thị chính biểu mẫu đó ngay trong ứng dụng của mình bằng refund request sheet của StoreKit, đưa người dùng không hài lòng thẳng đến Apple mà không cần qua ticket hỗ trợ nào.
Nếu bạn đang chạy App Store Server Notifications V2, một CONSUMPTION_REQUEST sẽ được gửi đến endpoint của bạn kèm theo giao dịch, sản phẩm, và lý do mà họ đã chọn.
Bạn có khoảng 12 giờ để phản hồi bằng dữ liệu tiêu thụ (consumption data). Bạn phản hồi, hoặc không.
Apple ra quyết định: REFUND, REFUND_DECLINED, hoặc không có gì cả nếu bạn không lắng nghe.
Nếu được chấp thuận, payload sẽ mang theo ngày và lý do thu hồi. Quyền truy cập bị gỡ bỏ kể từ ngày đó, và bản ghi doanh thu của bạn thay đổi theo.
Đôi khi Apple đổi ý sau khi khách hàng khiếu nại. REFUND_REVERSED sẽ xuất hiện và bạn cần khôi phục lại quyền truy cập.
Bước 3 là bước duy nhất bạn có thể tác động đến kết quả. Bước 5 và 6 là nơi tiền âm thầm bị thất thoát.
Một điều cần biết trước khi bạn xây dựng hệ thống này: Apple khuyến cáo nhà phát triển không nên poll (thăm dò liên tục) để kiểm tra trạng thái hoàn tiền. Notifications là hướng đi được khuyến nghị, còn Get Refund History chỉ nên dùng để đối soát sau sự cố gián đoạn, chứ không phải làm nguồn dữ liệu chính.
Một ví dụ thực tế về giá trị của việc này
Có một thread nổi tiếng trên r/iOSProgramming, trong đó một nhà phát triển kể lại lần đầu tiên anh xử lý CONSUMPTION_REQUEST. Anh đã bỏ qua nó suốt nhiều tháng. Sau khi thiết lập phản hồi tự động, anh đã lấy lại khoảng $1,000 doanh thu hàng tháng cho một ứng dụng nhỏ.
Không thay đổi paywall. Không có onboarding mới. Không thử nghiệm giá. Anh chỉ đơn giản là bắt đầu trả lời câu hỏi mà Apple đã luôn đặt ra cho anh.
Đó chính là bản chất của vấn đề này. Công việc không hào nhoáng và nằm sâu trong code backend. Nhưng lợi ích xuất hiện rất nhanh, bởi vì những yêu cầu đó vốn dĩ đã được chấp thuận mặc định.
Bốn sự kiện, và cách xử lý từng loại
CONSUMPTION_REQUEST
Apple đang hỏi ý kiến, chứ không phải đưa ra quyết định. Hãy lấy dữ liệu sử dụng thực tế của khách hàng, kiểm tra xem họ đã đồng ý cho chia sẻ dữ liệu của mình hay chưa, và điền năm trường: sự đồng ý, trạng thái giao hàng, mẫu đã cung cấp, tỷ lệ tiêu thụ theo milliunit, và kết quả bạn mong muốn. Từ chối những trường hợp sản phẩm đã được sử dụng. Chấp thuận những trường hợp sai sót thực sự.
REFUND
Tiền đang được hoàn lại, và hai hành động riêng biệt cần thực hiện. Thu hồi quyền sử dụng (entitlement) kể từ ngày thu hồi. Ghi nhận khoản hoàn tiền vào kỳ mà giao dịch mua ban đầu diễn ra, không phải kỳ mà bạn nhận được thông báo. Cũng nên lưu lại lý do thu hồi, vì nó giúp phân biệt các khoản hoàn tiền do lỗi ứng dụng gây ra với những trường hợp nhiễu khác.
REFUND_DECLINED
Không cần làm gì ngoài việc ghi nhận lại. Phản hồi của bạn đã có tác dụng, hoặc lịch sử tài khoản đã có tác dụng.
REFUND_REVERSED
Apple đã hủy một khoản hoàn tiền sau khi có khiếu nại. Nếu bạn đã cắt quyền truy cập, hãy khôi phục lại. Đối với gói đăng ký, ngày gia hạn không thay đổi khi việc này xảy ra, và điều đó thường khiến nhiều người bất ngờ.
Có hai trường hợp ngoại lệ mà không ai lường trước. Việc hoàn tiền cho gói đăng ký cũng đi kèm DID_CHANGE_RENEWAL_STATUS với subtype AUTO_RENEW_DISABLED, nghĩa là chế độ gia hạn đã bị tắt sẵn. Và khi bật Family Sharing, một khoản hoàn tiền sẽ kích hoạt REVOKE cho mọi thành viên trong gia đình từng có quyền truy cập.
Cách xử lý yêu cầu hoàn tiền của Apple: Công việc trong 12 giờ
Khung thời gian này rất ngắn và không quan tâm bạn đang ở múi giờ nào. Để phản hồi đúng cách cần năm bước. Xác minh chữ ký JWS dựa trên chuỗi chứng chỉ (certificate chain) của Apple trước khi tin tưởng bất kỳ byte nào trong đó. Đối chiếu giao dịch với đúng người dùng thực. Tính toán mức tiêu thụ dựa trên dữ liệu sử dụng đã ghi nhận, không phải phỏng đoán. Tạo một JWT có thời hạn ngắn bằng In-App Purchase key. Gửi phản hồi đi.
Sự đồng ý (consent) là điều kiện tiên quyết cho toàn bộ quy trình này. Tài liệu Send Consumption Information của Apple nói thẳng: đừng phản hồi gì cả nếu khách hàng chưa đồng ý cho chia sẻ dữ liệu tiêu thụ của họ. Hãy đưa điều khoản này vào terms của bạn trước khi phát hành. Các gói đăng ký tự động gia hạn sẽ từ chối hoàn toàn tỷ lệ tiêu thụ, vì Apple tự tính giá trị này dựa trên thời gian đã trôi qua.
Sandbox chỉ cho bạn 5 phút thay vì 12 giờ. Hãy coi đó như một gợi ý. Đây là việc dành cho server, không phải con người.
Điều gì xảy ra sau khi có quyết định
Xử lý yêu cầu chỉ là một nửa công việc. Cách nhà phát triển xử lý hoàn tiền trên App Store phụ thuộc vào những gì diễn ra trong giờ tiếp theo, khi ba yếu tố sau cần được đồng bộ:
Entitlements (quyền sử dụng). Tắt quyền truy cập khi có REFUND, bật lại khi có REFUND_REVERSED. Nếu một người dùng có quyền Pro thông qua hai lần cấp quyền, hãy kiểm tra lần cấp quyền còn lại trước. Chúng tôi đã phân tích toàn bộ vấn đề này trong bài viết về thu hồi quyền truy cập sau khi hoàn tiền.
Bản ghi doanh thu. Các khoản hoàn tiền thường đến sau nhiều tuần. Hãy quy chúng về đúng nhóm (cohort) ban đầu, nếu không LTV của bạn chỉ là con số ảo và ngân sách quảng cáo của bạn cũng sẽ đi theo hướng sai lệch đó.
Báo cáo. Ghi lại những gì Apple đã hỏi, những gì bạn đã gửi, liệu nó có được chấp nhận hay không, và mất bao lâu. Việc gửi phản hồi và việc phản hồi đó được chấp nhận là hai chuyện hoàn toàn khác nhau. Chỉ điều thứ hai mới thực sự quan trọng.
Bỏ qua bất kỳ yếu tố nào trong số đó, và đó chính là cách các ứng dụng di động quản lý hoàn tiền App Store một cách tệ hại trong khi vẫn nghĩ rằng mình đang làm tốt.
Tự xây dựng, hay mua phần mềm quản lý hoàn tiền Apple cho nhà phát triển
Quản lý hoàn tiền Apple cho nhà phát triển cuối cùng chỉ xoay quanh một lựa chọn: khối lượng công việc, cộng với việc liệu có ai muốn sở hữu một hệ thống xử lý mà không bao giờ được phép ngừng hoạt động hay không.
Tự xây dựng có nghĩa là phải xác minh JWS, một In-App Purchase key mà bạn chỉ tải xuống được một lần, một hệ thống ánh xạ giao dịch với người dùng có thể tồn tại qua các lần thay đổi schema, và một lịch trực cho ca 3 giờ sáng thứ Bảy. Chỉ mất vài ngày để có một phiên bản đơn giản, nhưng mất nhiều tháng để nó thực sự đáng tin cậy.
Mua sẵn thì nhanh hơn. Các công cụ quản lý hoàn tiền App Store khác nhau ở ba điểm: chúng có tự động phản hồi trong khung thời gian quy định hay không, chúng có hỗ trợ Google Play hay không, và chúng có hiển thị số tiền bạn giữ lại được hay chỉ đơn thuần là một nhật ký sự kiện. Chúng tôi đã so sánh các giải pháp trong bài viết công cụ quản lý hoàn tiền Apple: cách chọn giải pháp phù hợp.
Nếu bạn không muốn cài đặt gì và không muốn viết thêm dòng code nào, Refund Sensor là một giải pháp quản lý hoàn tiền App Store hoạt động dựa trên các store key mà bạn đã có sẵn. Nó tự động phản hồi từng yêu cầu bằng bằng chứng giao dịch trong đúng khung thời gian quy định và theo dõi kết quả cho từng trường hợp. Chỉ mất năm phút để kết nối, không cần SDK, không cần nộp lại ứng dụng.
Nguồn tham khảo
Câu hỏi thường gặp
Truy cập reportaproblem.apple.com, đăng nhập bằng Apple ID đã dùng để mua, tìm giao dịch đó trong 90 ngày gần nhất, rồi chọn lý do. Apple cho biết khách hàng sẽ nhận được phản hồi trong vòng 48 giờ. Trong ứng dụng, refund request sheet của StoreKit cũng hiển thị cùng biểu mẫu đó.
Không. Apple là bên quyết định. Bạn có thể gửi bằng chứng tiêu thụ (consumption evidence) trong khi yêu cầu đang chờ xử lý và nêu ý kiến mong muốn của mình. Nhưng quyết định cuối cùng không thuộc về bạn.
Các giao dịch mua trong 90 ngày gần nhất sẽ hiển thị tại reportaproblem.apple.com. Điều khoản của Apple quy định mọi giao dịch đều là cuối cùng, vì vậy việc hoàn tiền là một ngoại lệ tùy theo quyết định của Apple.
Về cơ bản là bạn không thể, và đó là sự thật. Notifications cần có một endpoint. Nếu không có server, một dịch vụ được quản lý (managed service) đảm nhiệm endpoint đó là cách duy nhất để bạn phản hồi trong vòng 12 giờ.
Một In-App Purchase key, được tạo trong App Store Connect ở mục Users and Access, phần Integrations. Đây không phải là App Store Connect API key của bạn, và file .p8 chỉ có thể tải xuống đúng một lần duy nhất.
Có. Khoản hoàn tiền đi kèm DIDCHANGERENEWALSTATUS và AUTORENEW_DISABLED, vì vậy chế độ gia hạn đã bị tắt ngay khi tiền được hoàn lại.
Bất kỳ giải pháp nào có thể tự động phản hồi mọi yêu cầu và báo cáo số tiền bạn giữ lại được. Đối với một nhà phát triển độc lập, việc tự xây dựng bộ xử lý này là một dự án cuối tuần khá hợp lý, nhưng sau đó lại cần được giám sát mãi mãi. Khi vượt qua một khối lượng nhất định, một giải pháp quản lý hoàn tiền ứng dụng iOS sẽ hiệu quả hơn nhiều so với việc phân lịch trực.
