Ứng dụng của bạn có thể hiển thị bảng yêu cầu hoàn tiền ngay trong ứng dụng, và đây là những gì Apple làm sau khi khách hàng nhấn gửi

Apple cho phép khách hàng yêu cầu hoàn tiền mà không cần rời khỏi ứng dụng của bạn. Một lệnh gọi StoreKit, beginRefundRequest, trình bày bảng hoàn tiền của chính Apple ngay trong giao diện của bạn, khách hàng chọn một lý do, và yêu cầu được gửi đến Apple để xét duyệt. Bạn không dựng biểu mẫu, bạn không chạm vào tiền, và bạn không quyết định kết quả. Cái bạn nhận được là một cách đặt lối hoàn tiền ngay nơi khách hàng đang bực bội đã có mặt, thay vì để mất họ vào tay ngân hàng của họ. Đây là yêu cầu hoàn tiền trong ứng dụng, và bạn nên hiểu nó trước khi quyết định có phát hành nút này hay không.

Đây là phần quan trọng đối với doanh thu của bạn. Bản thân nút này không hoàn lại bất cứ khoản nào. Nó mở một yêu cầu, Apple mất tối đa 48 giờ để chấp thuận hoặc từ chối, và với các giao dịch mua tiêu dùng, trước tiên nó bắn một CONSUMPTION_REQUEST vào máy chủ của bạn. Vậy nên bảng này không phải một món quà cho không. Nó là một phễu dẫn vào chính quy trình xét duyệt hoàn tiền mà bạn vốn đã có thể tác động, và nó có thể kéo một tranh chấp về khỏi mạng lưới thẻ trước khi nó trở thành một khoản bồi hoàn mà bạn không thể phản đối.

Bảng yêu cầu hoàn tiền trong ứng dụng thực chất là gì

beginRefundRequest là một phương thức StoreKit 2 trình bày bảng yêu cầu hoàn tiền cho một transaction trong một window scene. Chữ ký của nó ngắn gọn: func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus. Khi bạn gọi nó, hệ thống hiển thị một bảng với chi tiết giao dịch mua của khách hàng và một danh sách mã lý do để họ chọn. Apple dựng và kiểm soát giao diện đó. Bạn cung cấp scene và transaction, không gì khác.

Hướng dẫn của Apple về nơi đặt nút rất rõ ràng. Hãy gọi hàm này từ phần cài đặt tài khoản hoặc một menu trợ giúp, để một khách hàng muốn hoàn tiền tìm thấy nó ở nơi họ sẽ tìm hỗ trợ. Nó ra mắt trong iOS 15 và iPadOS 15, Mac Catalyst 15, và visionOS 1, nên bất kỳ ứng dụng nào nhắm đến các phiên bản đó đều có thể trình bày nó ngay hôm nay.

Hai cách mở bảng

Có hai điểm vào. Bạn có thể gọi beginRefundRequest(in:) trên một transaction cụ thể mà bạn đang giữ, việc này giới hạn bảng vào đúng giao dịch mua đó. Bạn cũng có thể mở bảng theo mã định danh sản phẩm khi bạn muốn khách hàng hoàn tiền cho một giao dịch mua của một sản phẩm nhất định. Dù cách nào, bảng, danh sách lý do, và quyết định đều thuộc về Apple. Việc của bạn kết thúc ở chỗ trình bày nó và đọc kết quả.

Lệnh gọi trả về gì, và điều gì có thể sai sót

Phương thức này là async throws, nên nó hoặc trả về một trạng thái hoặc ném ra một lỗi. Cả hai đều là những danh sách ngắn, và cả hai đều đáng xử lý để giao diện của bạn nói điều gì đó đúng sau khi bảng đóng lại.

Điều gì xảy ra trên máy chủ của bạn sau khi khách hàng nhấn gửi

Việc bảng đóng lại là điểm bắt đầu của quy trình, không phải điểm kết thúc. Apple xét duyệt yêu cầu và mất tối đa 48 giờ để chấp thuận hoặc từ chối. Với một giao dịch mua tiêu dùng trong ứng dụng, trước khi quyết định, App Store gửi một thông báo CONSUMPTION_REQUEST đến máy chủ của bạn để xin dữ liệu sử dụng. Nếu khách hàng đã đồng ý chia sẻ dữ liệu đó, bạn trả lời qua endpoint Send Consumption Information. Nếu họ không đồng ý, chính chỉ dẫn của Apple là hoàn toàn không phản hồi thông báo đó.

Một khi Apple ra quyết định, kết quả đến máy chủ của bạn dưới dạng một App Store Server Notification. Đó chính là luồng dữ liệu bạn vốn đã nhận, và yêu cầu trong ứng dụng đi vào đó y hệt như một khoản hoàn tiền mà khách hàng bắt đầu trên trang reportaproblem của Apple. Không có gì trong cách xử lý thay đổi chỉ vì yêu cầu bắt đầu bên trong ứng dụng của bạn.

Nút này khiến bạn tốn gì, và nó có thể tiết kiệm được gì

Một khoản hoàn tiền bạn có thể phản đối tốt hơn một khoản bồi hoàn bạn không thể

