Gắn thẻ mọi giao dịch mua Google Play bằng một obfuscated account id, nếu không một khoản bồi hoàn sẽ đến mà không có cách nào để truy vết

Một phiên xem xét bồi hoàn của Google Play xuất hiện với việc nêu tên một đơn hàng và một token mua. Nó không cho bạn biết khách hàng là ai. Nếu bạn chưa bao giờ đóng dấu định danh của riêng mình lên giao dịch mua đó, giờ đây bạn phải khớp một id đơn hàng trần trụi với bảng người dùng của mình dưới một chiếc đồng hồ 24 giờ, và bạn phải trả lời bằng bằng chứng tiêu thụ mà bạn có thể không tìm ra. Obfuscated account id là giải pháp. Nó là một chuỗi ngắn bạn gắn vào lúc thanh toán mà Google Play lưu cùng với giao dịch mua và trao lại cho bạn sau đó, nên mọi đơn hàng có thể được truy về đúng người dùng đã thực hiện nó. Đây là trường đó là gì, tại sao nó quyết định liệu bạn có thể trả lời một tranh chấp hay không, và việc bỏ qua nó tốn kém thế nào giờ đây khi một khoản bồi hoàn thua là một hóa đơn.

Obfuscated account id thực chất là gì

Obfuscated account id là một chuỗi tùy chọn duy nhất bạn truyền vào luồng thanh toán của Google Play khi một khách hàng mua thứ gì đó. Bạn đặt nó bằng setObfuscatedAccountId trên builder BillingFlowParams, và Google lưu nó bên cạnh giao dịch mua. Nó không phải tên khách hàng, không phải email của họ, và không phải tài khoản Google của họ. Nó là định danh của riêng bạn cho người dùng của riêng bạn, được viết dưới một hình thức mà Google có thể lưu giữ mà không biết người đó là ai.

Nó là một chuỗi bạn đặt lúc thanh toán, không phải một cái tên

Theo lời Google, setObfuscatedAccountId chỉ định một chuỗi obfuscated tùy chọn được liên kết duy nhất với tài khoản người dùng của người mua trong ứng dụng của bạn. Từ obfuscated đang làm một công việc thực sự. Google không muốn id người dùng thô của bạn hay bất cứ thứ gì nhận diện con người. Nó muốn một token ổn định ánh xạ một đối một tới một người dùng ở phía bạn, và không gì hơn. Trường này giới hạn ở 64 ký tự, đủ thoải mái cho một hàm băm và không nhiều hơn.

Google đọc nó trước tiên cho việc sàng lọc gian lận của chính mình

Trước khi hữu ích cho bạn, trường này làm một việc cho Google. Tài liệu thanh toán nói rằng Google Play có thể dùng giá trị này để phát hiện hoạt động bất thường, chẳng hạn nhiều thiết bị thực hiện mua hàng trên cùng một tài khoản trong một khoảng thời gian ngắn, và rằng Google dùng dữ liệu này để phát hiện hành vi đáng ngờ và chặn một số loại giao dịch gian lận trước khi chúng hoàn tất. Vậy nên lợi ích đầu tiên của việc đặt nó nằm ở thượng nguồn, trong những giao dịch mua sạch hơn và ít hơn những giao dịch gian lận về sau biến thành hủy và tranh chấp. Google liệt kê obfuscated account id và Voided Purchases API cùng nhau như hai công cụ chống lạm dụng cốt lõi của mình là có lý do.

Tại sao nó quan trọng khi một phiên xem xét bồi hoàn xuất hiện

Một khoản hoàn tiền bạn thấy trước được thì dễ. Trường hợp khó là khoản bồi hoàn ngân hàng, vì nó không bắt đầu bằng việc khách hàng của bạn nói chuyện với bạn. Nó bắt đầu từ ngân hàng, và Google Play chuyển tiếp nó tới bạn như một phiên xem xét có gắn kèm một chiếc đồng hồ.

Tranh chấp nêu tên một đơn hàng, không phải một con người

