Cách xử lý yêu cầu hoàn tiền của Apple trước khi mất doanh thu

Một yêu cầu hoàn tiền bắt đầu từ hành động của khách hàng. Về phía bạn, nó trở thành một chuỗi sự kiện mà backend của bạn hoặc xử lý được, hoặc bỏ lỡ.

Apple có thể yêu cầu server của bạn cung cấp thông tin. Việc đó có thời hạn. Kết quả sau đó được gửi đến dưới dạng thông báo, và trạng thái truy cập trong ứng dụng của bạn cần thay đổi cho khớp. Nếu bất kỳ mắt xích nào trong chuỗi đó bị thiếu, việc hoàn tiền vẫn diễn ra — bạn chỉ biết muộn hơn, qua báo cáo thanh toán hoặc từ một người dùng đang bối rối.

Bạn không thể quyết định Apple có chấp thuận hoàn tiền hay không. Đó là quyết định của Apple, và không công cụ nào dành cho nhà phát triển thay đổi được điều đó. Điều bạn có thể quyết định là hệ thống của bạn đã sẵn sàng hay chưa khi yêu cầu đến.

Hướng dẫn này bao gồm những việc cần làm trước, trong và sau một yêu cầu hoàn tiền của Apple. Nếu bạn muốn nhìn bức tranh vận hành rộng hơn, hướng dẫn của chúng tôi về quản lý hoàn tiền App Store bao quát toàn bộ quy trình xung quanh.

Những điểm chính

• Apple đưa ra quyết định hoàn tiền cuối cùng. Nhà phát triển không chấp thuận hay từ chối yêu cầu hoàn tiền.

• Apple có thể yêu cầu thông tin sử dụng (consumption). Khi đó, nhà phát triển có thể phản hồi nếu có sự đồng ý của khách hàng và trong thời hạn quy định.

• Thông báo hoàn tiền phải đến được backend của bạn, nếu không thì về phía bạn các sự kiện đó coi như không tồn tại.

• Kết quả hoàn tiền phải làm thay đổi trạng thái ứng dụng, không chỉ được ghi log.

• Thời gian rất quan trọng khi Apple đặt ra thời hạn phản hồi. Yêu cầu hoàn tiền không chờ giờ làm việc.

• Tự động hóa chủ yếu giúp tránh bỏ lỡ các bước: bỏ lỡ thông báo, bỏ lỡ thời hạn, bỏ lỡ cập nhật entitlement.

Điều gì xảy ra khi khách hàng yêu cầu hoàn tiền trên Apple?

Khách hàng gửi yêu cầu qua Apple. Apple đánh giá yêu cầu, có thể hỏi bạn thông tin trong quá trình đó, ra quyết định, rồi báo cho server của bạn biết điều gì đã xảy ra.

Bước 3 có điều kiện. Apple gửi consumption request cho một số loại giao dịch mua và tình huống nhất định, không tự động gửi cho mọi yêu cầu hoàn tiền. Xây dựng logic với giả định rằng thông báo này luôn đến sẽ tạo ra lỗ hổng.

Vì sao yêu cầu hoàn tiền của Apple có thể trở thành vấn đề doanh thu

Số tiền hoàn lại là chi phí nhìn thấy được, và hiếm khi là chi phí lớn nhất. Một kỳ subscription bị hoàn tiền đảo ngược doanh thu bạn đã ghi nhận và thường chấm dứt luôn chuỗi gia hạn phía sau — những lần gia hạn có lẽ đã nằm trong dự báo.

Rồi đến vấn đề trạng thái. Nếu thông báo kết quả không bao giờ đến, khách hàng vẫn giữ quyền truy cập trả phí. Cơ sở dữ liệu của bạn nói là đang hoạt động, Apple nói là đã hoàn tiền, và không ai đối soát hai bên cho đến khi có người phàn nàn.

Xung quanh đó là những chi phí âm thầm hơn: báo cáo thanh toán phải đối soát thủ công, những cuộc trao đổi hỗ trợ về quyền truy cập vốn không nên xảy ra, yêu cầu hoàn tiền App Store đến lúc nửa đêm và được trả lời quá muộn. Và khi không có lịch sử hoàn tiền, các nguyên nhân lặp lại vẫn vô hình.

Nhà phát triển có thể kiểm soát quyết định hoàn tiền của Apple không?

