Come ridurre le commissioni degli app store con gli acquisti in-app

Reindirizza il checkout dall’app al web in modo conforme

Collegamento a un browser esterno: gli sviluppatori che usano una WebView nell’app difficilmente supereranno la revisione dell’iOS App Store. Reindirizza invece a un browser esterno per mantenere la conformità.

Verifica il paese di distribuzione: Apple supporta attualmente solo Giappone, Corea del Sud, UE e Stati Uniti. Presta attenzione alla tua area geografica.

Usa una soluzione preconfigurata per garantire la conformità: oltre alle linee guida Apple, occorre rispettare le normative governative, bancarie e dei circuiti di pagamento applicabili. Queste includono standard di sicurezza come PCI, norme sulla privacy come il GDPR dell’UE e il CCPA della California, nonché le informative richieste da banche e società di carte. Possiamo fornire indicazioni al riguardo.

Quando si possono utilizzare pagamenti esterni

Apple consente alle app idonee dell’App Store statunitense di indirizzare gli utenti fuori dall’app per acquistare contenuti o servizi digitali in situazioni specifiche. Giochi, adesioni, abbonamenti, beni virtuali e contenuti digitali possono così offrire un’alternativa agli acquisti in-app di Apple (IAP).

Secondo le linee guida App Review di Apple 3.1.1 e 3.1.1(a), le app dello store statunitense possono includere pulsanti, link esterni o altri inviti all’azione che indirizzano a meccanismi diversi da IAP per acquistare contenuti o servizi digitali.

• Oggetti di gioco, valuta virtuale, livelli e contenuti virtuali
• Adesioni e abbonamenti
• Contenuti e servizi digitali
• App che desiderano un checkout Web/H5 di terze parti per gli acquisti esterni

Le regole attuali di Apple non richiedono lo StoreKit External Purchase Link Entitlement per mostrare pulsanti, link o inviti ad acquisti esterni nello store statunitense. Prima del lancio, l’esercente deve confermare l’applicabilità del modello di business, categoria dell’app, tipo di prodotto e ultime regole di revisione Apple al proprio caso.

Il pagamento esterno non è solo un link

Aggiungere un accesso al pagamento esterno sembra semplice, ma un checkout affidabile richiede più di un reindirizzamento. Occorre gestire ordini, conferma del pagamento, erogazione di prodotti o diritti, verifica delle notifiche, rimborsi, eccezioni e riconciliazione.

Quando l’utente torna dal checkout web, l’app non deve affidarsi soltanto al risultato del client. I parametri di ritorno migliorano l’esperienza, ma non provano il pagamento. Il risultato definitivo deve provenire dalle notifiche del server WooshPay o dalla risposta alla consultazione dell’ordine.

Come WooshPay supporta il checkout esterno

WooshPay offre un checkout mobile Web/H5 che riceve utenti dall’accesso agli acquisti esterni nell’app e li guida al pagamento nel browser.

• Creazione di sessioni di pagamento
• Visualizzazione di esercente, prodotto, importo, valuta e scadenza dell’ordine
• Metodi diffusi negli Stati Uniti, come carte di credito e debito, e wallet secondo l’idoneità del business
• Stati di pagamento riuscito, fallito, in attesa, chiuso e relativi ai rimborsi
• Notifiche del risultato del pagamento dal server
• Consultazione degli ordini, rimborsi, riconciliazione e report delle transazioni
• Verifica delle firme, controlli del rischio, limiti, prevenzione delle frodi, test sandbox e verifiche di lancio

Flusso di pagamento consigliato

Quando l’utente tocca l’accesso esterno nell’app, l’esercente crea un ordine con ID univoco. Il server fissa prodotto, importo, valuta, ID utente, canale e scadenza e crea una sessione di pagamento WooshPay.

