Your app can show an in-app refund request sheet, and here's what Apple does after a customer taps submit

Apple lets a customer request a refund without ever leaving your app. One StoreKit call, beginRefundRequest, presents Apple's own refund sheet right inside your interface, the customer picks a reason, and the request goes to Apple for review. You do not build the form, you do not touch the money, and you do not decide the outcome. What you get is a way to put a refund path where a frustrated customer already is, instead of losing them to their bank. This is the in-app refund request, and it is worth understanding before you decide whether to ship the button.

Here is the part that matters for your revenue. The button does not refund anything on its own. It opens a request, Apple takes up to 48 hours to approve or deny it, and for consumable purchases it fires a CONSUMPTION_REQUEST at your server first. So the sheet is not a giveaway. It is a funnel into the exact refund review you can already influence, and it can pull a dispute back from the card network before it becomes a chargeback you cannot contest.

What the in-app refund request sheet actually is

beginRefundRequest is a StoreKit 2 method that presents the refund request sheet for a transaction in a window scene. The signature is small: func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus. When you call it, the system shows a sheet with the customer's purchase details and a list of reason codes for them to choose from. Apple builds and controls that UI. You supply the scene and the transaction, nothing else.

Apple's guidance on where to put it is explicit. Call this function from account settings or a help menu, so a customer who wants a refund finds it where they would look for support. It shipped in iOS 15 and iPadOS 15, Mac Catalyst 15, and visionOS 1, so any app targeting those versions can present it today.

Two ways to open the sheet

There are two entry points. You can call beginRefundRequest(in:) on a specific transaction you already hold, which scopes the sheet to that one purchase. You can also open the sheet by product identifier when you want the customer to refund a purchase of a given product. Either way the sheet, the reason list, and the decision belong to Apple. Your job ends at presenting it and reading the result.

What the call returns, and what can go wrong

The method is async throws, so it either returns a status or throws an error. Both are short lists, and both are worth handling so your UI says something true after the sheet closes.

What happens on your server after the customer taps submit

The sheet closing is the start of the process, not the end. Apple reviews the request and takes up to 48 hours to approve or deny it. For a consumable in-app purchase, before it decides, the App Store sends a CONSUMPTION_REQUEST notification to your server asking for usage data. If the customer consented to share that data, you answer through the Send Consumption Information endpoint. If they did not consent, Apple's own instruction is to not respond to the notification at all.

Once Apple rules, the outcome lands on your server as an App Store Server Notification. That is the same feed you already receive, and the in-app request routes into it exactly like a refund a customer starts on Apple's reportaproblem page. Nothing about the handling changes just because the request began inside your app.

What the button costs you, and what it can save

A refund you can contest beats a chargeback you cannot

A customer who cannot find a refund path inside your app does not give up. They go to their bank. A card chargeback is final with the bank, it carries a dispute fee, and it takes the decision out of both your hands and Apple's. An in-app refund request keeps that same customer inside Apple's system, where a consumable purchase triggers a CONSUMPTION_REQUEST you can answer and a decision you can influence. Trading an uncontestable chargeback for a contestable Apple review is the whole financial argument for the button.

You are lowering the friction on a refund

The honest counterweight is that a visible, one-tap refund path produces more refund requests than a buried support email does. Some of those would never have happened. That is a real cost, and it is why Apple tells you to place the entry point in account settings or a help menu rather than on the purchase screen. You want the customer who is already unhappy to find it, not the customer who is merely curious.

The cost that runs the whole time is serving a refunded account

Whichever way the decision goes, the meter on delivery keeps running until you act on the outcome. Every hour a refunded entitlement stays live, you keep paying the real costs behind it: compute, model API calls, storage, and any creator or partner payout tied to that customer's usage. The in-app request does not change that. Revoking promptly on the REFUND notification does. The button is only as cheap as your handling of the notification it eventually produces.

Should you ship the in-app refund request

Put it where support lives, not where sales live

Follow Apple's placement guidance. Account settings and a help menu are the right homes. A refund link next to a paywall trains people to expect their money back, and it invites the curiosity refund you never needed to offer.

Test the full flow in the sandbox before you trust it

You can simulate the whole path in the sandbox and in Xcode's StoreKit testing, moving a request from pending to approved or declined. An approval delivers a REFUND notification to your server, and a denial delivers REFUND_DECLINED, so you can prove your handler reacts correctly before a real customer ever taps submit.

Handle every result, and never overclaim

Show pending on success, offer a retry on failed, say nothing changed on userCancelled, and treat duplicateRequest as a quiet note that the customer's earlier request still stands. The one mistake that hurts is telling a customer their refund is done when all you hold is a submitted request.

How RefundHalt handles the aftermath

The in-app sheet is Apple's. What comes after it is yours, and that is the part RefundHalt runs. When a customer submits a refund from inside your app, RefundHalt catches the CONSUMPTION_REQUEST for consumable purchases and answers it inside the 12-hour window with the usage evidence that helps Apple decide. When Apple rules, it revokes on REFUND and holds access untouched on REFUND_DECLINED, each keyed to the exact transaction. You get to offer the friendlier in-app refund path without leaving the review, the evidence, or the revocation to a manual scramble.