Hầu hết các hướng dẫn về cách xử lý yêu cầu hoàn tiền đều bắt đầu từ thời điểm nhận thông báo. Apple gửi thông báo cho bạn, Google gửi thông báo cho bạn, và đây là những gì cần gửi lại. Điều đó cũng hợp lý, nhưng khi thông báo đến nơi thì phần việc quan trọng đã hoàn thành hoặc đã bị bỏ lỡ từ trước, bởi những gì bạn có thể nói về một giao dịch mua phụ thuộc vào những gì bạn đã ghi lại ngay từ lúc nó diễn ra.
Vì vậy, bài viết này sẽ bắt đầu sớm hơn, ngay từ bước thanh toán. Dữ liệu mua hàng nào thực sự quan trọng khi có yêu cầu hoàn tiền, nên lưu trữ chúng ở đâu, và làm thế nào để biến chúng thành một câu trả lời mà cửa hàng sẽ thực sự cân nhắc. Nếu bạn chưa từng gắn một định danh vào giao dịch mua, hãy đọc bài viết của chúng tôi về appAccountToken và bảo vệ trước yêu cầu hoàn tiền trước, vì mọi nội dung bên dưới đều giả định rằng bạn có thể liên kết một mã giao dịch (transaction ID) với một người dùng cụ thể.
Những điểm chính
Cả Apple và Google đều tự quyết định việc hoàn tiền, và cả hai hiện đều yêu cầu bạn cung cấp dữ liệu mua hàng trước. Apple cho bạn 12 giờ, Google cho bạn 24 giờ.
Các cửa hàng muốn những thông tin tổng quát, không phải nhật ký chi tiết: sản phẩm đã được giao chưa, đã sử dụng bao nhiêu, khách hàng có nhận được bản dùng thử không, và bạn ưu tiên phương án nào.
Bạn cần lưu trữ bốn thông tin cho mỗi giao dịch mua: ai đã mua, khi nào được giao, khi nào được sử dụng, và liệu tài khoản này đã từng được hoàn tiền trước đó hay chưa.
Apple cho biết hầu hết các yêu cầu hoàn tiền đến trong vòng 30 ngày kể từ khi mua. Hãy lưu trữ dữ liệu ít nhất trong khoảng thời gian đó, thực tế nên là 90 ngày.
Các ứng dụng bắt đầu phản hồi yêu cầu hoàn tiền thường thấy tỷ lệ hoàn tiền giảm khoảng một phần ba, nhưng chỉ khi có dữ liệu thực sự để trình bày.
Các cửa hàng thực sự yêu cầu gì ở bạn
Yêu cầu của Apple khá đơn giản. Khi khách hàng yêu cầu hoàn tiền cho một giao dịch mua trong ứng dụng, bạn sẽ nhận được một CONSUMPTION_REQUEST, và bạn phản hồi thông qua endpoint Send Consumption Information với năm trường dữ liệu: khách hàng có đồng ý cho bạn chia sẻ dữ liệu hay không, giao dịch mua đã được giao chưa, phần trăm đã tiêu thụ là bao nhiêu (tính theo milliunit, vậy nên 100,000 nghĩa là toàn bộ), khách hàng có từng nhận bản dùng thử hoặc dùng thử miễn phí trước đó hay không, và mức ưu tiên hoàn tiền của bạn. Trước đây Apple từng yêu cầu khoảng một tá trường dữ liệu và đã loại bỏ phần lớn trong số đó, điều mà tôi cho rằng là do Apple cho rằng họ đã nắm rõ lịch sử của khách hàng hơn cả bạn.
Phiên bản của Google dành cho các trường hợp chargeback, và có phần chi tiết hơn. Một thông báo xem xét hoàn tiền đang chờ xử lý sẽ đến thông qua Real-time Developer Notifications kèm theo một token. Bạn gửi yêu cầu đến orders.reviewrefund với token đó, cùng cờ đánh dấu nội dung dùng thử tương tự, một mức ưu tiên là DECLINE, APPROVE hoặc NEUTRAL, phần trăm tiêu thụ (không bắt buộc), và tối đa 1,000 sự kiện sử dụng kèm dấu thời gian. Điều này càng trở nên quan trọng hơn khi Google bắt đầu tính phí nhà phát triển cho các chargeback trên những đơn hàng sau ngày 3 tháng 8 năm 2026.
Không cửa hàng nào muốn bạn xuất dữ liệu phân tích (analytics). Họ muốn biết về việc giao hàng, mức tiêu thụ, việc dùng thử và mức ưu tiên của bạn, còn mọi thứ khác mà bạn lưu trữ chỉ nhằm mục đích điền các thông tin đó một cách trung thực và nhanh chóng.
Lịch sử mua hàng phục vụ hoàn tiền: nên lưu gì và lưu trong bao lâu
Mức tối thiểu cần có:
Một định danh tại bước thanh toán. appAccountToken trên Apple, obfuscatedAccountId trên Google. Nếu không có nó, một yêu cầu hoàn tiền sẽ chỉ nêu tên giao dịch mà bạn không thể biết đó là của ai. Các kỹ sư của Apple cũng khuyên nên lưu ít nhất một originalTransactionId cho mỗi người dùng, vì chỉ cần có một trong số đó, bạn có thể gọi Get Transaction History để lấy toàn bộ lịch sử mua hàng của khách hàng đó trong ứng dụng, bất kể họ còn cài đặt ứng dụng hay không.
Một bản ghi giao hàng. Thời điểm bạn cấp xu hoặc mở khóa cấp độ, kèm dấu thời gian và kết quả. Nếu việc giao hàng thất bại, hãy ghi nhận rõ điều đó. Đây là trường hợp duy nhất mà bạn nên muốn yêu cầu hoàn tiền được chấp thuận, và việc khẳng định ngược lại sẽ làm mất đi uy tín mà bạn sẽ cần đến sau này.
Các sự kiện tiêu thụ. Không cần mọi lượt chạm, chỉ cần những sự kiện cho thấy giao dịch mua đã được sử dụng: xu đã tiêu, chương đã mở, bản xuất đã chạy. Google chấp nhận tối đa một nghìn sự kiện. Apple chỉ cần một con số phần trăm, nhưng bạn không thể tính ra con số đó nếu chưa từng ghi lại dữ liệu.
Một cờ đánh dấu bản dùng thử cho mỗi sản phẩm. Khách hàng này đã từng dùng thử, xem trước, hay dùng gói miễn phí chưa? Chỉ cần có hoặc không trên cả hai cửa hàng, vậy mà mọi người vẫn liên tục quên mất điều này.
Lịch sử hoàn tiền trước đó của tài khoản. Dù sao Apple cũng tự cân nhắc lịch sử hoàn tiền, nhưng bạn vẫn sẽ cần dữ liệu này cho các quy tắc riêng của mình.
Về thời gian lưu trữ, Apple cho biết hầu hết các yêu cầu hoàn tiền đến trong vòng 30 ngày và khuyên nên lưu dữ liệu tiêu thụ tương ứng với khoảng thời gian đó. Chúng tôi lưu trong 90 ngày, một phần vì các chargeback của Google có thể đến trễ hơn nhiều, và một phần vì lưu trữ dữ liệu thì rẻ, còn tranh luận dựa trên trí nhớ thì không.
Lịch sử mua hàng giúp ích gì cho việc hoàn tiền
Khi đã có đầy đủ dữ liệu đó, việc xử lý yêu cầu không còn là phán đoán chủ quan mà trở thành một thao tác tra cứu.
Đã giao, đã tiêu thụ hoàn toàn, không có bản dùng thử, chưa từng được hoàn tiền trước đó: đây là trường hợp phù hợp để chọn DECLINE. Đã giao, gần như chưa sử dụng, yêu cầu trong vòng một ngày: GRANT_FULL tốn kém không đáng kể và việc từ chối sẽ trông thật nhỏ nhặt. Giao hàng thất bại do lỗi từ phía bạn: hãy chấp thuận hoàn tiền và sửa lỗi. Sử dụng một phần trong vài tuần: Apple có GRANT_PRORATED cho trường hợp này, còn trên Google thì phần trăm tiêu thụ đảm nhận vai trò tương tự.
Những con số chứng minh điều đó. Dipsea, một ứng dụng âm thanh dạng thuê bao, bắt đầu phản hồi các yêu cầu của Apple từ cuối năm 2024, và tỷ lệ hoàn tiền của họ giảm từ 3% xuống còn 1.9% chỉ trong khoảng hai tuần. Về chargeback, Appcharge chia sẻ với PocketGamer rằng các tranh chấp không có bằng chứng hỗ trợ chỉ thắng 20 đến 30% số lần, trong khi những tranh chấp có bằng chứng thắng hơn 80%. Trên hơn 800 ứng dụng sử dụng Refund Sensor, 77% các yêu cầu đủ điều kiện đã được bảo vệ thành công, và những trường hợp chúng tôi thua phần lớn là do không có dữ liệu nào được ghi lại.
Điều mà lịch sử mua hàng không làm được là giúp bạn thắng những tranh chấp mà lẽ ra bạn không nên thắng. Nếu dữ liệu cho thấy khách hàng chỉ mở ứng dụng đúng một lần, câu trả lời trung thực chính là chấp thuận hoàn tiền.
Cách xử lý yêu cầu hoàn tiền trong thời hạn quy định
Quy trình xử lý yêu cầu hoàn tiền trên cả hai cửa hàng đều bị giới hạn về thời gian, vì vậy đây là việc xây dựng hệ thống nhiều hơn là phán đoán. Thông báo sẽ đến một endpoint mà bạn đã đăng ký. Bạn xác minh chữ ký, lấy mã giao dịch, tra cứu các bản ghi giao hàng và tiêu thụ của người dùng, tính toán phần trăm, chọn mức ưu tiên theo quy tắc bạn đã đặt ra từ trước, rồi gửi phản hồi. Ghi lại những gì bạn đã gửi và thời điểm gửi, sau đó chờ kết quả, trên Apple là thông báo REFUND hoặc REFUND_DECLINED. Khi nhận được REFUND, hãy thu hồi quyền truy cập ngay trong giờ đó, vì khách hàng đã được hoàn tiền nhưng vẫn giữ nội dung thường có xu hướng tiếp tục lạm dụng việc này.
Có hai điều khiến nhiều người gặp khó khăn. Thứ nhất là sự đồng ý: Apple sẽ không chấp nhận hồ sơ gửi lên trừ khi customerConsented là true, vì vậy quyền chia sẻ dữ liệu sử dụng cần được nêu trong điều khoản của bạn trước khi có yêu cầu đầu tiên. Thứ hai là thời gian: đồng hồ đếm ngược không dừng lại vào cuối tuần, và một tỷ lệ đáng ngạc nhiên các yêu cầu đến vào ban đêm. Quản lý yêu cầu hoàn tiền phần lớn là việc đảm bảo luôn có người hoặc hệ thống sẵn sàng xử lý. Hướng dẫn quản lý yêu cầu hoàn tiền của Apple của chúng tôi sẽ đi sâu hơn vào khía cạnh vận hành.
Phần mềm xử lý hoàn tiền cho nhà phát triển, hay tự viết code
Nếu có đội ngũ backend, quy trình nêu trên chỉ mất khoảng một tuần để xây dựng, nhưng sau đó trở thành một nhiệm vụ liên tục, và chính nhiệm vụ đó mới là phần tốn kém.
Nếu bạn đang dùng RevenueCat hoặc Adapty, cả hai đều tự động phản hồi các yêu cầu tiêu thụ của Apple dựa trên dữ liệu sử dụng mà SDK của họ đã thu thập sẵn, và Adapty còn hỗ trợ cả việc xem xét của Google. Đây là lựa chọn mặc định hợp lý nếu SDK đã có sẵn trong ứng dụng của bạn.
Refund Sensor làm điều tương tự mà không cần SDK. Bạn chỉ cần kết nối một API key của App Store Connect và một URL thông báo, sau đó nó sẽ nhận các yêu cầu, gửi phản hồi trong thời hạn cho phép, và lưu lại dòng thời gian cho từng trường hợp. Việc thiết lập chỉ mất vài phút và mức giá là cố định. Xem chi tiết tại trang web của Refund Sensor.
Dù bạn chọn giải pháp nào, kể cả không chọn giải pháp nào, lớp dữ liệu vẫn là của bạn. Không một phần mềm xử lý hoàn tiền nào dành cho nhà phát triển có thể tự tạo ra một bản ghi giao hàng mà bạn chưa từng lưu lại.
Kết luận
Việc bảo vệ trước yêu cầu hoàn tiền thường được nói đến như một vấn đề về phản hồi, nhưng thực chất nó là hệ quả của một vấn đề về việc ghi nhận dữ liệu. Các cửa hàng chỉ hỏi bốn câu hỏi cụ thể, và việc bạn có trả lời được hay không phụ thuộc vào những quyết định bạn đã đưa ra tại bước thanh toán và giao hàng, từ rất lâu trước khi ai đó muốn lấy lại tiền.
Hãy gắn một định danh, ghi lại việc giao hàng và tiêu thụ kèm dấu thời gian, đánh dấu các bản dùng thử, và lưu trữ tất cả trong 90 ngày. Khi đã có đầy đủ những điều đó, cách xử lý yêu cầu hoàn tiền chỉ còn là một quy tắc và một cron job, và tỷ lệ hoàn tiền thường sẽ tự được cải thiện.
Câu hỏi thường gặp
Apple cho bạn 12 giờ kể từ khi nhận CONSUMPTION_REQUEST. Google cho bạn 24 giờ kể từ thông báo xem xét hoàn tiền đang chờ xử lý đối với trường hợp chargeback. Nếu bạn bỏ lỡ thời hạn, cả hai sẽ tự quyết định mà không cần đến bạn.
Năm trường dữ liệu: sự đồng ý của khách hàng, trạng thái giao hàng, phần trăm tiêu thụ tính theo milliunit, việc có cung cấp bản dùng thử hay không, và mức ưu tiên hoàn tiền của bạn. Các trường cũ như thời gian sử dụng tài khoản và tổng chi tiêu trọn đời đã không còn nữa.
Phần lớn là giống, cộng thêm chi tiết hơn nếu bạn có. Google nhận phần trăm tiêu thụ và tối đa 1,000 sự kiện sử dụng kèm dấu thời gian, với các tùy chọn ưu tiên là DECLINE, APPROVE hoặc NEUTRAL.
Trên Apple thì có. Hồ sơ gửi lên sẽ bị từ chối trừ khi customerConsented là true, vì vậy quyền này cần được nêu trong điều khoản của bạn trước khi yêu cầu hoàn tiền xuất hiện.
Không. Cả hai cửa hàng đều coi mức ưu tiên của bạn chỉ là một yếu tố đầu vào, và cả hai đều thấy được toàn bộ lịch sử của khách hàng. Việc từ chối khi chính dữ liệu của bạn cho thấy giao hàng thất bại hoặc mức sử dụng gần như bằng 0 sẽ khiến bạn mất uy tín ở những trường hợp thực sự quan trọng.
