App Store sale notification: know the moment someone buys your app

How to find out someone bought your app: the short answer

There are four honest ways to learn that someone bought your app, and they are not equally fast. The one most founders reach for — App Store Connect's Sales and Trends dashboard — is the slowest, because it lags a day or more and reports proceeds monthly. The three faster routes all use a signal Apple already emits in near-real-time: StoreKit 2 transactions in your app, App Store Server Notifications v2 to your server, and a DIY endpoint you build to catch those and ping you. Any of them will tell you, within moments, that a purchase happened.

So this guide is careful to be accurate about Apple: the internet is full of the claim that "Apple gives you nothing real-time," which is simply not true. The Connect dashboard is delayed; the purchase signal is not. But it is also honest about the one thing every route stops short of. Each is triggered by a transaction, so each can only ever tell you about the transaction — not who that was, or whether they are a brand-new customer or someone resubscribing. That gap, and how an identity-joined alert closes it, is the back half of the article. It is the same argument we make for the other rail in the Stripe sale notification guide; here it is pointed at Apple.

App Store Connect: the report you keep refreshing

Start with the honest truth about the dashboard, because it is the frustration that brought most people to this search. App Store Connect's Sales and Trends is where you go to see downloads and revenue, and it is accurate. It is also delayed: sales data typically shows up around a day after the fact — sometimes longer — and your actual proceeds are reported on a monthly cycle. If you shipped something this morning and want to know whether it is selling this afternoon, the dashboard is the wrong instrument. It is a ledger you reconcile, not a feed you watch.

It is worth stating this carefully, without the usual Apple-bashing, because the nuance is the whole point. The delay is a property of the reporting dashboard, not of Apple's platform as a whole. Apple finalises reported figures on a schedule for good reasons — reconciliation, refunds, currency, tax — the way any global marketplace closes its books. That simply means Sales and Trends answers "how did last period go" far better than "did I just make a sale." For the second question you want a different signal — and Apple already emits one. We go deeper on living with the reporting delay in seeing app revenue in real time before App Store Connect catches up.

StoreKit 2: the signal already in your own code

The earliest place a purchase becomes knowable is inside your own app. With StoreKit 2, when a customer completes a buy, your app receives a verified Transaction right then — on device, the moment it happens, cryptographically signed so you can check it is genuine. This is the signal you use to actually deliver the goods — grant the content, mark the subscription active — and it is real-time by construction.

The reason StoreKit alone is not a complete answer to "notify me of sales" is where the signal lives. A StoreKit transaction fires on the buyer's device — exactly right for granting access, but awkward as a notification source: you would be relying on the client to phone home, and a purchase that completes while your backend is unaware is a familiar source of grief. That is why serious setups pair the on-device transaction with a server-side confirmation, so the sale is known to your systems, not just to one phone. Handling and verifying those transactions well, without standing up a full billing backend, is its own topic; we cover it in validating App Store purchases without building subscription infrastructure and, for the analytics angle, in StoreKit 2 subscription analytics.

Server Notifications v2: Apple's real-time hook

Here is the piece most "Apple is a black box" complaints miss. Apple provides a proper, near-real-time, server-to-server signal: App Store Server Notifications v2. You configure a URL in App Store Connect, and from then on Apple posts a signed message to that endpoint whenever something happens against a transaction — an initial purchase, a renewal, a failed renewal, a refund, a cancellation. It arrives within moments, and because it is signed, you can verify it genuinely came from Apple rather than trust a client.

This is the real-time hook to build on. It is server-side, so it does not depend on a device checking in; it covers the whole subscription lifecycle, not just the first buy; and it is the same class of signal a payment processor's webhook gives you on the card rail. If you want to understand the notification types and how to consume them, we wrote a founder-level walkthrough: App Store Server Notifications v2, explained for founders. For this guide, the important thing is what the notification is and is not. It is a fast, trustworthy purchase event — not a customer view. It tells you a transaction changed state, not who the buyer is across your other rails, which plan they hold in your own terms, or what they have paid you to date. Those answers live in layers the notification never touches.

The DIY endpoint: build it yourself

Given that Apple sends the notification, the obvious move is to catch it yourself. Stand up a small endpoint, point App Store Server Notifications v2 at it, verify the signature, and have it push you a message — into Slack, email, or your phone — whenever a purchase lands. Plenty of teams do exactly this, and for a solo developer who just wants a buzz on the first sale, it is a reasonable afternoon's work.

Be clear-eyed about what you are signing up for, though, because the endpoint is the easy 20%. To keep it trustworthy you have to verify Apple's signatures, handle every notification type and subtype, deal with retries and out-of-order delivery, and reconcile against the App Store Server API when you need fuller history. And when you are done, you have a reliable pipe that still only carries a purchase event. The DIY route gets Apple's real-time signal into a channel you like; it does not, by itself, get you the customer behind the sale — the same instinct that makes a raw error log frustrating, which we wrote about in what plain-English summaries are and why founders need them.

Every route to an App Store sale notification, compared

Here is the honest comparison of the routes above. The columns move together until the last one — because they are all reading the same transaction layer, just at different speeds and in different places.

The first four rows are the right answer to "how do I know when someone buys my app." If that is all you needed — a fast, trustworthy heads-up that a sale happened — pick the route that matches your appetite for building and set it up. The last row is a different kind of answer, because it is built on a different layer, and the rest of this guide is about why that last column matters the day a bare purchase event stops being enough.

The wall: a purchase event says "new subscription" and nothing else