Không. Apple đưa ra quyết định hoàn tiền cuối cùng. Nhà phát triển có thể cung cấp thông tin sử dụng được yêu cầu khi áp dụng và quản lý trạng thái ứng dụng phát sinh về phía mình.

Phân định rõ ranh giới đó giúp tiết kiệm rất nhiều công sức vô ích.

Những gì bạn kiểm soát

• Thông báo có đến và được backend của bạn xử lý hay không

• Giao dịch có được lưu trữ và tìm lại được sau này hay không

• Một giao dịch có ánh xạ tới một tài khoản người dùng cụ thể hay không

• Dữ liệu sử dụng có chính xác và được chuẩn bị trước hay không

• Bạn có sự đồng ý hợp lệ để gửi dữ liệu đó hay không

• Bạn có phản hồi trong thời hạn của Apple hay không

• Entitlement, hồ sơ và báo cáo có được cập nhật sau khi có kết quả hay không

Những gì bạn không kiểm soát

• Quyết định cuối cùng của Apple đối với từng trường hợp hoàn tiền

• Cách Apple cân nhắc các yếu tố đằng sau quyết định đó

• Chính sách hoàn tiền dành cho khách hàng và quy tắc về điều kiện hoàn tiền của Apple

Cách phản hồi yêu cầu hoàn tiền của Apple

Tám bước. Phần lớn diễn ra trước khi có bất kỳ yêu cầu hoàn tiền nào.

1. Đảm bảo App Store Server Notifications đến được backend của bạn

Sự kiện hoàn tiền được gửi đến một endpoint server do bạn cấu hình. Nếu endpoint không truy cập được, chưa được xác minh, hoặc âm thầm gặp lỗi, những sự kiện đó coi như biến mất khỏi tầm nhìn của bạn. Apple mô tả cách thiết lập và định dạng payload có ký trong tài liệu tham chiếu App Store Server Notifications. Hãy xác minh chữ ký, trả về phản hồi thành công, và ghi log những gì nhận được trước khi xử lý.

2. Xác định giao dịch và khách hàng

Thông báo tham chiếu đến mã định danh giao dịch của Apple, không phải của bạn. Bạn cần một bản ghi giao dịch đã lưu để đối chiếu, và một cách để truy ngược về tài khoản người dùng. Phần thứ hai là việc của appAccountToken — một UUID được gắn vào lúc mua. Trường này là tùy chọn, và đó là lý do nhiều team về sau phải viết các heuristic đối chiếu.

3. Kiểm tra xem Apple có yêu cầu thông tin sử dụng không

Thông báo CONSUMPTION_REQUEST có nghĩa là Apple đang hỏi về việc khách hàng sử dụng sản phẩm trong khi đánh giá yêu cầu hoàn tiền. Đây không phải thông báo rằng việc hoàn tiền đã diễn ra, và nó không đến với mọi trường hợp hoàn tiền. Hãy coi đây là một loại sự kiện riêng với handler riêng.

4. Kiểm tra yêu cầu về sự đồng ý

Chỉ gửi dữ liệu sử dụng khi đáp ứng các yêu cầu của Apple. Tài liệu Send Consumption Information của Apple nói rất rõ: bạn phải có được sự đồng ý hợp lệ từ khách hàng trước khi chia sẻ dữ liệu của họ, và việc lấy sự đồng ý đó là trách nhiệm của bạn, không phải của Apple. Thông báo không mang theo tín hiệu đồng ý nào — bạn phải biết điều đó từ hồ sơ của chính mình. Nếu khách hàng chưa đồng ý, hướng dẫn của Apple là không phản hồi.

Vì vậy, sự đồng ý là vấn đề của ứng dụng, cần được thu thập trước khi có bất kỳ yêu cầu hoàn tiền nào. Gắn thêm vào sau đó sẽ không hiệu quả.

5. Chuẩn bị thông tin sử dụng chính xác

Payload mô tả điều thực sự đã xảy ra với giao dịch mua, nên hãy lấy giá trị từ hồ sơ của chính bạn thay vì ước lượng. Apple mô tả các trường và giá trị hợp lệ của chúng, bao gồm cách cho biết bạn không cung cấp một trường cụ thể nào đó. Độ chính xác quan trọng hơn cách diễn đạt: đây là đầu vào cho quy trình của Apple, không phải lập luận bạn đưa ra.

6. Phản hồi trong thời hạn Apple yêu cầu

