Apple quyết định có chấp nhận hoàn tiền hay không. Phần chính sách để lại cho bạn là mọi thứ diễn ra xung quanh quyết định đó, và đó chính là nơi phần lớn tổn thất có thể tránh được đang nằm.
Chúng tôi nghe một phiên bản của câu chuyện này rất thường xuyên. Một người dùng yêu cầu Apple hoàn tiền vào tháng 3. Apple đồng ý. Máy chủ của nhà phát triển không hề hay biết. Đến tháng 6, chính người dùng đó vẫn đang dùng phiên bản trả phí của ứng dụng. Không ai nhận ra cho đến khi bộ phận tài chính kiểm tra vào cuối quý, và ngay cả khi đó cũng mất một thời gian mới hiểu được chuyện gì đã xảy ra. Khoản hoàn tiền nằm trong báo cáo thanh toán. Bản ghi quyền truy cập nằm trong cơ sở dữ liệu riêng của ứng dụng. Hai bên không bao giờ nói chuyện với nhau.
Đó là cách phần lớn nhà phát triển biết đến chính sách hoàn tiền của App Store. Không phải qua việc đọc nó, mà qua việc phát hiện ra, nhiều tháng sau, những gì nó chưa bao giờ đề cập đến.
Đây là phần chính sách không nói rõ. Việc Apple đảo ngược một khoản thanh toán và việc ứng dụng của bạn thu hồi quyền truy cập là hai sự kiện khác nhau. Apple lo phần đầu. Bạn lo phần sau. Khoảng trống giữa hai việc đó là nơi nhà phát triển âm thầm mất tiền, tháng này qua tháng khác. Phần lớn bài viết này nói về cách khép lại khoảng trống đó.
Vì vậy bài viết này nhìn chính sách từ phía nhà phát triển: Apple kiểm soát những gì, phần nào thuộc về bạn, và hệ thống của bạn cần làm gì khi một khoản hoàn tiền được thực hiện. Nếu bạn muốn đọc phần thực hành hơn là bản thân chính sách, hướng dẫn của chúng tôi về quản lý hoàn tiền App Store mà không mất doanh thu ứng dụng di động sẽ đề cập đến điều đó.
Những điểm chính
● Apple đưa ra mọi quyết định hoàn tiền. Không có nút nào trong App Store Connect để chấp nhận hay từ chối hoàn tiền, vì lựa chọn đó chưa bao giờ thuộc về nhà phát triển.
● Nơi khách hàng sinh sống có thể thay đổi kết quả. Điều kiện đủ và quy trình khác nhau theo quốc gia hoặc khu vực, theo Điều khoản và Điều kiện Dịch vụ Truyền thông của Apple.
● Apple có thể gửi thông báo liên quan đến hoàn tiền tới máy chủ của bạn, và có thể yêu cầu thông tin về cách giao dịch mua đã được sử dụng trong lúc xem xét yêu cầu.
● Bạn có 12 giờ để phản hồi, và chỉ khi khách hàng đã cho phép chia sẻ thông tin đó.
● Khoản hoàn tiền Apple chấp nhận và khoản hoàn tiền cơ sở dữ liệu của bạn ghi nhận là hai sự kiện riêng biệt. Khoảng cách giữa chúng là nơi tiền bị thất thoát.
● Tự động hóa có thể giúp phần việc của bạn nhanh hơn và nhất quán hơn. Nó không ảnh hưởng gì đến quyết định của Apple.
Chính sách hoàn tiền App Store là gì?
Nói ngắn gọn, đó là bộ quy tắc về cách Apple xử lý yêu cầu hoàn tiền của khách hàng, cộng với danh sách các việc kỹ thuật thuộc về nhà phát triển.
Apple quyết định có chấp nhận hoàn tiền hay không. Bạn không có tiếng nói. Bạn không thể chấp nhận một yêu cầu, và cũng không thể chặn nó. App Store Connect không có màn hình nào để nhà phát triển bỏ phiếu về việc này. Nhiều nhất bạn có thể làm là gửi cho Apple một số thông tin ở vài thời điểm trong quy trình, và chúng ta sẽ nói đến ngay sau đây. Nếu bạn muốn xem khách hàng thực sự gửi yêu cầu như thế nào, điều đó được trình bày trong hướng dẫn yêu cầu hoàn tiền cho ứng dụng hoặc nội dung của Apple.
Chúng tôi thường chia chính sách thành bốn phần khi làm việc với các nhóm, vì chỉ hai trong bốn phần thực sự là vấn đề của bạn.
Phần thứ nhất là điều kiện đủ. Yêu cầu đi thẳng tới Apple, không bao giờ tới bạn. Điều kiện đủ có thể thay đổi tùy theo quốc gia hoặc khu vực của khách hàng, và các quy tắc nằm trong Điều khoản và Điều kiện Dịch vụ Truyền thông của Apple. Vì vậy nếu một người dùng hỏi tại sao họ được hoàn tiền còn bạn của họ thì không, không có câu trả lời đơn giản. Tất cả phụ thuộc vào nơi mỗi người sinh sống.
Phần thứ hai là bản thân quyết định. Đó hoàn toàn là việc của Apple. Bạn chỉ biết sau khi quyết định đã được đưa ra.
Phần thứ ba là trách nhiệm của bạn, và chúng mang tính kỹ thuật chứ không phải pháp lý, điều khiến nhiều người bất ngờ gần như mọi lần. Vận hành một máy chủ có thể nhận thông báo. Cung cấp thông tin khi Apple yêu cầu. Giữ hồ sơ sạch sẽ. Đó là toàn bộ công việc.
Phần thứ tư là chuyện gì xảy ra với quyền lợi (entitlement) sau quyết định, và đây là phần thực sự tốn tiền. Việc Apple đảo ngược một khoản thanh toán tự nó không thay đổi gì trong cơ sở dữ liệu của bạn. Một khách hàng được hoàn tiền nhưng vẫn giữ quyền truy cập trả phí mãi mãi không phải là lỗi của chính sách Apple. Đó là lỗ hổng trong cách hệ thống của bạn được xây dựng.
Bạn có thể đoán được phần nào quan trọng nhất với chúng tôi.
Quy trình hoàn tiền Apple App Store vận hành thế nào với nhà phát triển?
Khách hàng bắt đầu. Apple kết thúc. Bạn ở đâu đó giữa chừng.
Khách hàng yêu cầu hoàn tiền qua Apple
↓
Apple xem xét yêu cầu
↓
Máy chủ của bạn có thể nhận thông báo liên quan đến hoàn tiền
↓
Bạn cung cấp thông tin hỗ trợ, nếu áp dụng
↓
Apple đưa ra quyết định
↓
Bạn nhận kết quả dưới dạng thông báo
↓
Quyền lợi và quyền truy cập được cập nhật
Hai điều đáng chú ý ở đây. Apple cho khách hàng biết sẽ có câu trả lời trong khoảng 24 đến 48 giờ, và mốc thời gian đó không liên quan gì đến mốc của bạn, nên hãy cẩn thận với những gì đội hỗ trợ hứa hẹn khi yêu cầu còn đang chờ xử lý. Và mọi bước ở trên chỉ hoạt động nếu máy chủ của bạn thực sự được thiết lập và có thể truy cập được. Không ít nhóm phát hiện ra máy chủ của mình không như vậy. Nếu endpoint của bạn ngừng hoạt động, khoản hoàn tiền vẫn diễn ra. Chỉ là bạn không bao giờ biết.
Quy tắc hoàn tiền App Store có ý nghĩa gì với nhà phát triển?
Bỏ đi ngôn ngữ chính sách, các quy tắc trở thành một danh sách kiểm tra ngắn và khá khô khan cho đội kỹ thuật của bạn.
● Bản ghi giao dịch có thể thực sự tra cứu được. Thông báo hoàn tiền tham chiếu đến mã định danh giao dịch của Apple. Nếu bạn không lưu chúng tại thời điểm mua, thông báo gần như vô dụng. Bạn cũng cần một liên kết đáng tin cậy giữa mỗi giao dịch và một tài khoản người dùng, vì payload của Apple xác định giao dịch mua chứ không phải người thực hiện.
● Một endpoint nhận thông báo hoạt động tốt và kiểm tra chữ ký. Sự kiện hoàn tiền đến qua App Store Server Notifications, và các payload đều được ký. Hãy kiểm tra chữ ký mỗi lần. Một endpoint tin tưởng mọi thứ gửi đến là một rủi ro bảo mật có kèm URL.
● Một luồng lấy sự đồng ý, được thiết lập từ trước. Nếu Apple yêu cầu thông tin tiêu dùng, bạn chỉ được phép phản hồi khi khách hàng đã đồng ý chia sẻ dữ liệu đó. Trách nhiệm này thuộc về bạn. Tài liệu Send Consumption Information của Apple nói thẳng về điều này, và bất kỳ phản hồi nào gửi đi mà không có sự đồng ý sẽ bị từ chối. Bạn cũng không thể quay lại thu thập sự đồng ý sau khi yêu cầu đã đến. Hoặc bạn đã có nó tại thời điểm mua, hoặc bạn bỏ qua lần đó.
● Logic quyền lợi hoạt động theo cả hai chiều. Hoàn tiền đôi khi bị đảo ngược. Apple cũng cho phép hoàn tiền một phần, khi chỉ một phần giao dịch mua được trả lại. Toàn phần, một phần hay đảo ngược, mã của bạn cần xử lý cả ba.
● Một nơi lưu kết quả mà bộ phận tài chính thực sự dùng được. Khoản hoàn tiền chỉ tồn tại trong cơ sở dữ liệu của ứng dụng sẽ không bao giờ khớp với báo cáo thanh toán. Hầu hết các nhóm phát hiện điều này lúc chốt quý, và hiếm khi đó là một ngày vui.
Chính sách hoàn tiền của Apple ảnh hưởng đến nhà phát triển như thế nào?
Ai cũng tập trung vào số tiền được hoàn. Nó thường là con số nhỏ nhất trong câu chuyện.
Một kỳ đăng ký bị hoàn tiền lấy lại doanh thu bạn đã tính, và trong hầu hết trường hợp mối quan hệ cũng kết thúc ở đó. Các lần gia hạn bạn mong đợi âm thầm không còn xuất hiện. Giao dịch mua một lần đơn giản hơn, nhưng vẫn phát sinh sau khi bán, nên bất kỳ báo cáo nào dựa trên số liệu gộp sẽ phóng đại kết quả cho đến khi các khoản hoàn tiền được trừ đi.
Đây là điểm phân biệt đáng nhớ nhất trong toàn bộ bài viết này. Khoản hoàn tiền Apple chấp nhận và khoản hoàn tiền hệ thống của bạn thực sự ghi nhận là hai sự kiện riêng biệt. Nửa của Apple diễn ra theo lịch riêng của họ, dù có ai theo dõi hay không. Nửa của bạn chỉ diễn ra nếu trình xử lý thông báo được kích hoạt, giao dịch được khớp, tài khoản được tìm thấy, và quyền truy cập được cập nhật. Thiếu bất kỳ mắt xích nào thì công việc mới chỉ xong một nửa, và nhìn từ bên ngoài, không ai biết là nửa nào.
Khoảng trống đó có tên: rò rỉ hoàn tiền (refund leakage). Đây là những khách hàng đã nhận lại tiền nhưng vẫn giữ mọi thứ họ đã trả. Họ sẽ không báo cáo, vì theo những gì họ thấy thì chẳng có gì sai. Nó chỉ lộ ra nhiều tháng sau trong quá trình đối soát, nếu có lộ ra.
Mọi thứ khác đều bắt nguồn từ chính khoảng trống đó. Nhân viên hỗ trợ trả lời ticket mà không có bản ghi hoàn tiền nào để đối chiếu. Số liệu phân tích phóng đại giá trị vòng đời khách hàng vì các khoản đảo ngược chưa bao giờ vào số liệu. Không có lịch sử hoàn tiền để nhìn lại, nên không ai nhận ra khi một sản phẩm tạo ra nhiều yêu cầu hoàn tiền hơn hẳn phần còn lại.
Nhà phát triển nên làm gì khi có yêu cầu hoàn tiền từ Apple?
Bảy bước. Phần lớn công việc diễn ra từ rất lâu trước khi bất kỳ yêu cầu nào xuất hiện.
1. Nhận và kiểm tra thông báo
Sự kiện hoàn tiền đến endpoint của bạn dưới dạng payload JWS đã ký. Kiểm tra chữ ký đối chiếu với chuỗi chứng chỉ của Apple. Xác nhận bundle ID. Chỉ sau đó mới hành động dựa trên nội dung bên trong. Đây là vệ sinh cơ bản, vậy mà các nhóm vẫn bỏ qua. Một endpoint chấp nhận mọi thứ nó nhận được là endpoint mà người khác có thể lợi dụng.
2. Tìm giao dịch và tài khoản
Lấy mã định danh giao dịch từ payload và khớp với bản ghi mua hàng của bạn. Nếu bạn đã gắn một token tài khoản ổn định tại thời điểm mua, đây chỉ là một lần tra cứu. Nếu không, bạn đang đoán mò dưới áp lực thời gian.
3. Kiểm tra những gì bạn đã biết về giao dịch mua
Bạn không thể nói gì hữu ích với Apple cho đến khi biết hệ thống của mình đã ghi nhận gì. Nội dung đã được giao chưa? Nó có hoạt động như mong đợi không? Khách hàng thực sự đã dùng bao nhiêu? Nếu bạn không thể trả lời những câu này từ bản ghi của chính mình, đó là vấn đề thực sự đầu tiên của bạn, và nó không phải là khoản hoàn tiền.
4. Gửi thông tin tiêu dùng khi Apple yêu cầu và có sự đồng ý
Một thông báo CONSUMPTION_REQUEST từ Apple có nghĩa là bạn có thể phản hồi bằng thông tin về cách giao dịch mua đã được sử dụng, nhưng chỉ khi hai điều đúng: khách hàng đã đồng ý hợp lệ, và bạn vẫn còn trong khung 12 giờ Apple đặt ra. Tài liệu hiện tại của Apple gắn thông báo này với yêu cầu hoàn tiền cho mọi loại sản phẩm, vì vậy hãy xây dựng trình xử lý mà không giả định nó sẽ luôn xuất hiện. Bất cứ thứ gì bạn gửi nên lấy trực tiếp từ bản ghi của bạn, không phải ước đoán đại khái.
5. Theo dõi kết quả cuối cùng
Kết quả đến dưới dạng thông báo. REFUND nghĩa là được chấp nhận. REFUND_DECLINED nghĩa là bị từ chối. REFUND_REVERSED nghĩa là Apple đã đảo ngược một khoản hoàn tiền đã chấp nhận trước đó. Lưu cả ba kết quả. Trường hợp đảo ngược là trường hợp các nhóm hay quên nhất, và bỏ sót một lần đảo ngược có thể khóa một khách hàng trả tiền khỏi thứ họ sở hữu hợp pháp.
6. Cập nhật quyền lợi và quyền truy cập
Thu hồi quyền truy cập khi hoàn tiền được chấp nhận. Khôi phục nếu khoản hoàn tiền bị đảo ngược. Xử lý trường hợp một phần, khi chỉ một tỷ lệ được trả lại. Và chạy việc này dựa trên sự kiện phía máy chủ, để quyền truy cập của khách hàng luôn đúng dù họ có mở lại ứng dụng hay không.
7. Đối soát với báo cáo doanh thu và đăng ký
Khớp khoản hoàn tiền với đúng kỳ và đúng sản phẩm. Bỏ qua bước này, tài chính và kỹ thuật sẽ nhìn vào hai phiên bản khác nhau của cùng một tháng. Ai từng ngồi trong cuộc họp đó đều biết nó đáng để tránh.
Vì sao quản lý hoàn tiền App Store thủ công trở nên khó khăn
Đây không phải chuyện bất cẩn. Các ràng buộc đơn giản là không phù hợp với một quy trình phụ thuộc vào việc có ai đó thức và chú ý suốt ngày đêm.
Yêu cầu hoàn tiền xuất hiện bất cứ khi nào khách hàng gửi. Sáng Chủ nhật. Hai giờ sáng. Ngày lễ. Khung thời gian phản hồi không tạm dừng vì lịch của bất kỳ ai. Mỗi yêu cầu cần một lần tra cứu giao dịch, một lần khớp tài khoản, một lần kiểm tra sự đồng ý, một con số sử dụng, và một lần cập nhật quyền lợi. Ngày thuận lợi thì mất khoảng năm phút. Nhưng nó gấp về thời gian, lặp đi lặp lại, và hoàn toàn vô hình khi được làm đúng. Không ai được cảm ơn vì xử lý đúng một khoản hoàn tiền lúc 4 giờ sáng.
Khối lượng làm mọi thứ khó hơn. Vận hành nhiều hơn một ứng dụng cũng vậy, với dữ liệu giao dịch ở một hệ thống và dữ liệu tài khoản ở hệ thống khác. Rồi kỹ sư hiểu trình xử lý chuyển sang nhóm khác. Bảng tính theo dõi được đặt tên kiểu refunds_OLD_final_v2 và âm thầm không còn được mở nữa. Tài chính phát hiện lỗ hổng lúc chốt quý, khoảng ba tháng sau thời điểm ai đó còn có thể làm gì được.
Làm sao nhà phát triển quản lý hoàn tiền App Store đáng tin cậy hơn?
Giám sát thủ công trông đại khái thế này: ai đó mở dashboard, tra cứu một giao dịch, cập nhật một bản ghi, rồi chuyển sang việc khác. Nó hoạt động ổn ở khối lượng thấp, và đó chính là cái bẫy, vì nó không đổ vỡ ầm ĩ. Nó phai dần. Không có khoảnh khắc nào nó ngừng hoạt động, nên không ai kịp phát hiện.
Tự động hóa gỡ các bước máy móc khỏi tay con người: nhận và xác minh thông báo, khớp giao dịch với tài khoản, tổng hợp dữ liệu phản hồi, theo dõi khung thời gian phản hồi, ghi nhận kết quả, và giữ quyền lợi đồng bộ.
Điều nó không làm được là thay đổi quyết định của Apple. Tự động hóa không làm hoàn tiền ít xảy ra hơn, và không thể tác động đến quyết định, dù một số công cụ ngụ ý gì đi nữa. Tất cả những gì nó thay đổi là phần việc của bạn có diễn ra nhất quán và đúng hạn hay không, và riêng điều đó đã là một thứ đáng để sửa.
Quản lý hoàn tiền App Store là hạng mục mà công việc này thuộc về, và đáng nói thẳng một công cụ trong mảng này nên bao phủ những gì: xử lý thông báo, khớp giao dịch với người dùng, luồng phản hồi tôn trọng sự đồng ý và thời hạn, lịch sử hoàn tiền có thể tra cứu về sau, và cập nhật quyền lợi xử lý được hoàn tiền toàn phần, một phần và đảo ngược.
RefundSensor đảm nhận phần việc đó. Nó kết nối sự kiện hoàn tiền từ App Store và Google Play với một luồng công việc tự động, để phản hồi được gửi đi trong khung thời gian của cửa hàng mà không cần ai theo dõi thông báo thủ công, và bản ghi hoàn tiền luôn chính xác khi khối lượng tăng. Nó sẽ không thay đổi quyết định của Apple, vì không gì làm được điều đó. Nó thay đổi lượng công việc mỗi khoản hoàn tiền để lại cho nhóm của bạn sau đó.
Các quy tắc này được ghi ở đâu
Ba nguồn của Apple đứng sau mọi thứ ở trên. Hãy tự đọc trước khi xây dựng bất cứ thứ gì, và thỉnh thoảng kiểm tra lại, vì lĩnh vực này đã thay đổi hơn một lần.
Yêu cầu hoàn tiền cho ứng dụng hoặc nội dung — chính sách mà khách hàng nhìn thấy. Đề cập cách gửi yêu cầu, khung cập nhật 24 đến 48 giờ, và lưu ý của Apple về điều kiện theo khu vực.
Send Consumption Information — luồng phản hồi dành cho nhà phát triển. Đề cập yêu cầu về sự đồng ý, khung 12 giờ, và các trường trong yêu cầu. Đáng đọc trọn vẹn trước khi đụng vào xử lý thông tin tiêu dùng.
App Store Server Notifications — cách sự kiện hoàn tiền đến backend của bạn. Đề cập định dạng payload đã ký và các loại thông báo, gồm CONSUMPTION_REQUEST, REFUND, REFUND_DECLINED và REFUND_REVERSED.
Nếu sự kiện hoàn tiền vẫn đang được kiểm tra thủ công
Giám sát thủ công hoạt động ổn, cho đến khi nó không còn ổn nữa, và sự cố thường diễn ra âm thầm. Một thông báo không ai thấy. Một khung thời gian đóng lại lúc 3 giờ sáng. Một khách hàng được hoàn tiền vẫn giữ quyền truy cập suốt cả quý.
Nếu điều đó nghe quen, RefundSensor có thể đưa luồng hoàn tiền ra khỏi việc theo dõi thủ công: sự kiện từ cửa hàng, khung thời gian phản hồi, và đảm bảo kết quả đến được cả bản ghi lẫn logic quyền lợi của bạn.
Câu hỏi thường gặp
Đó là bộ quy tắc về cách Apple xử lý yêu cầu hoàn tiền của khách hàng, cùng với phần việc kỹ thuật xung quanh thuộc về nhà phát triển. Apple quyết định kết quả. Nhà phát triển lo phần hạ tầng xung quanh: nhận thông báo, gửi thông tin tiêu dùng khi được yêu cầu và khách hàng đã cho phép, rồi cập nhật quyền truy cập và bản ghi khi có quyết định.
Không, và không có cách nào để làm điều đó dù họ có muốn. Apple đưa ra quyết định cuối cùng cho từng yêu cầu. Endpoint thông tin tiêu dùng hiện tại cho phép bạn gợi ý kết quả mong muốn, nhưng đó chỉ là một trong nhiều dữ liệu đầu vào, không phải chỉ thị. Apple vẫn có thể quyết định khác.
Khách hàng gửi yêu cầu tới Apple. Apple xem xét và có thể liên hệ máy chủ của bạn để lấy thông tin tiêu dùng. Nếu có sự đồng ý, bạn phản hồi trong khung thời gian Apple đặt ra. Apple quyết định, gửi kết quả dưới dạng một thông báo riêng, và hệ thống của bạn điều chỉnh quyền lợi của khách hàng cùng bản ghi cho khớp với quyết định đó.
Có, nhưng chỉ theo một cách rất hạn chế. Khi thông báo CONSUMPTION_REQUEST đến, Apple muốn có thông tin về cách giao dịch mua đã được sử dụng. Phản hồi của bạn cần có sự đồng ý hợp lệ của khách hàng, cần chính xác, và cần được gửi trong khung thời gian của Apple. Nó cung cấp thông tin cho quá trình xem xét. Nó không quyết định kết quả.
Đó là một App Store Server Notification yêu cầu máy chủ của bạn cung cấp thông tin về một giao dịch mua trong lúc Apple xem xét yêu cầu hoàn tiền. Nó không phải bản thân khoản hoàn tiền, và cũng không phải quyết định. Bạn có 12 giờ để phản hồi, và chỉ khi khách hàng đã đồng ý chia sẻ dữ liệu đó.
Theo hai cách. Trực tiếp, kỳ bị hoàn tiền được đảo ngược. Gián tiếp, mối quan hệ thường kết thúc ở đó, nên các lần gia hạn bạn đang trông đợi không bao giờ xuất hiện. Báo cáo dựa trên gia hạn gộp sẽ phóng đại doanh thu cho đến khi trừ đi các khoản hoàn tiền, và giá trị vòng đời khách hàng mang theo cùng sai số đó.
Ba việc cần làm, rồi hai việc cần để ý. Ghi nhận kết quả gắn với giao dịch và khách hàng. Thu hồi quyền lợi tương ứng. Đưa khoản hoàn tiền vào báo cáo doanh thu đúng kỳ. Sau đó xử lý trường hợp hoàn tiền một phần, khi chỉ một phần giao dịch được trả lại, và giữ sẵn đường khôi phục, vì Apple có thể đảo ngược khoản hoàn tiền về sau.
Các phần máy móc thì có, hoàn toàn. Xác minh thông báo, khớp giao dịch với tài khoản, theo dõi khung thời gian phản hồi, cập nhật quyền lợi, lưu lịch sử hoàn tiền. Tất cả đều đủ dự đoán được để tự động hóa. Phần nên giữ lại cho con người là thiết kế luồng lấy sự đồng ý và thực sự đọc hiểu các mẫu hoàn tiền của bạn, vì chúng cho bạn biết điều gì đó thật về sản phẩm.