Một khách hàng không tìm được lối hoàn tiền bên trong ứng dụng của bạn sẽ không bỏ cuộc. Họ tìm đến ngân hàng của họ. Một khoản bồi hoàn thẻ là quyết định cuối cùng với ngân hàng, nó kèm một khoản phí tranh chấp, và nó lấy quyền quyết định ra khỏi tay cả bạn lẫn Apple. Một yêu cầu hoàn tiền trong ứng dụng giữ chính khách hàng đó trong hệ thống của Apple, nơi một giao dịch mua tiêu dùng kích hoạt một CONSUMPTION_REQUEST bạn có thể trả lời và một quyết định bạn có thể tác động. Đổi một khoản bồi hoàn không thể phản đối lấy một cuộc xét duyệt của Apple có thể phản đối chính là toàn bộ lập luận tài chính cho nút này.

Bạn đang giảm ma sát cho việc hoàn tiền

Mặt đối trọng trung thực là một lối hoàn tiền hiển thị rõ, chỉ một chạm sẽ tạo ra nhiều yêu cầu hoàn tiền hơn một email hỗ trợ bị chôn giấu. Một số trong đó lẽ ra đã không bao giờ xảy ra. Đó là một chi phí thật, và đó là lý do Apple bảo bạn đặt điểm vào ở phần cài đặt tài khoản hoặc một menu trợ giúp thay vì trên màn hình mua hàng. Bạn muốn khách hàng vốn đã không hài lòng tìm thấy nó, chứ không phải khách hàng chỉ đơn thuần tò mò.

Chi phí chạy suốt cả quá trình là việc phục vụ một tài khoản đã được hoàn tiền

Dù quyết định ngả về hướng nào, đồng hồ tính chi phí phân phối vẫn chạy cho đến khi bạn hành động theo kết quả. Mỗi giờ một quyền lợi đã được hoàn tiền vẫn còn hoạt động, bạn tiếp tục trả những chi phí thật đằng sau nó: điện toán, các lệnh gọi model API, lưu trữ, và bất kỳ khoản chi trả cho nhà sáng tạo hay đối tác nào gắn với việc sử dụng của khách hàng đó. Yêu cầu trong ứng dụng không thay đổi điều đó. Thu hồi kịp thời khi có thông báo REFUND thì có. Nút này chỉ rẻ đúng bằng cách bạn xử lý thông báo mà rốt cuộc nó tạo ra.

Bạn có nên phát hành yêu cầu hoàn tiền trong ứng dụng không

Đặt nó ở nơi hỗ trợ tồn tại, không phải nơi bán hàng tồn tại

Hãy làm theo hướng dẫn về vị trí của Apple. Phần cài đặt tài khoản và một menu trợ giúp là những chỗ đặt đúng. Một liên kết hoàn tiền ngay cạnh một paywall dạy người ta trông đợi lấy lại tiền của mình, và nó mời gọi khoản hoàn tiền vì tò mò mà bạn chưa bao giờ cần phải đưa ra.

Kiểm thử toàn bộ luồng trong sandbox trước khi tin tưởng nó

Bạn có thể mô phỏng toàn bộ đường đi trong sandbox và trong công cụ kiểm thử StoreKit của Xcode, chuyển một yêu cầu từ đang chờ sang được chấp thuận hoặc bị từ chối. Một sự chấp thuận gửi một thông báo REFUND đến máy chủ của bạn, và một sự từ chối gửi REFUND_DECLINED, nên bạn có thể chứng minh bộ xử lý của mình phản ứng đúng trước khi một khách hàng thật sự nhấn gửi.

Xử lý mọi kết quả, và đừng bao giờ tuyên bố quá mức

Hiển thị đang chờ khi success, mời thử lại khi failed, nói rằng không có gì thay đổi khi userCancelled, và coi duplicateRequest như một ghi chú lặng lẽ rằng yêu cầu trước đó của khách hàng vẫn còn hiệu lực. Sai lầm duy nhất gây tổn hại là nói với khách hàng rằng khoản hoàn tiền của họ đã xong trong khi tất cả những gì bạn nắm chỉ là một yêu cầu đã gửi.

RefundHalt xử lý phần hậu kỳ như thế nào

Bảng trong ứng dụng là của Apple. Những gì đến sau nó là của bạn, và đó là phần RefundHalt vận hành. Khi một khách hàng gửi một yêu cầu hoàn tiền từ bên trong ứng dụng của bạn, RefundHalt bắt lấy CONSUMPTION_REQUEST cho các giao dịch mua tiêu dùng và trả lời nó trong cửa sổ 12 giờ bằng bằng chứng sử dụng giúp Apple quyết định. Khi Apple phán quyết, nó thu hồi khi có REFUND và giữ nguyên quyền truy cập khi có REFUND_DECLINED, mỗi hành động gắn với đúng transaction. Bạn có thể đưa ra lối hoàn tiền trong ứng dụng thân thiện hơn mà không phó mặc việc xét duyệt, bằng chứng, hay việc thu hồi cho một cuộc xoay xở thủ công.