Tài liệu hiện tại của Apple yêu cầu phản hồi trong vòng 12 giờ kể từ khi có thông báo. Hãy kiểm tra trang tài liệu thay vì tin vào một triển khai cũ — Apple đã sửa đổi endpoint này và hiện mô tả nhiều hơn một phiên bản. Mười hai giờ là lý lẽ thực tế mạnh nhất để tự động hóa bước này, vì yêu cầu đến vào ban đêm và cuối tuần.

7. Theo dõi kết quả cuối cùng

Lưu lại kết quả. REFUND nghĩa là được chấp thuậ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 trước đó đã chấp thuận. Các team thường xử lý hai loại đầu và quên loại thứ ba, khiến khách hàng mất quyền truy cập mà họ đáng được hưởng.

8. Cập nhật entitlement và trạng thái truy cập

Trạng thái truy cập trong ứng dụng phải khớp với trạng thái giao dịch. Khi hoàn tiền được chấp thuận, thu hồi quyền truy cập sau khi hoàn tiền. Khi bị đảo ngược, khôi phục lại. Hãy điều khiển việc này từ sự kiện phía server thay vì kiểm tra phía client, để trạng thái luôn đúng ngay cả khi khách hàng không bao giờ mở ứng dụng nữa.

Cách xử lý hoàn tiền Apple mà không mất nhiều doanh thu hơn cần thiết

Biết cách xử lý hoàn tiền Apple không đồng nghĩa với cố ngăn chặn mọi trường hợp hoàn tiền.

Một số yêu cầu là chính đáng. Một khoản bị tính phí hai lần, nội dung không được mở khóa, subscription gia hạn sau khi ai đó tin rằng họ đã hủy. Phản ứng hữu ích ở đây là sửa vấn đề gốc.

Phần còn lại là kỷ luật: hồ sơ giao dịch chính xác, xử lý sự kiện nhanh, dữ liệu sử dụng trung thực, entitlement nhất quán, và lịch sử hoàn tiền có thể truy vấn. Điều cuối cùng làm lộ ra các nguyên nhân lặp lại — một sản phẩm có tỷ lệ hoàn tiền cao hơn hẳn các sản phẩm khác, một đợt tăng vọt sau khi phát hành, một paywall không nói rõ sẽ tính phí gì. Không điều nào loại bỏ được hoàn tiền. Nó giảm tổn thất có thể tránh và giữ trạng thái ứng dụng chính xác, và đó mới là mục tiêu thực tế.

Còn khách hàng muốn yêu cầu hoàn tiền Apple thì sao?

Khách hàng không yêu cầu hoàn tiền từ nhà phát triển. Nếu bạn đang thắc mắc cách yêu cầu hoàn tiền cho giao dịch mua trên Apple, hoặc cách yêu cầu hoàn tiền nội dung App Store, con đường là quy trình riêng của Apple: đăng nhập tại reportaproblem.apple.com, chọn “Request a refund” (Yêu cầu hoàn tiền), chọn lý do và mục cần hoàn, rồi gửi. Trang của Apple về yêu cầu hoàn tiền cho ứng dụng hoặc nội dung hướng dẫn từng bước, và lưu ý rằng thường mất 24 đến 48 giờ để có cập nhật về yêu cầu.

Đó là nửa dành cho khách hàng. Mọi thứ khác trong bài viết này là nửa dành cho nhà phát triển, và hai nửa chạy trên những mốc thời gian khác nhau.

Chính sách hoàn tiền của Apple và quản lý hoàn tiền của nhà phát triển

Hai khái niệm này thường bị nhầm lẫn đủ nhiều để đáng tách riêng. Chính sách hoàn tiền của Apple điều chỉnh phía khách hàng: ai có thể yêu cầu hoàn tiền, qua quy trình nào, và theo điều kiện gì. Apple cho biết điều kiện hoàn tiền có thể khác nhau theo quốc gia hoặc khu vực, với Điều khoản và Điều kiện Apple Media Services làm căn cứ, và quyền bảo vệ người tiêu dùng được áp dụng khi luật địa phương quy định. Nhà phát triển không thiết lập bất kỳ điều nào trong số này.

Quản lý hoàn tiền của nhà phát triển là mọi thứ ở phía bạn: nhận sự kiện, xác định giao dịch, phản hồi khi được hỏi, theo dõi kết quả, cập nhật quyền truy cập, và hiểu tác động doanh thu. Chính sách của Apple xác định điều gì xảy ra với khách hàng. Hệ thống của bạn xác định điều gì xảy ra với ứng dụng của bạn.

