Abrechnung-API

Die quellenbewusste Kontostandsaufnahme des aufrufenden Projekts. Alle Millicredit-Beträge sind kanonische Dezimalstrings. Es ist eine Momentaufnahme, keine Zahlungsbefugnis; rails_available ist falsch, solange Karte, Steuer und Auszahlungs-Schiene nicht verfügbar sind.

Stabile Cursor-Paginierung über unveränderliche veröffentlichte Journal-Einträge für das aufrufende Projekt. Holds sind keine veröffentlichten Einträge. Korrekturen verlinken auf das Originalereignis, anstatt es umzuschreiben. Es gibt keine willkürliche Gewährungs- oder Auszahlungsänderung auf dieser Ebene.

Die Nutzung des aufrufenden Projekts für einen UTC-Monat, mit den ausgelieferten und empfangenen Bytes (nie berechnet), dem Speicher, der über dem kostenlosen Speicher des Plans des Zahlers berechnet wird (allowance.storage_bytes), sowie den API-Anfragen, abgerechneten Projekt-Stream-Ereignissen und Webhook-Zustellversuchen, die auf die kostenlosen 10.000 pro Monat angerechnet werden. Ein Projekt, das für sich selbst zahlt, liest seinen eigenen Pool.

Ein Projekt, für das ein anderer Zahler bezahlt, teilt den Pool dieses Zahlers mit dessen anderen Projekten; es liest seinen eigenen Anteil, und payer nennt den Zahler. Der Pool-Gesamtbetrag des Zahlers bleibt in den Abrechnungen des Zahlers.

Was eine Organisation über den App Store in der screenRIG-App für iPhone und iPad kaufen darf (Bundle ai.screenrig.app) und das Konto-Token, das ihre Käufe tragen.

Erfordert einen designierten Administrator der aktiven Organisation (die Person, die ihren Plan und ihre Abrechnung verwaltet); Mitarbeiter und die Admins des Resellers, an den die Organisation delegiert ist, können das Angebot ohne products oder Token lesen, alle anderen erhalten 404 not_found.

Eine an einen Reseller delegierte Organisation listet keine Produkte auf: ihr Reseller bezahlt ihren Plan. account_token ist eine zufällige UUID, die der Server einmal pro Organisation erzeugt und aufbewahrt: Die App übergibt sie an StoreKit als appAccountToken, sodass jede Transaktion und jede Server-Benachrichtigung ihre Organisation nennt.

Für einen Leser, der nicht kaufen kann, ist account_token die UUID aus lauter Nullen. products listet die Pläne, die der Aufrufer jetzt kaufen darf, je ein App-Store-Produkt: plus, education (nur solange education_eligible true ist) und premium. education_eligible ist true, wenn Mitarbeiter eine K-12-Schule oder einen K-12-Schulbezirk verifiziert haben oder wenn der Admin, der das Angebot liest, eine verifizierte Konto-E-Mail-Adresse bei einer K-12-Schuldomain hat (education_eligibility_source school_email): Öffnet ein solcher Admin das Angebot oder erfasst er eine Transaktion, wird die Organisation einmalig berechtigt, ein Organisations-Audit-Eintrag mit der passenden Domain geschrieben und Education in dasselbe Angebot aufgenommen.

Eine Entscheidung der Mitarbeiter, in beide Richtungen, ist endgültig, und die automatische Berechtigung überschreibt sie nie.

Ein Plan, den die Organisation bereits über eine andere Quelle (Mitarbeiter, Rechnungsstellung, anderes Abonnement) auf gleicher oder höherer Stufe hat, wird nicht angeboten, außer der Person, deren App-Store-Abonnement ihn hält; sie darf innerhalb der Abonnementgruppe den Plan wechseln. can_purchase ist true, wenn products nicht leer ist. subscription ist das App-Store-Abonnement der Organisation oder null.

Die Antwort ist privat und no-store.

Erfasst eine signierte StoreKit-2-Transaktion (Transaction.jwsRepresentation), die für die Organisation gekauft wurde, und versetzt die Organisation in ihren Plan. Erfordert einen designierten Administrator der aktiven Organisation, Cookie-Authentifizierung mit demselben Ursprung und bei JWT-Sitzungen den CSRF-Header.

Der Server verifiziert das JWS mit seiner x5c-Kette bis Apple Root CA - G3 (außerhalb der Produktion auch dem StoreKit-Testing-Root von Xcode), die Bundle-ID ai.screenrig.app, die Produkt-ID, die Umgebung (Production nur in der Produktion; Sandbox überall, weil App Review und TestFlight mit Sandbox-Konten gegen die Produktion kaufen; Xcode nur außerhalb der Produktion) und dass appAccountToken dem account_token der Organisation entspricht (getAppStoreOffer); nichts in der Anfrage nennt, wer bezahlt hat.

Der Plan folgt dem Produkt der neuesten Transaktion des Abonnements: Ein höherer Plan gilt sofort, ein niedrigerer, wenn ihn der nächste UTC-Monatswechsel der Abrechnung erreicht, wie bei jedem Planwechsel. Eine erneut gesendete oder ältere Transaktion ändert nichts und beantwortet das Abonnement, wie es steht; eine abgelaufene Transaktion wird erfasst und ändert keinen Plan.

Die App schließt die Transaktion nach einer 2xx-Antwort oder einem endgültigen 4xx-Problem ab. Probleme: app_store_transaction_invalid (422), app_store_account_mismatch (409), education_not_eligible (403), app_store_plan_conflict (409), billed_by_reseller (409, die Organisation ist an einen Reseller delegiert, der für ihren Plan zahlt).

Apples App Store Server Notifications V2 (der Body signedPayload), die in App Store Connect für die Produktions- und die Sandbox-Umgebung festgelegte URL. Öffentlich: Die signierte Payload ist der Berechtigungsnachweis und wird so verifiziert, wie recordAppStoreTransaction eine Transaktion verifiziert, samt der darin enthaltenen signierten Transaktion und Verlängerungsinformation.

SUBSCRIBED, DID_RENEW, DID_CHANGE_RENEWAL_PREF und DID_CHANGE_RENEWAL_STATUS (sowie OFFER_REDEEMED, RENEWAL_EXTENDED und REFUND_REVERSED) wenden die neueste Transaktion an: Eine Verlängerung verlängert das Abonnement, ein Upgrade wechselt den Plan sofort und ein Downgrade, wenn das niedrigere Produkt zum Periodenende verlängert wird.

EXPIRED, GRACE_PERIOD_EXPIRED, REFUND und REVOKE beenden das Abonnement und entfernen den damit gesetzten Plan, wie die Abrechnung jeden Plan entfernt: zum nächsten UTC-Monatswechsel, ohne bereits Gewährtes zurückzunehmen. Ein Plan, den Mitarbeiter oder die Rechnungsstellung der Organisation seither gegeben haben, wird nie entfernt.

Jeder andere Typ, eine Benachrichtigung für ein Produkt, das kein Plan ist, und eine, die keine Organisation nennt, werden bestätigt und protokolliert. 200 bestätigt. Eine Payload, die sich nicht verifizieren lässt, ist ein 422-Problem app_store_transaction_invalid; ein serverseitiger Fehler ist ein 5xx, den Apple erneut sendet. Begrenzt pro Client-Adresse.