L’utente paga nel checkout Web/H5 di WooshPay. Quando lo stato cambia, WooshPay notifica il notify_url dell’esercente. Il server verifica firma, ID ordine, importo, valuta e ID esercente prima di assegnare il diritto digitale.

Al ritorno nell’app, consultare lo stato dell’ordine sul server dell’esercente anziché fidarsi dei parametri di reindirizzamento del client.

Cosa deve preparare l’esercente

• Configurare un accesso chiaro agli acquisti esterni nell’app
• Spiegare chiaramente che l’utente passerà a una pagina web o checkout sicuro per completare l’acquisto
• Creare ordini con ID esercente globalmente univoci
• Fissare prodotto, importo, valuta, ID utente, canale e scadenza
• Supportare stati come in attesa di pagamento, in elaborazione, riuscito, fallito, chiuso e rimborsato
• Configurare notify_url per notifiche di pagamento, rimborso e chiusura ordine
• Verificare firme, ID ordini, importi, valute e ID esercenti delle notifiche
• Gestire le notifiche in modo idempotente per evitare erogazioni duplicate
• Erogare adesioni, abbonamenti, valuta virtuale, oggetti o altri diritti digitali solo dopo la conferma del server
• Gestire notifiche e pagamenti duplicati, ordini scaduti, rimborsi, storni e ordini anomali

Non occorre segnalare ad Apple i pagamenti di terze parti

Per lo scenario statunitense descritto nel documento originale, l’esercente non deve segnalare ad Apple le transazioni di terze parti. Deve comunque conservare registri completi di transazioni, rimborsi, riconciliazione, rischi e assistenza per le proprie esigenze operative e finanziarie.

Un checkout più flessibile per gli utenti dell’App Store statunitense

I pagamenti esterni offrono un altro percorso di acquisto alle app di contenuti e servizi digitali negli Stati Uniti. WooshPay collega gli accessi nell’app al checkout Web/H5, mantenendo pagamento, erogazione, rimborsi e riconciliazione sotto controllo del server.

WooshPay riduce la complessità di integrazione, migliora la gestione degli stati e trasforma i link di acquisto esterni in un checkout affidabile, verificabile e scalabile.

In Giappone l’acquisto esterno non è solo un link di pagamento

Apple consente alle app iOS idonee in Giappone di usare acquisti esterni in situazioni specifiche. Gli editori possono mantenere Apple IAP disponibile e offrire anche il pagamento nel browser predefinito del dispositivo.

Non basta aggiungere un link di pagamento alla pagina prodotto. Occorre gestire entitlement Apple, idoneità regionale e del dispositivo, pari evidenza per IAP, Apple Disclosure, browser predefinito, ritorno tramite Universal Link, erogazione sul server e obblighi di segnalazione ad Apple.

WooshPay collega questi passaggi con SDK, Hosted Checkout e servizio di dati per giochi iOS, creando un percorso esterno pronto al lancio, verificabile e più facile da riconciliare.

Ambito di applicazione

• Utenti iPhone sullo store giapponese
• iOS 26.2 o successivo
• Giochi che hanno richiesto e configurato l’entitlement Apple pertinente per gli acquisti esterni
• Acquisti di prodotti digitali che richiedono un pagamento nel browser accanto ad Apple IAP
• Beni digitali di gioco, come oggetti, valuta virtuale, livelli e contenuti virtuali

Prima del lancio, confermare l’applicabilità secondo l’ultima documentazione Apple Developer, i requisiti di revisione, il modello di business e la strategia di pubblicazione.

Come WooshPay supporta l’intero flusso di acquisto

Quando il giocatore tocca l’accesso esterno nella pagina prodotto, WooshPay SDK esegue prima i controlli Apple a runtime. Se giocatore e contesto sono idonei, mostra Apple Disclosure e, dopo conferma, apre WooshPay Hosted Checkout nel browser predefinito.