Khi nào nhà phát triển nên tự động hóa xử lý hoàn tiền Apple?

Xử lý thủ công hiệu quả khi khối lượng còn thấp và một người có thể nhớ hết trong đầu.

Nó thất bại vì những lý do rất bình thường. Thông báo đến lúc 3 giờ sáng. Kỹ sư viết handler hoàn tiền chuyển sang team khác. Transaction ID nằm ở một hệ thống và tài khoản nằm ở hệ thống khác. Thời hạn phản hồi hết trước khi có ai đọc thông báo, và bộ phận tài chính phát hiện lỗ hổng lúc chốt quý.

Tự động hóa bao quát các phần có tính xác định: nhận và xác minh thông báo, đối chiếu giao dịch với người dùng, theo dõi thời hạn, cập nhật entitlement, lưu giữ lịch sử có thể tìm kiếm. Nó không ảnh hưởng đến quyết định của Apple, và bất kỳ công cụ nào gợi ý điều ngược lại đang mô tả sai quy trình.

Phần mềm quản lý hoàn tiền App Store thực sự nên làm gì?

Phần mềm quản lý hoàn tiền App Store nên lấp những lỗ hổng cụ thể mà xử lý thủ công để lại.

Nó nên giám sát và xác minh thông báo, để sự kiện không biến mất vào một endpoint đang lỗi. Nó nên phân tách các loại sự kiện hoàn tiền, vì consumption request và kết quả hoàn tiền cần cách xử lý khác nhau. Nó nên ánh xạ giao dịch với tài khoản, vì đó là nơi công việc thủ công tập trung nhiều nhất. Nó nên theo dõi thời hạn phản hồi, vì đó là hạn chót mọi người hay bỏ lỡ. Xung quanh đó: hỗ trợ quy trình consumption bao gồm trạng thái đồng ý, lịch sử hoàn tiền có thể tìm kiếm, đồng bộ entitlement, và báo cáo đủ rõ để thấy các mẫu hình lặp lại.

Giá trị không nằm ở số lượng tính năng. Mà ở việc không bước nào trong số này phụ thuộc vào việc ai đó nhớ kiểm tra.

Các quy tắc này được ghi ở đâu

Mọi tuyên bố liên quan đến Apple ở trên đều lấy từ tài liệu chính thức của Apple. Hãy đọc trực tiếp trước khi xây dựng, và kiểm tra lại định kỳ, vì các API hoàn tiền đã thay đổi nhiều hơn một lần.

Send Consumption Information — yêu cầu về sự đồng ý, thời hạn phản hồi và các trường của request. Nguồn tham chiếu chính thức cho các bước 4 đến 6.

App Store Server Notifications — thiết lập endpoint, định dạng payload có ký, và các loại thông báo, bao gồm CONSUMPTION_REQUEST, REFUND, REFUND_DECLINED và REFUND_REVERSED.

Yêu cầu hoàn tiền cho ứng dụng hoặc nội dung — quy trình dành cho khách hàng của Apple, và lưu ý rằng điều kiện hoàn tiền khác nhau theo quốc gia hoặc khu vực.

Lời kết

Bạn không quyết định kết quả hoàn tiền của Apple. Bạn quyết định hệ thống của mình phản ứng nhanh và chính xác đến đâu trước những kết quả đó.

Điều đó quy về vài thứ: thông báo đến được nơi cần đến, giao dịch bạn có thể xác định, thông tin chính xác được gửi khi Apple hỏi, kết quả được ghi lại, entitlement khớp với thực tế, và đủ tầm nhìn để thấy tác động doanh thu.

Nếu tuần này bạn chỉ muốn kiểm tra một thứ, hãy kiểm tra endpoint. Xác nhận URL App Store Server Notifications của bạn đang hoạt động, đã được xác minh, và đang ghi log những gì nhận được. Mọi thứ khác trong bài viết này phụ thuộc vào việc mảnh ghép đó hoạt động.

Nếu hoạt động hoàn tiền đã vượt quá khả năng theo dõi thủ công

Khi sự kiện hoàn tiền quá thường xuyên để theo dõi bằng tay, một hệ thống chuyên dụng có thể giám sát chúng, quản lý quy trình phản hồi, theo dõi kết quả, và cắt giảm công việc vận hành lặp lại. RefundSensor đảm nhận phía đó của quy trình — phía nhà phát triển, không phải phía Apple.