Hãy xác minh thông báo máy chủ App Store trước khi xử lý hoàn tiền, vì bất kỳ ai cũng có thể gửi yêu cầu đến URL webhook của bạn

Bất kỳ ai biết URL webhook của bạn đều có thể gửi đến đó một yêu cầu hoàn tiền. Đó là sự thật khó chịu đằng sau mọi thông báo máy chủ App Store và mọi Real-time developer notification của Google Play: cho đến khi bạn xác minh, tin nhắn đó chỉ là một HTTPS POST chứa một ít JSON. Nếu máy chủ của bạn hủy gói đăng ký, thu hồi tín dụng hoặc khóa tài khoản chỉ vì một yêu cầu ghi REFUND, bạn đã trao quyền đó cho bất kỳ ai biết viết một lệnh curl.

Cả hai cửa hàng đều cho bạn cách kiểm tra. Apple ký chính thông báo, nên bạn có thể xác minh thông báo máy chủ App Store chỉ với chứng chỉ gốc của Apple. Google Play đi theo hướng khác. Tin nhắn không được ký, nhưng việc phân phối qua Pub/Sub thì có thể được ký, và dù sao Google cũng yêu cầu bạn xác nhận mọi thay đổi bằng API của họ. Dưới đây là những gì mỗi bên chứng minh được, và cái giá phải trả khi bạn sai theo bất kỳ hướng nào.

Mỗi cửa hàng thực sự ký những gì

Cách xác minh thông báo máy chủ App Store

Tài liệu của Apple mô tả signedPayload là một chuỗi gồm ba thành phần mã hóa Base64URL, phân tách bằng dấu chấm: header, payload và chữ ký, được ký theo đặc tả JSON Web Signature. Giải mã payload thì dễ. Tin tưởng nó thì cần bốn bước kiểm tra.

• Đọc mảng x5c từ header đã giải mã. Apple ghi rõ thứ tự: đầu tiên là chứng chỉ chứa khóa ký, tiếp theo là chứng chỉ trung gian của Apple, sau đó là chứng chỉ gốc của Apple.
• Xác thực chuỗi đó với chứng chỉ gốc của Apple mà bạn tự tải về từ trang PKI của Apple, trên thực tế là Apple Root CA - G3. Đừng bao giờ tin chứng chỉ gốc đi kèm trong tin nhắn, vì kẻ giả mạo có thể đặt bất kỳ chứng chỉ nào vào đó.
• Xác nhận chứng chỉ trung gian mang phần mở rộng Apple Worldwide Developer Relations, 1.2.840.113635.100.6.2.1, rồi xác minh chữ ký JWS bằng khóa công khai của chứng chỉ lá.
• Đối chiếu dữ liệu đã giải mã với ứng dụng của bạn: bundleId, appAppleId trong production, và environment. Một chữ ký Apple hợp lệ trên ứng dụng của nhà phát triển khác, hoặc trên một giao dịch sandbox gửi đến endpoint production của bạn, vẫn không phải là khoản hoàn tiền của bạn.

Sau đó làm lại một lần nữa với phần bên trong. Đối tượng data chứa signedTransactionInfo và signedRenewalInfo, mỗi cái là một JWS riêng với chuỗi x5c riêng. Một handler REFUND xác minh lớp vỏ nhưng đọc giao dịch mà không xác minh nó đã để lại một lỗ hổng ở giữa.

Dùng thư viện của Apple thay vì tự viết

Apple phát hành App Store Server Library cho Swift, Java, Python và Node. SignedDataVerifier của thư viện nhận các chứng chỉ gốc của bạn, một cờ kiểm tra trực tuyến, environment, bundle ID của bạn và, với production, appAppleId của bạn. Mã nguồn Node cho thấy những gì nó bắt buộc: đúng ba chứng chỉ trong chuỗi, phần mở rộng chứng chỉ lá của Apple 1.2.840.113635.100.6.11.1 và phần mở rộng của chứng chỉ trung gian, ngày hiệu lực của chứng chỉ, cùng bundle ID, app ID và environment khớp nhau. Khi bật kiểm tra trực tuyến, nó còn hỏi máy chủ phản hồi OCSP xem chứng chỉ lá và chứng chỉ trung gian có bị thu hồi hay không.

Danh sách IP cho phép có đủ không?

Không. Apple cho biết nếu máy chủ của bạn cần danh sách cho phép, bạn nên thêm subnet 17.0.0.0/8, áp dụng cho cả sandbox và production. Việc đó giảm bớt nhiễu. Nhưng nó không chứng minh tin nhắn là thật, và nó sẽ hỏng ngay khi mạng của Apple thay đổi theo cách bạn không được báo trước. Hãy giữ bước kiểm tra chữ ký làm cửa chặn thực sự.

Cách xác minh thông báo hoàn tiền của Google Play