Khi một khách hàng tranh chấp một khoản tính phí với ngân hàng của họ và Google cần ý kiến của bạn, Google Play gửi một PendingRefundReviewNotification. Thông điệp đó nhận diện đơn hàng. Nó không mang id người dùng của bạn, vì Google chưa bao giờ có id người dùng của bạn. Nó chỉ có bất cứ thứ gì bạn đã đóng dấu lên giao dịch mua. Nếu đó là không có gì, giờ đây bạn phải tra ngược một id đơn hàng trần trụi và token mua trên các bản ghi của chính mình, hy vọng bạn đã ghi log token lúc mua và hy vọng sự khớp là rõ ràng. Nếu bạn đặt một obfuscated account id, giao dịch mua mang hàm băm của riêng bạn, bạn tra người dùng trong một truy vấn, và bạn chuyển sang dựng bằng chứng thay vì săn lùng danh tính.

orders.reviewrefund thực chất yêu cầu bạn những gì

Trả lời tranh chấp nghĩa là gọi phương thức orders.reviewrefund trong vòng 24 giờ. Google ghi nhận lần gọi đầu tiên của bạn và bỏ qua phần còn lại, nên câu trả lời đầu tiên là câu trả lời duy nhất. Đây là các trường nó muốn, và mỗi trường bằng chứng đều giả định bạn đã biết đơn hàng thuộc về người dùng nào.

Việc bỏ qua nó thực chất tốn kém thế nào

Trong phần lớn lịch sử của Google Play, một khoản bồi hoàn bạn không thể bảo vệ là một khoản bán hàng bị mất và một cái nhún vai. Điều đó đã thay đổi. Với các đơn hàng đặt vào hoặc sau ngày 3 tháng 8 năm 2026, một khoản bồi hoàn thua tính vào nhà phát triển giá mua trừ đi phí dịch vụ của Google, cộng với phí bồi hoàn của ngân hàng. Tranh chấp bạn không thể trả lời giờ đây là một khoản mục.

Hãy đi qua một đơn hàng. Một khách hàng tranh chấp một giao dịch mua $9.99 với ngân hàng của họ. Google Play gửi phiên xem xét, và bạn có 24 giờ. Nếu bạn đã gắn thẻ giao dịch mua, bạn tìm ra người dùng, thấy họ đã tiêu thụ phần lớn thứ họ mua, và trả lời reviewrefund với một tùy chọn DECLINE cùng bằng chứng tiêu thụ, cho Google một lập luận thực sự để phản đối một tranh chấp không chính đáng. Nếu bạn không gắn thẻ nó, bạn hoặc là không thể nhận diện đơn hàng kịp thời hoặc trả lời với không gì cả, tranh chấp được quyết định mà không có phía của bạn, và trên một đơn hàng sau ngày 3 tháng 8 bạn phải trả lại $9.99 trừ phí của Google, cộng với một phí bồi hoàn ngân hàng cố định thường rơi vào khoảng $20. Trên một giao dịch nhỏ, riêng phí cố định đó có thể lớn hơn số bạn thu về ròng.

• Khoản thu bị mất: phần ròng của bạn từ giao dịch, bị đảo ngược.
• Phí bồi hoàn của ngân hàng: một chi phí cố định do mạng lưới thẻ đặt ra, tính thêm lên trên với các đơn hàng đặt sau ngày 3 tháng 8 năm 2026, mà một khoản hoàn tiền thông thường không bao giờ mang theo.
• Khoản chi phí lãng phí: sức tính toán, các lệnh gọi API bên thứ ba, và lưu trữ mà tài khoản đã dùng, mất đi dù bạn có thể trả lời hay không.
• Mô hình bạn không thấy được: không có một id tài khoản ổn định bạn cũng không thể biết rằng cùng một người dùng đang tranh chấp hết lần này đến lần khác, nên lạm dụng có hệ thống bị đọc thành các khoản lỗ đơn lẻ không liên quan.

