The App Store order ID on a customer's receipt tells you what they bought and whether Apple already refunded it

Before you answer an iPhone customer's refund email, ask for the App Store order ID on their Apple receipt. That one string, run through Apple's Look Up Order ID endpoint, tells you which product they bought, when, and whether Apple has already refunded it. Without it you're matching a screenshot and an email address against your database and hoping. With it, you know in seconds whether you're talking to a paying customer, a customer Apple already paid back, or someone holding a receipt from a different app.

Where the App Store order ID comes from

Apple's documentation is specific. When customers make one or more in-app purchases in your app, the App Store emails them a receipt, and that receipt contains an order ID. Customers can also find their order IDs in their purchase history on the App Store. Apple's purchase history page lives at reportaproblem.apple.com and in the App Store app under Apps & Purchase History, and it shows the last 90 days by default, with filters for older purchases.

So the customer already holds the key. Your support form just has to ask for it.

Why an email address isn't enough

Apple doesn't share the customer's Apple Account email with you. The address that writes to your support inbox may have nothing to do with the account that paid. If you set an appAccountToken at purchase, you can tie a transaction to your own user ID, but only from your side. The order ID works from the customer's side, from a receipt they can forward in one tap.

What Look Up Order ID returns

Look Up Order ID is part of the App Store Server API, available from version 1.1.0. You call GET https://api.storekit.apple.com/inApps/v1/lookup/{orderId} with your signed JWT. Apple says the response is based on the customer's in-app purchase history regardless of whether they installed, removed, or reinstalled the app.

Is it a valid receipt for my app?

That's the question OrderLookupStatus answers first. A 1 means the order ID didn't resolve to purchases in your app. The common cases are a typo, a receipt for a different app, or a receipt that isn't from the App Store at all. Don't refund, credit, or restore anything on a 1. Ask the customer to check the receipt again.

Did Apple already refund this purchase?

Check revocationDate on each decoded transaction. If it's set, Apple has already refunded that purchase or revoked it from Family Sharing, and the customer has their money. Your App Store Server Notifications should have sent a REFUND for the same transaction, so this is also a cheap way to confirm your server actually revoked access.

What the order ID can't do on the App Store

It can't issue a refund. Developers have no App Store refund button. Apple decides refunds, and its support article sends customers to reportaproblem.apple.com, where they choose "I'd like to", then "Request a refund", pick a reason, and select the item. Apple also says a pending charge can't be refunded until the customer has the email receipt.

The only place you get a say is Apple's CONSUMPTION_REQUEST. When a customer asks Apple for a refund, Apple can send that notification, and you have 12 hours to answer with Send Consumption Information. The order ID lookup is a support tool. It doesn't open that window or extend it.

What a refund email costs when you skip the lookup

Support without the order ID is where money leaks quietly. Three patterns show up again and again.

• Goodwill on top of a refund. Apple refunds the purchase, the customer also writes to you, and support grants free credits or an extra month. Every credit you hand out runs on compute, API calls and storage you pay for, on an account that's already been paid back.
• Access that never got revoked. If your REFUND handling failed, the refunded customer keeps generating usage. A lookup that shows a revocationDate while your database still says active is a bug report with a price tag.
• Wrong account, wrong fix. Restoring or crediting the account behind a forwarded email, when the order ID belongs to someone else, gives paid service to a person who never bought it.

None of these needs a dispute or a deadline to hurt. They're just support replies made without facts. One API call per ticket removes the guessing.

Does revocationReason 1 mean I did something wrong?

Not necessarily. Apple says reason 1 means it refunded the purchase due to an actual or perceived issue within your app. Perceived is doing a lot of work there. But a cluster of reason 1 refunds on one product, after one release, is the clearest product feedback Apple gives you. Count them.

How Google Play's order ID compares

Google Play works the other way round. Google's billing documentation says users receive an email with a unique order ID for each one-time product purchase, for the initial subscription purchase, and for each recurring renewal, and that you can use the order ID to manage refunds in Play Console. You search Order management by order ID or the user's full email address, then refund it yourself.

On Google Play, the order ID matters more because you're the one pressing the button. Play Console says refunding the most recent subscription order removes the subscription immediately and cancels future renewals, while refunding an older order is refund only and leaves the subscription active. Partial refunds are only supported for orders placed after March 2018, and you can't partially refund a paid app.

Put the order ID at the front of your refund support flow

• Ask for the order ID in your support form, with a one-line hint: it's in the Apple or Google Play receipt email.
• On iOS, call Look Up Order ID, decode every transaction, and show support the productId, purchaseDate, revocationDate and revocationReason on one screen.
• If OrderLookupStatus is 1, stop and ask for the right receipt. Grant nothing.
• If revocationDate is set, confirm access is already revoked on your server, then close the ticket. No goodwill on top.
• If it isn't set and the customer wants their money back, send them to reportaproblem.apple.com and keep your CONSUMPTION_REQUEST handler ready for the 12-hour window. RefundHalt answers that request with the consumption data Apple asks for.
• On Android, find the exact order in Play Console before you refund, and decide between refund only and refund and revoke on purpose.