Dopo il pagamento, il giocatore può tornare tramite Universal Link. Il client non deve erogare oggetti basandosi solo sull’URL di ritorno: il server del gioco deve consultare lo stato definitivo WooshPay o elaborarne il webhook prima dell’erogazione.

Funzionalità principali

1. Verifica dell’idoneità prima di ogni acquisto

Lo SDK deve eseguire canMakePayments e isEligible a ogni tentativo senza affidarsi solo a risultati memorizzati all’avvio. Restrizioni utente, store, versione iOS e stato dell’entitlement possono influire sul risultato.

2. Supporto per iOS 26.2/26.3 e iOS 26.4+

Gli acquisti esterni in Giappone sono supportati da iOS 26.2+. I percorsi dei token e delle segnalazioni differiscono tra iOS 26.2/26.3 e iOS 26.4+. WooshPay SDK può gestire entrambi mantenendo coerente l’esperienza del giocatore.

3. Gestione dei token LINK_OUT e creazione del registro

In iOS 26.4+, lo SDK ottiene un token LINK_OUT prima di ogni possibile transazione e lo invia a WooshPay Server prima del checkout. Il token collega tentativo di acquisto, sessione, stato della transazione e dati per Apple.

4. Apple Disclosure prima di aprire il browser

Apple Disclosure informa che l’utente lascia l’ambiente Apple per effettuare una transazione con lo sviluppatore o terzi. Lo SDK deve usare l’API Apple, non un’interfaccia personalizzata simile. Se il giocatore chiude o rifiuta l’avviso, restituire lo stato annullato senza aprire il browser.

5. Hosted Checkout nel browser predefinito

I link esterni devono aprire una pagina o scheda del browser predefinito, non WKWebView o altre pagine di pagamento incorporate nell’app. WooshPay Hosted Checkout gestisce metodi, rischi, stati, risultati e pulsante di ritorno al gioco.

L’erogazione deve basarsi sullo stato definitivo del server

Universal Link riporta il giocatore nell’app e trasmette dati di ordine consultabili, ma non prova il pagamento. return_url non deve contenere un parametro modificabile success=true che attivi direttamente l’erogazione.

Lo stato definitivo deve provenire da WooshPay Server. Si raccomanda di combinare notifiche webhook e consultazioni attive. Il server eroga adesioni, abbonamenti, valuta virtuale, oggetti e altri diritti solo quando l’ordine è SUCCESS e importo, valuta, ordine e identità del giocatore coincidono.

Cosa deve gestire lo sviluppatore del gioco

WooshPay integra pagamenti, apertura del browser e dati per le segnalazioni, ma lo sviluppatore deve completare attività essenziali di business e conformità. Idoneità Apple, pagine prodotto, ordini, erogazione e invio delle segnalazioni vanno implementati nel contesto della propria app, prodotti e account dei giocatori.

Configurazione Apple e App Store

• Confermare che app, tipo di prodotto, regione del giocatore e scenario rientrino nell’ambito Apple degli acquisti esterni in Giappone.
• Richiedere e configurare l’entitlement pertinente in Apple Developer o App Store Connect.
• Impostare jp come regione consentita nel file entitlements di Xcode e verificare che il pacchetto di produzione includa l’impostazione.
• Mantenere allineati bundle identifier, account Apple, ambiente di rilascio e app approvata.
• Consultare documentazione e linee guida Apple aggiornate prima del lancio per ridurre rischi di revisione dovuti a cambiamenti di policy.

Pagina prodotto e accesso all’acquisto

• Progettare l’accesso esterno sulla pagina prodotto, dettaglio dell’oggetto o ricarica e mostrarlo solo in situazioni idonee.
• Mantenere Apple IAP disponibile e almeno altrettanto evidente dell’opzione esterna per posizione, peso visivo, testo e orientamento.
• Spiegare chiaramente che il giocatore lascerà l’app per pagare nel browser o in un checkout sicuro.
• Evitare di suggerire che Apple elabori l’acquisto esterno e sconti, colori o layout che indirizzino chiaramente gli utenti lontano da IAP.
• Se canMakePayments o isEligible non riesce, nascondere o disabilitare l’accesso esterno oppure indirizzare a Apple IAP secondo la strategia del prodotto.