Cách đặt nó mà không khiến giao dịch mua bị chặn

Hai quy tắc bao trùm gần như mọi sai lầm mà các đội mắc phải với trường này. Băm id, và đặt nó ở mọi nơi.

Băm id người dùng của bạn, không bao giờ gửi PII

Đừng đặt một email, một số điện thoại, hay bất kỳ chi tiết cá nhân thô nào vào trường này. Google nói rõ rằng lưu PII như email ở dạng văn bản rõ dẫn đến việc các giao dịch mua bị chặn, và khuyến nghị một hàm băm một chiều hoặc mã hóa để tạo ra giá trị. Cách làm sạch sẽ là một hàm băm một chiều của id người dùng nội bộ của bạn, tính theo cùng một cách mỗi lần để cùng một người dùng luôn tạo ra cùng một chuỗi 64 ký tự. Cũng đừng dùng id tài khoản Google của người đó hay id nhà phát triển của bạn. Giá trị chỉ nên có ý nghĩa với hệ thống của bạn.

Đặt nó trên mọi giao dịch mua, và đọc lại nó trên máy chủ của bạn

Gắn id vào mọi luồng thanh toán, cả sản phẩm một lần lẫn đăng ký, để không giao dịch mua nào từng không được gắn nhãn. Sau giao dịch mua, đọc lại nó ở hai nơi. Trên máy khách, Purchase.getAccountIdentifiers trả về một đối tượng mà getObfuscatedAccountId của nó cho bạn chuỗi bạn đã đặt. Trên backend của bạn, bản ghi giao dịch mua phía máy chủ mang nó dưới dạng trường obfuscatedExternalAccountId, và bản sao trên máy chủ là bản đáng tin, vì một tranh chấp đến máy chủ của bạn, không phải đến thiết bị.

Dùng setObfuscatedProfileId khi một tài khoản có nhiều hồ sơ

Nếu ứng dụng của bạn cho phép một tài khoản giữ nhiều hồ sơ, một hộ gia đình xem streaming hay một trò chơi với nhiều nhân vật, hãy đặt cả setObfuscatedProfileId. Nó là cùng một loại chuỗi đã băm, 64 ký tự, không PII, giới hạn ở hồ sơ đã thực hiện giao dịch mua. Google lưu ý rằng đặt một id hồ sơ cũng yêu cầu truyền cả id tài khoản, nên hãy gửi cả hai. Kết quả là một tranh chấp ánh xạ không chỉ tới tài khoản mà tới đúng hồ sơ đã tiêu tiền.

Phần tương đương trên iOS, trong một dòng

App Store có cùng ý tưởng dưới một cái tên khác. Trên iOS bạn gắn một appAccountToken, một UUID, vào một giao dịch mua, và nó quay lại trên giao dịch và trên CONSUMPTION_REQUEST mà Apple gửi khi một khách hàng yêu cầu hoàn tiền. Hình dạng của vấn đề là giống hệt nhau trên cả hai cửa hàng. Luồng tranh chấp hoặc hoàn tiền tham chiếu tới một giao dịch, và định danh của riêng bạn là thứ nối nó về một người dùng mà bạn có thể báo cáo mức sử dụng.

Không điều nào trong số này khó xây dựng. Nó dễ bị bỏ qua, vì cái ngày bạn viết mã thanh toán không phải cái ngày một khoản bồi hoàn đến, và chi phí của việc bỏ qua nó vô hình cho tới lúc đó. RefundHalt đặt và theo dõi định danh tài khoản trên cả hai cửa hàng, giữ liên kết giao dịch mua tới người dùng để một tranh chấp luôn phân giải về một khách hàng thực, và trả lời orders.reviewrefund của Google Play cùng CONSUMPTION_REQUEST của Apple trong các cửa sổ của chúng bằng bằng chứng tiêu thụ được ghi lại tại thời điểm bán. Chiếc đồng hồ 24 giờ không phải lúc để phát hiện ra rằng bạn không thể nói ai đã mua món đó.