API Fatturazione

L’istantanea del saldo consapevole della sorgente del progetto chiamante. Tutti gli importi millicredito sono stringhe decimali canoniche. È un’istantanea, non un’autorità di pagamento; rails_available è falso mentre carta, tasse e rail cash-out non sono disponibili.

Paginazione cursore stabile su voci di diario immutabili pubblicate per il progetto chiamante. Le hold non sono voci pubblicate. Le correzioni collegano all'evento originale invece di riscriverlo. Non ci sono mutazioni arbitrarie di concessione o pagamento su questa superficie.

L’uso del progetto chiamante per un mese UTC, con i byte serviti e ricevuti (mai addebitati), l’archiviazione addebitata oltre quella gratuita del piano del pagante (allowance.storage_bytes) e le richieste API, gli eventi di flusso del progetto fatturati e i tentativi di consegna webhook conteggiati rispetto ai 10.000 gratuiti al mese. Un progetto che paga per sé legge il proprio pool.

Un progetto pagato da un altro pagatore condivide il pool di quel pagatore con gli altri progetti di quel pagatore; legge la propria quota, e payer nomina il pagatore. Il totale del pool del pagatore resta nelle letture di fatturazione del pagatore.

Che cosa un’organizzazione può acquistare tramite App Store nell’app screenRIG per iPhone e iPad (bundle ai.screenrig.app) e il token account che portano i suoi acquisti.

Richiede un amministratore designato dell’organizzazione attiva (la persona che ne gestisce piano e fatturazione); lo staff e gli amministratori del reseller a cui l’organizzazione è delegata possono leggere l’offerta senza products o token, e chiunque altro riceve 404 not_found.

Un’organizzazione delegata a un reseller non elenca alcun prodotto: il suo reseller paga il piano. account_token è un UUID casuale che il server crea una volta per organizzazione e conserva: l’app lo passa a StoreKit come appAccountToken, così ogni transazione e ogni notifica del server nomina la sua organizzazione.

Per un lettore che non può acquistare, account_token è l’UUID composto solo da zeri. products elenca i piani che il chiamante può acquistare ora, un prodotto App Store ciascuno: plus, education (solo finché education_eligible è true) e premium. education_eligible è true quando lo staff ha verificato una scuola o un distretto K-12, oppure quando l’amministratore che legge l’offerta ha un indirizzo email dell’account verificato su un dominio scolastico K-12 (education_eligibility_source school_email): aprire l’offerta, o registrare una transazione, come tale amministratore rende l’organizzazione idonea una sola volta, scrive una voce di audit dell’organizzazione con il dominio corrispondente e include Education nella stessa offerta.

Una decisione dello staff, in un senso o nell’altro, è definitiva e l’idoneità automatica non la sostituisce mai.

Un piano che l’organizzazione ha già tramite un’altra fonte (staff, fatturazione, un altro abbonamento) allo stesso livello o a uno superiore non viene offerto, tranne alla persona il cui abbonamento App Store lo detiene, che può cambiare piano all’interno del gruppo di abbonamenti. can_purchase è true quando products non è vuoto. subscription è l’abbonamento App Store dell’organizzazione, oppure null.

La risposta è privata e no-store.

Registra una transazione firmata StoreKit 2 (Transaction.jwsRepresentation) acquistata per l’organizzazione e mette l’organizzazione sul suo piano. Richiede un amministratore designato dell’organizzazione attiva, l’autenticazione tramite cookie della stessa origine e, per le sessioni JWT, l’intestazione CSRF.

Il server verifica il JWS con la sua catena x5c fino ad Apple Root CA - G3 (fuori dalla produzione anche la radice di test StoreKit di Xcode), il bundle id ai.screenrig.app, l’id prodotto, l’ambiente (Production solo in produzione; Sandbox ovunque, perché App Review e TestFlight acquistano con account sandbox contro la produzione; Xcode solo fuori dalla produzione) e che appAccountToken sia uguale all’account_token dell’organizzazione (getAppStoreOffer); nulla nella richiesta nomina chi ha pagato.

Il piano segue il prodotto della transazione più recente dell’abbonamento: un piano superiore si applica subito e uno inferiore quando lo raggiunge il prossimo inizio mese UTC della fatturazione, come per qualsiasi cambio di piano. Inviare di nuovo una transazione, o una più vecchia, non cambia nulla e risponde con l’abbonamento così com’è; una transazione scaduta viene registrata e non cambia alcun piano.

L’app conclude la transazione dopo un 2xx o un problema 4xx definitivo. Problemi: app_store_transaction_invalid (422), app_store_account_mismatch (409), education_not_eligible (403), app_store_plan_conflict (409), billed_by_reseller (409, l’organizzazione è delegata a un reseller, che paga il suo piano).

App Store Server Notifications V2 di Apple (il corpo signedPayload), l’URL impostato in App Store Connect per gli ambienti di produzione e sandbox. Pubblico: il payload firmato è la credenziale, verificato come recordAppStoreTransaction verifica una transazione, insieme alla transazione firmata e alle informazioni di rinnovo al suo interno.

SUBSCRIBED, DID_RENEW, DID_CHANGE_RENEWAL_PREF e DID_CHANGE_RENEWAL_STATUS (e OFFER_REDEEMED, RENEWAL_EXTENDED e REFUND_REVERSED) applicano la transazione più recente: un rinnovo estende l’abbonamento, un upgrade cambia subito il piano e un downgrade quando il prodotto inferiore viene rinnovato a fine periodo.

EXPIRED, GRACE_PERIOD_EXPIRED, REFUND e REVOKE terminano l’abbonamento e rimuovono il piano che aveva impostato, come la fatturazione rimuove qualsiasi piano: al prossimo inizio mese UTC, senza riprendere nulla di già concesso. Un piano che staff o fatturazione hanno assegnato da allora all’organizzazione non viene mai rimosso.

Qualsiasi altro tipo, una notifica per un prodotto che non è un piano e una che non nomina alcuna organizzazione vengono confermate e registrate. 200 conferma. Un payload che non si verifica è un problema 422 app_store_transaction_invalid; un errore lato server è un 5xx, che Apple rinvia. Limitato per indirizzo client.