Devoria
Reemborsament App Store: què veu el desenvolupador
Per Mehdi Azizi
Publicat el , 8 min
Reemborsament App Store: decideix Apple. El desenvolupador rep CONSUMPTION_REQUEST, pot respondre en 12 h i coneix la decisió per REFUND.
A l'App Store, és Apple qui concedeix o denega un reemborsament, mai el desenvolupador. El client fa la sol·licitud al web d'Apple o des de la teva app. Si has connectat les notificacions de servidor d'Apple, reps una notificació CONSUMPTION_REQUEST en el moment de la sol·licitud, i després REFUND o REFUND_DECLINED quan hi ha decisió. Entremig, tens 12 hores per enviar dades de consum i la teva preferència, sempre que el client hi hagi donat el consentiment.
Un reemborsament concedit treu la compra dels drets actius del client i apareix en negatiu als teus informes de vendes. Aquesta guia detalla cada pas, què pots enviar a Apple i què tens dret a fer contra les sol·licituds abusives. Les regles surten de les pàgines d'Apple revisades el 3 de novembre de 2026. El cas real surt d'una alerta que vaig connectar a les meves apps a l'octubre.
Qui decideix un reemborsament a l'App Store?
Apple, i només Apple. La pàgina d'assistència d'Apple descriu el recorregut del client: entra a reportaproblem.apple.com, tria «Request a refund», indica un motiu i després la compra afectada. Apple li recomana esperar de 24 a 48 hores per tenir resposta.
El client també pot demanar un reemborsament des de la teva app. Per a això, StoreKit ofereix un full de sol·licitud, disponible des d'iOS 15. Apple recomana obrir-lo des dels ajustos del compte o d'un menú d'ajuda. Mostra la compra i una llista de motius, i Apple triga fins a 48 hores a decidir.
En tots dos casos, tu no has de validar res. Només pots donar informació i una preferència, que compten entre diversos criteris en la decisió d'Apple.
Què veu cadascú, pas a pas
| Pas | Costat del client | Costat del desenvolupador |
|---|---|---|
| Sol·licitud | Formulari d'Apple o full dins l'app | Notificació CONSUMPTION_REQUEST |
| En les 12 hores | Espera | Possibilitat d'enviar les dades de consum |
| En 48 hores | Resposta d'Apple | Notificació REFUND o REFUND_DECLINED |
| Després d'una concessió | Diners retornats al seu mitjà de pagament | Compra retirada dels drets actius, unitats negatives |
| Després d'una impugnació | Reemborsament anul·lat per Apple | Notificació REFUND_REVERSED, accés a restablir |
App Store Connect només et mostra els reemborsaments ja concedits, a Sales and Trends. La sol·licitud en si només arriba per les notificacions de servidor. Sense elles, descobreixes el reemborsament a posteriori.
Les notificacions de servidor d'un reemborsament
Les App Store Server Notifications V2 envien cinc tipus útils aquí. Les reps a l'adreça HTTPS declarada a App Store Connect, una per a producció i una per a sandbox.
| Notificació | Què anuncia | Què fas |
|---|---|---|
CONSUMPTION_REQUEST | El client demana un reemborsament | Respondre en 12 hores, si hi ha consentiment |
REFUND | Apple ha reemborsat la transacció | Retirar el contingut o l'accés reemborsat |
REFUND_DECLINED | Apple ha denegat la sol·licitud | Res, l'accés continua |
REFUND_REVERSED | Apple anul·la un reemborsament després d'una impugnació del client | Restablir el que havies retirat |
REVOKE | Una compra compartida amb En família ja no està disponible | Retirar l'accés al membre de la família |
El teu servidor ha de respondre amb un codi HTTP entre 200 i 206. Segons la pàgina sobre les respostes a les notificacions, si no, Apple ho torna a provar cinc vegades, 1, 12, 24, 48 i 72 hores després de l'intent anterior. A sandbox, només l'envia una vegada.
La Consumption API: què pots dir a Apple
Quan arriba la sol·licitud, pots respondre amb Send Consumption Information. La regla cap en una frase d'Apple: «Respond within 12 hours of receiving the CONSUMPTION_REQUEST notification.» La versió 2 de l'API val per a tots els tipus de productes, subscripcions incloses.
Els camps de la petició:
| Camp | Obligatori | Què li diu a Apple |
|---|---|---|
customerConsented | Sí | El client ha consentit compartir les seves dades |
deliveryStatus | Sí | La compra s'ha lliurat i funciona, o per què no s'ha lliurat |
sampleContentProvided | Sí | S'oferia una prova, un fragment o una descripció abans de la compra |
consumptionPercentage | No | La part consumida, de 0 a 100.000 per a 0 a 100 % |
refundPreference | No | La teva preferència: DECLINE, GRANT_FULL o GRANT_PRORATED |
Dos detalls importen. Si deliveryStatus no és DELIVERED, la part consumida ha de valer zero. I per a un reemborsament proporcional d'una subscripció, omets la part consumida: la calcula Apple.
El consentiment és la condició de tot. Apple escriu: «You must obtain valid consent from the customer before sharing their personal data with Apple in the Send Consumption Information API.» Sense consentiment, no respons. Apple també prohibeix fer servir la finestra de seguiment publicitari per obtenir aquest consentiment: «Don't use the AppTrackingTransparency prompt to obtain consent».
Si fas servir RevenueCat
Amb RevenueCat, és ell qui rep les notificacions d'Apple i respon a la sol·licitud, amb Refund Control. Tries una política entre quatre: preferir un reemborsament complet, preferir una denegació, enviar només les dades de consum o no respondre.
Activar la compartició de dades equival a confirmar que tens el consentiment dels teus clients. Ho diu el mateix RevenueCat: «Enabling consumption data sharing confirms that you obtained consent from your Customers.» També recomana reservar «Prefer no refund» per a un grup concret, i avisa quan aquesta preferència afecta la majoria dels teus clients.
Per rebre també les notificacions al teu propi servidor, RevenueCat ofereix un camp «Apple Server Notification Forwarding URL» als ajustos de l'app. Està descrit a la seva pàgina sobre les notificacions d'Apple. És el que faig servir jo. Com muntar una subscripció amb RevenueCat ho tens a RevenueCat i la subscripció in-app a iOS.
L'efecte en els teus ingressos i en la subscripció
En l'accés. Segons la documentació de currentEntitlements, «Products that the App Store has refunded or revoked don't appear in the current entitlements». Si la teva app comprova els drets amb currentEntitlements, l'accés reemborsat desapareix sol. La transacció porta la data i el motiu de la retirada, a revocationDate i revocationReason.
En els informes. Segons l'ajuda de l'informe de vendes, un reemborsament apareix amb unitats i preu de client negatius. Per a les subscripcions, la pàgina sobre les dades de subscripció compta els reemborsaments complets i parcials entre els esdeveniments, i els resta de les unitats diàries.
En la teva reputació. La guideline 5.6.4 cita les sol·licituds de reemborsament excessives entre els senyals d'una qualitat insuficient. Una taxa de reemborsament alta no és només una pèrdua de diners: Apple la pot tenir en compte per valorar si respectes el codi de conducta.
El meu cas: l'alerta connectada a les meves apps
El 12 d'octubre de 2026 vaig connectar una alerta a les meves apps. RevenueCat transmet les notificacions d'Apple a una ruta de devoria.fr. Aquesta verifica la signatura d'Apple i m'envia una alerta, sense import. Volia veure la sol·licitud en el moment que arriba, no només el resultat.
El 18 d'octubre va arribar la primera sol·licitud de debò a TradaZen, el meu simulador de trading. Una subscripció anual, pagada al final d'una prova gratuïta de 7 dies. Motiu indicat: una compra involuntària. Tres lliçons:
- La mateixa sol·licitud pot arribar diverses vegades. Vaig rebre tres vegades la mateixa alerta el mateix vespre. Des d'aleshores, cada alerta es deduplica pel tipus de notificació i l'identificador de transacció.
- La decisió va arribar en menys d'un dia. Apple la va denegar unes 22 hores després de la sol·licitud. El client va conservar l'accés.
- Una denegació no és el final. El mateix client va tornar a fer una sol·licitud dos dies després, sobre la mateixa transacció.
Una sol·licitud per «compra involuntària» al final d'una prova no es guanya en la resposta a Apple. Es prevé al paywall, abans del primer pagament.
Limitar les sol·licituds abusives sense infringir les regles
El que està permès:
- Respondre cada sol·licitud amb dades exactes, quan el client ha donat el consentiment.
- Expressar una preferència concreta, per exemple una denegació per a una compra ja consumida, en lloc d'una denegació per a tothom.
- Vincular cada
REFUNDa un compte de client. La pàgina d'Apple sobre les notificacions de reemborsament ho recomana per detectar reemborsaments repetits. - Dir clarament què es compra abans de la compra. La guideline 3.1.2(c) demana descriure què obté l'usuari pel preu, abans de proposar-li que se subscrigui.
El que està prohibit:
- Enviar dades falses perquè es denegui una sol·licitud, o respondre sense consentiment.
- Obtenir el consentiment amb la finestra de seguiment publicitari, cosa que Apple exclou explícitament.
- Fer trampa en la compra. La guideline 5.6 prohibeix empènyer els clients a compres no volgudes o cobrar el que no es lliura.
- Pressionar un client que demana un reemborsament. La mateixa regla exigeix respecte en l'atenció al client, sense intimidació.
La millor palanca continua sent abans: un paywall que digui el preu, la data del primer pagament i com cancel·lar. Els errors que cal evitar són a els errors de paywall, i les regles de la prova a la prova gratuïta a l'App Store.
Provar abans de producció
Segons la pàgina sobre la prova de sol·licituds, la sandbox i les proves StoreKit d'Xcode accepten sol·licituds de reemborsament. A sandbox, qualsevol motiu provoca una concessió automàtica. Per simular una denegació, tria «Other» i escriu DECLINE. Per a un reemborsament proporcional, escriu GRANT_PRORATED. A sandbox, la teva resposta de consum ha de sortir en cinc minuts.
Una subscripció que es reemborsa menys
L'iOS & Android Kit parteix del codi de les meves apps, amb l'onboarding, el paywall i les subscripcions ja programats, i segueix quatre etapes fins a l'App Store, al teu ritme. El muntatge complet està detallat a la pàgina subscripció in-app a iOS, i les regles d'Apple sobre la subscripció a la guideline 3.1.2.
Abans de llançar el teu paywall, fes el teu diagnòstic gratuït: et diu què bloqueja de veritat el teu projecte i t'envia la meva checklist antirebuig d'Apple.
Preguntes freqüents
El desenvolupador pot denegar un reemborsament a l'App Store?
No. Decideix només Apple. Pots enviar dades de consum i una preferència, DECLINE per exemple, que compten entre diversos criteris. Apple té l'última paraula.
El desenvolupador rep avís d'una sol·licitud de reemborsament?
Sí, si ha connectat les App Store Server Notifications V2. Apple envia CONSUMPTION_REQUEST en el moment de la sol·licitud, i després REFUND o REFUND_DECLINED quan decideix. Sense notificacions, només veus els reemborsaments concedits, als teus informes.
Quant triga Apple a tramitar una sol·licitud de reemborsament?
Apple anuncia al client de 24 a 48 hores. La documentació de StoreKit parla de 48 hores com a màxim. Per part teva, tens 12 hores per enviar les dades de consum.
Què passa amb l'accés després d'un reemborsament?
La compra reemborsada surt dels drets actius del client: StoreKit 2 ja no la retorna a currentEntitlements. Si després Apple anul·la el reemborsament, reps REFUND_REVERSED i has de restablir l'accés.
Cal el consentiment del client per respondre a Apple?
Sí. Apple exigeix un consentiment vàlid abans de compartir qualsevol dada per la Consumption API. Sense ell, no respons a la notificació. La finestra de seguiment publicitari no es pot fer servir per obtenir-lo.
Els reemborsaments compten en contra de la meva app?
Poden comptar. La guideline 5.6.4 cita les sol·licituds de reemborsament excessives entre els senyals d'una qualitat insuficient, que Apple pot tenir en compte per valorar el respecte del codi de conducta.
