Transfer an app to another developer account and the orders placed before the sale stay with the seller, here's what that means for refunds

Google's help page says it in one line: orders created before an app is transferred remain in the original account. So when you transfer an app to another developer account, the subscribers move to the buyer but the purchase history doesn't. The refunds, disputes and support tickets tied to that history don't sort themselves out. They land on whoever the store's rules point to, which isn't always the party that got paid. Apple and Google handle this differently, and Apple says less than Google does. Here's what each store documents, which parts of your refund setup quietly stop working after a transfer, and what to put in writing before either side signs.

What moves and what stays when you transfer an app

Both stores treat a transfer as a change of owner going forward. The app, its users and its ratings move. The financial record of the past mostly doesn't.

On the App Store

Apple's rule is about data. The transferring developer keeps access to payment and sales information from before the transfer and loses access to everything after it. The recipient only receives payment and sales information for transactions that occur after the transfer. Apple's transfer guide doesn't address refunds of purchases made before the transfer. It says nothing about whose proceeds a late refund comes out of.

On Google Play

Google is more explicit. Users, statistics, data, comments, ratings and subscriptions transfer. Orders created before the transfer stay in the original account, and if one of them needs a refund, Google says you must go back to the original account or use the Google Play Developer API. The seller's account doesn't stop mattering on the day of the sale. It stays the only place some refunds can be issued.

Who issues a refund after an app transfer

Most refunds on both stores are decided without any developer. Apple handles refund requests itself. On Google Play, buyers can refund many purchases themselves within 48 hours, and Google support grants others. A transfer doesn't change any of that. What it changes is who can see the refund and who can act on the rare flows that ask for a developer.

A refund you want to give on Google Play

Say a long-time subscriber writes to the new owner asking for their money back on a charge from two months before the sale. The new owner can't refund it from their own Play Console, because the order isn't there. The seller has to log in and do it, or someone with API access to the seller's account has to call the Google Play Developer API. If the seller has closed the account or stopped answering, that refund is stuck. Google even offers to refund the seller's $25 registration fee if they close the original account after a transfer, which is exactly why the buyer should make sure pre-transfer refunds are handled before that happens.

A refund Apple grants on its own

On the App Store, you don't issue refunds, Apple does. When Apple refunds a pre-transfer purchase, the payment and sales record for it sits with the original developer. Apple's transfer documentation doesn't say which party's proceeds carry that refund, so neither side should assume. Write it into the agreement.

The two refund flows that ask for evidence

Only two refund flows ask a developer for anything. Apple sends a CONSUMPTION_REQUEST and gives you 12 hours to answer with consumption data through Send Consumption Information. Google Play sends a chargeback review, and you have 24 hours to answer through orders.reviewrefund. Both answers are signed with credentials that belong to an account, not to the app. That's where transfers break.

The refund plumbing that breaks during a transfer

A transferred app can keep selling for weeks while nobody notices that the refund side has gone dark.

Apple's notification URL and In-App Purchase key

The App Store Server Notifications URL is set per app, under App information in App Store Connect. Apple's transfer guide doesn't mention it, so the new owner should open that screen on day one and point production and sandbox at their own server. If it still names the seller's endpoint, every CONSUMPTION_REQUEST for the app lands on a server the buyer doesn't run, and the 12 hours pass in silence.

Responses go through the App Store Server API, which needs an In-App Purchase key. Those keys are generated under Users and Access by an Account Holder or Admin, and Apple lets you download each one only once. The seller's key lives in the seller's account. The buyer should generate their own, and the seller should revoke theirs once the handover is done.

Apple's shared secret and webhooks

For apps with auto-renewable subscriptions, Apple tells the seller to generate an app-specific shared secret before the transfer and share it with the recipient, who uses it to verify subscriptions. Once the transfer completes, the recipient should generate a new one so people outside their organization no longer have it. App Store Connect webhooks also transfer to the recipient, and Apple suggests the seller delete them first if they don't want events delivered to their server afterward.

Google's permissions and Cloud project

Google says permissions and linkage settings for integrated services don't transfer. It tells the seller to add the target account as an Owner of any Google Developers Console projects the app uses. On Play, that's where your real-time developer notifications topic and the service account behind your Developer API calls usually live. If the service account isn't granted access in the buyer's Play Console, voided purchase checks fail and an orders.reviewrefund answer can't be sent inside its 24 hours.

What a transfer costs in refunds and chargebacks

The mechanics above turn into money in three places.

You serve users who paid the seller

Take a subscriber who bought a $59.99 annual plan a month before the sale. On Google Play, that order sits in the seller's account. On the App Store, its payment record stays with the seller. The buyer gets no payment for it and still runs the compute, the third-party API calls and the storage that subscriber uses for the rest of the year. If that subscriber later asks the buyer for a refund, the buyer can't issue it on Google Play without the seller. Count those prepaid subscriptions at signing, because they're a cost the buyer takes on with no revenue attached.

Chargebacks on orders the buyer never sold

For Google Play orders placed after August 3, 2026, the developer is responsible for a chargeback's purchase price, less Play's service fee, plus the bank's chargeback fee. A chargeback is bank-final once it's decided. Google's transfer page doesn't say how that cost is handled for an order that stayed in the seller's account. Until Google says, a sale contract should say who pays a chargeback on a pre-transfer order, and who answers its chargeback review.

The 15% tier counts the same earnings twice

Google Play's 15% service fee applies to a developer's first $1 million in earnings each year. When an app moves between developer accounts in separate Account Groups, all of the app's earnings for that calendar year are included in both groups' totals. Google's own example is an app that earned $100,000 in Account Group A and moves to Account Group B. That $100,000 counts toward both groups' first $1 million. A buyer close to the threshold can hit the standard rate sooner than their own sales suggest.

What to settle before you transfer an app

For the seller

• Download the reports you'll need. Google's bulk export, estimated sales and earnings reports don't transfer, and Apple's recipient won't see your history.
• Keep the original account open and reachable until pre-transfer refunds and disputes have run their course.
• Generate and share the app-specific shared secret before an App Store transfer, then revoke your In-App Purchase key and delete webhooks you don't want firing afterward.

For the buyer

• Set your own App Store Server Notifications URL and generate your own In-App Purchase key on day one.
• Grant your service account access in your Play Console and confirm real-time developer notifications arrive at your endpoint.
• Get a list of prepaid subscriptions and recent large purchases, so you know what you'll be serving without revenue.
• Put pre-transfer refunds, chargebacks and chargeback reviews in the sale agreement, with a named contact on the seller's side.

RefundHalt connects to each app with credentials from the account that owns it. After a transfer, connect the app from the new owner's account, and consumption requests and chargeback reviews route to the new owner from then on.