Trả lời nhanh: Trước khi bạn gửi dữ liệu consumption cho Apple để phản hồi một CONSUMPTION_REQUEST, bạn phải có sự đồng ý hợp lệ từ khách hàng, và bạn phải đặt customerConsented thành true. Thông báo của Apple không cho bạn biết liệu sự đồng ý đó có tồn tại hay không, đây là chủ ý thiết kế: Apple kỳ vọng app của bạn, không phải server của bạn, thu thập điều đó. Và vì bạn là người chia sẻ dữ liệu mà bạn đã thu thập từ người dùng, trách nhiệm pháp lý đối với sự đồng ý đó hoàn toàn thuộc về bạn, không phải Apple. Làm sai điều này sẽ là vấn đề pháp lý về quyền riêng tư, không chỉ là một lệnh gọi API bị từ chối.
Lỗ hổng mà hầu hết lập trình viên bỏ sót
Các hướng dẫn về tự động hóa hoàn tiền rất thích nói về khung thời gian 12 giờ và các trường dữ liệu consumption. Hầu như không hướng dẫn nào dừng lại ở chi tiết duy nhất dễ khiến lập trình viên gặp rắc rối nhất: thông báo CONSUMPTION_REQUEST không chứa bất kỳ dấu hiệu nào về sự đồng ý.
Điều này khiến nhiều người bất ngờ. Bạn có thể nghĩ một cách hợp lý rằng nếu Apple đang yêu cầu bạn dữ liệu, thì Apple đã xử lý xong việc cho phép chia sẻ dữ liệu đó. Nhưng không phải vậy. Quan điểm của Apple hoàn toàn ngược lại: dữ liệu bạn sẽ gửi là dữ liệu bạn đã thu thập từ người dùng của bạn, vì vậy trách nhiệm có được quyền chia sẻ nó thuộc về bạn. Apple chỉ đơn giản yêu cầu bạn xác nhận điều đó bằng cách đặt customerConsented thành true, và từ chối việc gửi dữ liệu nếu bạn không làm vậy. Đây chính là cốt lõi của các yêu cầu về sự đồng ý trong Apple Consumption API.
Vì vậy, trường này không phải là một ô checkbox bạn bật lên chỉ để API chấp nhận. Đó là một sự xác nhận pháp lý. Đặt nó thành true khi bạn chưa thực sự thu được sự đồng ý không phải là một lỗi kỹ thuật nhỏ, đó là một lỗi tuân thủ đang chờ bị phát hiện.
Vì sao sự đồng ý là trách nhiệm của lập trình viên
Hãy nghĩ về việc ai nắm giữ cái gì. Apple vận hành cửa hàng và đưa ra quyết định hoàn tiền. Nhưng thời gian sử dụng tài khoản, thời gian chơi, trạng thái giao hàng và lịch sử sử dụng mà bạn đưa vào một ConsumptionRequest đều là hồ sơ của bạn về người dùng của bạn, được thu thập theo chính sách quyền riêng tư của bạn. Khi bạn gửi chúng cho Apple, bạn đang tiết lộ dữ liệu cá nhân cho một bên thứ ba.
Theo các khung pháp lý về quyền riêng tư hiện hành, việc tiết lộ này cần có một cơ sở pháp lý phù hợp. Tài liệu API cụ thể của Apple yêu cầu phải có sự đồng ý hợp lệ trước khi chia sẻ dữ liệu cá nhân qua Consumption Information API, trong khi các yêu cầu pháp lý chính xác lại phụ thuộc vào khu vực pháp lý của người dùng. Apple nói rằng lập trình viên chịu trách nhiệm xác định sự tuân thủ với các luật áp dụng.
Đó là lý do gánh nặng này đổ lên lập trình viên, và vì sao câu "Apple yêu cầu điều đó" không phải là lời bào chữa nếu một cơ quan quản lý hỏi bạn đã có quyền gì để chia sẻ dữ liệu của người dùng. Đối với một quy trình đồng ý hoàn tiền của Apple (apple refund consent), điều quan trọng là sự đồng ý phải tồn tại trước khi dữ liệu được chia sẻ.
Nơi sự đồng ý phải được thu thập
Đây là phần quan trọng trên thực tế: sự đồng ý phải được thu thập trong app của bạn, trước khi quy trình hoàn tiền diễn ra, không phải suy luận tại server khi thông báo đến.
Vào thời điểm một CONSUMPTION_REQUEST đến server của bạn, đã quá muộn để hỏi. Không có người dùng hiện diện, và chỉ còn khoảng 12 giờ để xử lý. Sự đồng ý phải đã tồn tại từ trước, được thu thập sớm hơn như một phần trong cách app của bạn tiếp nhận người dùng mới và công bố các thực hành về dữ liệu, để khi yêu cầu đến, bạn có thể trung thực đặt customerConsented thành true.
Trong thực tế, điều này có nghĩa là các điều khoản, chính sách quyền riêng tư, và quy trình mua hàng hoặc tiếp nhận người dùng mới của app bạn cần công bố rõ ràng rằng dữ liệu consumption có thể được chia sẻ với Apple để xử lý các yêu cầu hoàn tiền, và thu được sự đồng ý theo cách bạn có thể bảo vệ được. Sự đồng ý mập mờ, bị gộp chung, hoặc bị ẩn giấu chính là điều mà luật quyền riêng tư hiện đại được thiết kế để loại bỏ. Đây cũng là yếu tố trung tâm của quyền riêng tư trong hoàn tiền Apple (apple refund privacy) vì Apple cụ thể yêu cầu sự đồng ý hợp lệ trước khi dữ liệu consumption được chia sẻ.
Điều này liên quan đến GDPR và DPDP như thế nào
Nếu bất kỳ người dùng nào của bạn ở EU/UK (GDPR), Ấn Độ (DPDP), California (CCPA), hoặc trong danh sách ngày càng dài các khu vực pháp lý khác, việc chia sẻ dữ liệu consumption sẽ nằm trực tiếp trong các khung pháp lý đó. Một vài nguyên tắc luôn được áp dụng:
Sự đồng ý phải được thông báo rõ ràng và cụ thể. Người dùng nên hiểu rằng dữ liệu liên quan đến hoàn tiền có thể được chia sẻ với Apple, không chỉ đơn thuần đồng ý với một đoạn văn bản pháp lý dài dòng.
Sự đồng ý nên có thể tách biệt. Việc gộp sự đồng ý chia sẻ dữ liệu với các điều khoản không liên quan vào một ô checkbox bắt buộc duy nhất là một cách làm sai đã được công nhận rộng rãi.
Bạn phải có thể chứng minh được điều đó. Nếu bị thách thức, câu "chúng tôi đã có sự đồng ý" cần phải chứng minh được, nghĩa là việc thu thập sự đồng ý của bạn phải được ghi lại, không chỉ là giả định.
Chính sách quyền riêng tư của bạn phải thực sự nêu rõ điều đó. Nếu chính sách của bạn không công bố việc chia sẻ dữ liệu consumption với Apple cho mục đích hoàn tiền, sự đồng ý của bạn cho việc này sẽ đứng trên nền tảng không vững chắc.
Đối với các nhóm đang xem xét các yêu cầu về dữ liệu consumption theo GDPR (gdpr consumption data), điều quan trọng là chính Apple yêu cầu sự đồng ý hợp lệ cho API này, trong khi các yêu cầu pháp lý chính xác và cơ sở pháp lý có thể khác nhau theo khu vực pháp lý. Hướng dẫn của Apple nói rằng sự đồng ý phải được đưa ra một cách tự nguyện, cụ thể, được thông báo rõ ràng và không mơ hồ, và lập trình viên chịu trách nhiệm xác định sự tuân thủ theo luật áp dụng.
Đối với các app tập trung vào Ấn Độ, sự đồng ý hoàn tiền theo DPDP (dpdp app refund) cũng nên được xem xét dựa trên các yêu cầu áp dụng, thay vì cho rằng chỉ riêng yêu cầu API của Apple đã giải quyết được toàn bộ các nghĩa vụ về quyền riêng tư.
Đây không phải là lời khuyên pháp lý, và các chi tiết cụ thể về nghĩa vụ của bạn phụ thuộc vào người dùng và khu vực pháp lý của bạn, nhưng định hướng chung thì rõ ràng: sự đồng ý đằng sau trường customerConsented đó phải là thật, được thông báo rõ ràng, và được ghi lại.
Một thiết lập tuân thủ sẽ trông như thế nào
Tổng hợp lại, một thiết lập có thể bảo vệ được gồm ba phần hoạt động trước khi có bất kỳ giao dịch hoàn tiền nào:
Công bố (Disclosure): chính sách quyền riêng tư và điều khoản của bạn nêu rõ rằng dữ liệu consumption/usage có thể được chia sẻ với Apple để xử lý các yêu cầu hoàn tiền.
Thu thập (Capture): app của bạn thu được sự đồng ý được thông báo rõ ràng, có thể tách biệt từ người dùng, và ghi lại sự đồng ý đó.
Xác nhận (Attestation): khi một CONSUMPTION_REQUEST đến, phản hồi của bạn phản ánh trung thực sự đồng ý đã ghi lại đó trong customerConsented.
RefundSensor được xây dựng với chuỗi quy trình này trong đầu. Nền tảng xử lý phản hồi hoàn tiền và việc xác nhận customerConsented như một phần của quy trình tự động, và chúng tôi đã công bố một bộ tài liệu tuân thủ đầy đủ, chính sách quyền riêng tư, điều khoản, DPA, chính sách cookie và chính sách hoàn tiền phù hợp với GDPR, DPDP và CCPA, nhờ đó phần công bố và xử lý được đảm bảo thay vì làm tạm bợ. Việc thu thập sự đồng ý trong app của bạn vẫn là quyết định của riêng bạn, như nó phải vậy, nhưng mọi thứ ở các bước sau đó đều được xử lý.
Đối với các nhóm đang đánh giá phần mềm tuân thủ hoàn tiền (refund compliance software) hoặc một công cụ tự động hóa hoàn tiền Apple (Apple refund automation tool), sự phân tách này rất quan trọng: tự động hóa có thể xử lý phản hồi kỹ thuật, nhưng không nên tự tạo ra hoặc giả định sự đồng ý của khách hàng.
Những lỗi phổ biến nhất
Đặt customerConsented thành true theo mặc định. Cách nhanh nhất để biến một tính năng hoàn tiền thành một rủi ro về tuân thủ.
Cho rằng Apple xử lý sự đồng ý. Không phải vậy, và Apple cũng đã nói rõ điều này.
Cố gắng thu thập sự đồng ý vào thời điểm hoàn tiền. Không có người dùng và không có khung thời gian cho việc đó, sự đồng ý phải tồn tại từ trước.
Không công bố gì trong chính sách quyền riêng tư. Nếu chính sách không đề cập đến việc chia sẻ dữ liệu với Apple, sự đồng ý đằng sau đó rất khó bảo vệ.
Gộp chung vào một ô checkbox bắt buộc duy nhất. Sự đồng ý có thể tách biệt là chuẩn mực; việc gộp chung sẽ làm suy yếu điều đó.
Sử dụng App Tracking Transparency làm cơ chế đồng ý. Tài liệu của Apple nói rõ rằng sự đồng ý cần thiết cho Consumption Information API là tách biệt với App Tracking Transparency.
Nguồn chính thức
Cả yêu cầu và quy định đều có thể thay đổi, vì vậy hãy xem các nguồn sau là tài liệu tham khảo chính thức cuối cùng:
Tự động hóa hoàn tiền tôn trọng chuỗi đồng ý. RefundSensor xử lý phản hồi hoàn tiền và việc xác nhận customerConsented như một phần của quy trình tự động, được hỗ trợ bởi một bộ tài liệu tuân thủ đầy đủ phù hợp với GDPR/DPDP/CCPA. Đối với các nhóm đang tìm kiếm giải pháp tự động hóa hoàn tiền app (app refund automation), chuỗi đồng ý vẫn là một phần của việc triển khai. Bắt đầu miễn phí
Câu hỏi thường gặp
Có. Bạn phải có sự đồng ý hợp lệ, được thông báo rõ ràng, và đặt customerConsented thành true. Apple yêu cầu sự xác nhận này và từ chối các phản hồi không có nó, và bạn chịu trách nhiệm pháp lý về việc đã thu được sự đồng ý đó.
Trong app của bạn, trước khi diễn ra quy trình hoàn tiền. Khi một CONSUMPTION_REQUEST đến server của bạn, không có người dùng nào hiện diện và chỉ còn khoảng 12 giờ để xử lý, vì vậy sự đồng ý phải đã tồn tại từ trước và được ghi lại.
Không. Thông báo này không mang bất kỳ dấu hiệu nào về sự đồng ý. Apple kỳ vọng app của bạn đã thu thập sự đồng ý đó, và kỳ vọng bạn xác nhận điều này trong phản hồi của mình.
Có thể, nếu chuỗi đồng ý được thực hiện đúng cách: công bố rõ ràng trong chính sách của bạn, sự đồng ý được thông báo đầy đủ và có thể tách biệt được thu thập trong app và ghi lại, cùng với sự xác nhận trung thực trong phản hồi API. Việc tự động hóa xử lý phần phản hồi; việc thu thập sự đồng ý trong app vẫn là trách nhiệm của bạn.
Apple sẽ không xử lý dữ liệu consumption, vì vậy bạn sẽ mất cơ hội cung cấp thông tin cho quyết định hoàn tiền đó. Hướng đi đúng là thu được sự đồng ý thực sự từ trước, thay vì gửi dữ liệu mà không có nó.