Here is the moment every growing app hits. A notification fires. It says, in effect, new subscription — Pro, $9.99. And your very next thought is a question the event cannot answer: who was that? A brand-new customer, or someone who churned in March and just resubscribed? Is "Pro" the monthly or the annual? What have they paid you before across every rail — someone worth $9.99, or someone worth $214 who just came back? The purchase event is silent on all of it, and it is silent for a structural reason worth understanding.

A transaction is a single-layer fact. A product identifier, a price, a timestamp, a signed confirmation that it is real. That is the entire content of the event — whether it reaches you through StoreKit, through Server Notifications v2, or through the DIY endpoint you built to catch them. Everything you actually want to know lives in other layers: which plan the product maps to lives in your entitlements; whether this is a new or returning buyer lives in your customer records; the lifetime value lives in your revenue history, across every rail; the past errors live in your error monitoring. Apple's signal is genuinely real-time, but it has no join to those layers, so it reports the purchase and only the purchase. The signal is not underbuilt — it describes one event, and the answer lives across several.

This is the same shape of problem behind a lot of "why can't my tools just tell me" frustration — revenue on one rail, customers in another system, errors in a third, no thread connecting them. We wrote about the broader version in the complete guide to app revenue intelligence, and the whole real-time cluster starts at the hub, real-time business monitoring. The sale alert is where the gap gets personal — the moment you have a name-shaped hole in front of you and nothing to fill it with.

An alert that names the customer, their plan, and their value

The fix is not another notification channel, and it is not asking Apple to speed up a report it finalises for good reasons. It is a different foundation under the alert. Crossdeck ingests and verifies Apple's own signal — StoreKit 2 transactions and Server Notifications v2 — and joins the verified purchase to the customer by identity, the cross-match, so the sale lands on that customer's one timeline across Apple, Google Play and Stripe. The transaction becomes one event on a person's history — and because that history is right there, the alert carries what a raw purchase event never could.

Concretely, instead of "new subscription — Pro, $9.99," an identity-joined alert reads more like: New App Store subscription — $9.99. Alex (returning customer) started Pro (annual) after churning in March. Lifetime value now $214. No open errors. Every field comes from a different layer, joined to one identity: the amount and product from the Apple rail, the plan from entitlements, "returning customer" and the lifetime value from revenue history, the error status from error monitoring. None of it is estimated — every figure is read from your live Crossdeck data. (The name and numbers are illustrative; the shape of the alert is the real thing.)

Two points of accuracy, because they matter. First, this arrives before App Store Connect's Sales and Trends would show the sale — not because Crossdeck outruns Apple, but because it reads the real-time signal Apple already emits, which the reporting dashboard lags behind. Second, none of this touches Apple's payouts: your proceeds still land on Apple's schedule. What changes is your awareness — that when the sale surfaces, it surfaces with the customer attached. It is the same instinct behind knowing when a paying customer hit a checkout error.

The last row is the whole argument. A raw purchase event is built on the transaction, so it can only ever show you the transaction — however fast and however well-verified it arrives. An identity-joined alert is built on the customer, so the sale arrives with its context attached. Same trigger — a verified App Store purchase — but a different foundation, and a completely different alert.

Ask a follow-up: "is this a new install or a resubscribe?"

There is one more thing an identity-joined alert can do that a purchase event structurally cannot: hold a conversation. With a StoreKit hook, a Server Notification, or your own DIY ping, the message is the end of the exchange. Crossdeck delivers its sale alerts through a Telegram bot, live today in a private chat with you, and the chat is two-way.

When a sale lands, you can do more than read it. You can open a Mini App dashboard for the fuller picture — Home, Revenue, Errors and People, with a project switcher if you ship more than one app — or run hard-data commands right in the chat: /revenue for this month's recognised revenue, /people for latest customers, /status for a health check. And if you want to just ask, that is what Prism is for: with /prism you type a plain-English question — "is this a new install or a resubscribe?", "what has this customer paid us across Apple and web?" — and get an answer off your live numbers.

Two things matter about how Prism works, and both are the point. First, it runs on your own connected AI model, with your own key — you connect a model in the Prism tab first, and from then on the questions are answered by your model, not by anything Crossdeck runs on your data. Crossdeck never trains on your data; the model and the key are yours. Second, the answer is grounded in your live Crossdeck data — not a guess or a generic estimate, but your real history, read at the moment you ask. You can see how that works on the Prism page. A sale alert you can interrogate is a different tool than one you can only read.

One honest note on scope: today the bot runs in your private chat, one-to-one. Shared team and group chats — where your whole team gets the alerts and asks Prism together — are on the roadmap, not shipped. For now, think of it as your own line to your numbers, not a team channel yet.

How to choose

None of this means ripping out what works. The right choice depends on what you want the alert to do — and for many teams the answer is more than one thing.

• If you just want the period totals: App Store Connect's Sales and Trends is the system of record. Read it as the ledger it is, a day or more behind.
• If you want to grant access the instant a buy completes: handle the StoreKit 2 transaction on device — that is what it is for, and it is already in your code.
• If you want a fast, trustworthy server-side signal: consume App Store Server Notifications v2, or build an endpoint to catch them. This is Apple's own real-time hook.
• If you want the alert to answer the next question — who, which plan, worth how much: you need an alert built on the customer's identity, not the transaction. That is the join Crossdeck makes on top of Apple's verified signal, delivered to Telegram, with a follow-up you can ask.

The test is simple. Read your next purchase notification and notice your very next thought. If it is "good," a raw purchase event is doing its job. If it is "wait — who was that?", that is the moment an identity-joined alert earns its place. This post is part of a wider set on watching your business in real time — the hub is real-time business monitoring, and the closest neighbour is the same idea on the card rail, the Stripe sale notification.

If you want to see the alert with the customer attached rather than described, start free or look at how the cross-match works on cross-deck.com.

Frequently asked questions