Google Play xuất bản tin nhắn RTDN lên một topic Pub/Sub do bạn sở hữu, và chỉ service account google-play-developer-notifications@system.gserviceaccount.com mới nên giữ vai trò Pub/Sub Publisher trên topic đó. Sau đó subscription của bạn phân phối tin nhắn theo một trong hai cách, và mỗi cách có bằng chứng riêng.

• Pull subscription: máy chủ của bạn mở một kết nối có xác thực đến Pub/Sub và lấy tin nhắn về. Không có endpoint công khai, nên người lạ không có nơi nào để gửi đến.
• Push subscription có bật xác thực: Pub/Sub ký một JSON Web Token và gửi nó trong header Authorization dưới dạng token Bearer. Hướng dẫn của Google yêu cầu xác thực chữ ký của token và kiểm tra rằng các claim email và audience khớp với giá trị bạn đã cấu hình, và mã mẫu của họ còn yêu cầu email_verified phải là true. Token có thể đã được tạo từ tối đa một giờ trước.
• Push subscription không có xác thực: bất cứ thứ gì truy cập được URL đều có thể gửi một tin nhắn trông giống RTDN.

Vì sao Google muốn bạn xác nhận bằng API

Ngay cả một RTDN được xác thực hoàn hảo cũng không mang đầy đủ thông tin. Hướng dẫn thiết lập của Google nói rõ rằng các thông báo này chỉ cho bạn biết trạng thái giao dịch mua đã thay đổi, và bạn phải gọi Google Play Developer API để lấy trạng thái đầy đủ. Với voidedPurchaseNotification, điều đó có nghĩa là tìm giao dịch mua trong Voided Purchases API, hoặc lấy trạng thái hiện tại của nó, trước khi thu hồi bất cứ thứ gì. Lệnh gọi API được xác thực bằng service account của chính bạn, nên câu trả lời của nó là thứ kẻ giả mạo không thể làm giả.

Một khoản hoàn tiền giả mạo hoặc bị từ chối khiến bạn tốn bao nhiêu tiền

Một thông báo hoàn tiền giả mạo mà bạn tin tưởng sẽ khiến bạn mất một khách hàng trả phí. Bạn khóa quyền truy cập của một người mà bạn vẫn đang giữ tiền của họ, họ mở phiếu hỗ trợ, và một số người sẽ đến cửa hàng để yêu cầu khoản hoàn tiền mà hệ thống của bạn đã giả vờ chấp thuận. Một giao dịch mua hoặc gia hạn giả mạo thì gây tốn kém theo chiều ngược lại: bạn cung cấp tài nguyên tính toán GPU, các lệnh gọi API bên thứ ba trả phí, dung lượng lưu trữ và tiền chi trả cho nhà sáng tạo dựa trên doanh thu chưa từng tồn tại.

Kiểu thất bại ngược lại thì âm thầm hơn và thường lớn hơn. Một trình xác minh từ chối tin nhắn thật, do appAppleId sai, cấu hình sandbox trong production hoặc chứng chỉ gốc lỗi thời, sẽ đánh rơi đúng hai luồng hoàn tiền mà bằng chứng của bạn có giá trị. Apple yêu cầu dữ liệu tiêu thụ trong vòng 12 giờ kể từ CONSUMPTION_REQUEST. Google cho bạn 24 giờ để trả lời đợt xem xét chargeback qua orders.reviewrefund, và với các đơn hàng đặt sau ngày 3 tháng 8 năm 2026, một vụ chargeback Google Play bị thua sẽ khiến bạn mất giá mua trừ phí dịch vụ của Play, cộng thêm khoản phí mà ngân hàng của người mua tính.

Đừng để lỗi xác minh nuốt mất thời hạn

• Lưu yêu cầu gốc trước khi xác minh, để một tin nhắn bị từ chối không bao giờ thực sự bị mất.
• Cảnh báo với mọi lần xác minh thất bại. Một tin nhắn giả mạo chỉ là nhiễu. Mọi tin nhắn cùng thất bại một lúc là lỗi của chính bạn.
• Với Apple, bạn có thể phát lại những gì đã từ chối. Get Notification History trả về signedPayload gốc trong 180 ngày gần nhất, vì vậy hãy sửa trình xác minh rồi chạy lại các payload đã lưu hoặc khôi phục qua nó.
• Với Google, một đợt xem xét chargeback đang chờ chỉ tồn tại trong thông báo của nó, nên audience push bị cấu hình sai đồng nghĩa với một đợt xem xét bị bỏ lỡ. Hãy kiểm tra bằng Send Test Message trong Play Console sau mỗi lần thay đổi.

RefundHalt xác minh thông báo của cả hai cửa hàng, xác nhận hoàn tiền bằng API của cửa hàng trước khi bất cứ điều gì thay đổi, và trả lời CONSUMPTION_REQUEST cũng như các đợt xem xét chargeback trong thời hạn của chúng, để một tin nhắn giả không thể làm bạn mất khách hàng và một tin nhắn thật không thể lọt qua.