Integrazione client e ritorno nell’app

• Inizializzare WooshPay SDK all’avvio con merchantId, environment, returnUniversalLink e livello di log.
• Chiamare purchase solo quando il giocatore tocca attivamente l’accesso esterno; non avviare il flusso senza azione dell’utente.
• Configurare dominio Universal Link, file apple-app-site-association e Associated Domains.
• Gestire stati client: riuscito, in attesa, fallito, annullato, errore di apertura del browser e fallback Universal Link.
• Non salvare chiavi private Apple API, issuer ID, key ID o altre credenziali sensibili di segnalazione nel client.

Ordini ed erogazione sul server

• Creare merchant_order_id globalmente univoco e fissare prodotto, importo, valuta, giocatore, server, personaggio e scadenza.
• Integrare API server WooshPay per creare sessioni, consultare ordini, ricevere webhooks e rimborsare.
• Verificare firme webhook, ID ordini, importi, valute, identità del giocatore e protezione dai replay.
• Eseguire tutte le erogazioni sul server dell’esercente, con idempotenza tramite merchant_order_id o transaction_id.
• Definire regole per PENDING, FAILED, CANCELLED, EXPIRED e REFUNDED per evitare erogazioni premature o duplicate.
• Se il pagamento riesce senza ritorno nell’app, il webhook deve comunque attivare l’erogazione sul server; il giocatore vedrà il diritto aggiornato alla successiva consultazione dello stato.

Segnalazioni, riconciliazione e operazioni

• Ottenere payload o file di segnalazione per Apple tramite WooshPay Reporting API o Dashboard.
• Inviare segnalazioni ad Apple con credenziali/JWT propri dell’esercente, mantenendo responsabilità su tempestività e accuratezza.
• Creare verifiche, tentativi ripetuti e tracce di audit per transazioni riuscite, rimborsi, annullamenti, scadenze, token senza transazione e correzioni.
• Riconciliare pagamenti WooshPay, erogazioni del gioco, rimborsi e dati segnalati ad Apple nei processi finanziari.
• Preparare SOP di assistenza e operazioni per annullamenti, pagamenti in attesa, addebiti senza erogazione, pagamenti senza ritorno, rimborsi e ripristino dei diritti.

Dati di segnalazione ad Apple e limiti di responsabilità

I rischi di segnalazione in Giappone includono anche annullamenti, scadenze, pagamenti falliti, token senza transazione, rimborsi e correzioni. SDK e server devono trattarli come stati formali di business, non come semplice rumore nei log.

Il servizio di segnalazione WooshPay mantiene il registro dei token e collega transazioni, rimborsi, annullamenti, scadenze e risultati senza transazione a payload o file per Apple.

Per impostazione predefinita, WooshPay non conserva chiavi private Apple API, issuer ID o key ID dell’esercente e non invia segnalazioni per suo conto. L’esercente usa le proprie credenziali/JWT mantenendo controllo delle credenziali e responsabilità legale e finanziaria.

Create acquisti esterni per giochi iOS in Giappone con WooshPay

Gli acquisti esterni offrono ai giochi iOS in Giappone un nuovo pagamento e nuovi requisiti tecnici, di revisione e segnalazione. WooshPay collega SDK, Hosted Checkout, sincronizzazione degli stati e generazione dei dati per lanciare un’esperienza controllata, riconciliabile e scalabile.

WooshPay riduce lo sviluppo ripetuto dei flussi Apple, semplifica apertura del browser e ritorno all’app, permette erogazioni basate sullo stato definitivo del server e prepara dati strutturati e verificabili per le segnalazioni ad Apple.