Entwicklung / ROBLOX
ProcessReceipt in Roblox: Ausgabe eines Developer Product prüfen
Trennen Sie Kaufdialog und Ausgabe, einen neuen Kauf und erneute Verarbeitung sowie Funktionsausführung und Ergebnis. Definieren Sie prüfbare Bedingungen für den Handler vor Beginn des Verkaufs.
Das versprochene Ergebnis festlegen #
Beginnen Sie mit einem genauen Versprechen: Ein fiktives Paket ergänzt Übungsmarken im gespeicherten Spielerprofil. Legen Sie Menge, Verwendung und Zustand nach einem erneuten Beitritt fest. „Ausgegeben“ ist ungenau, wenn nur eine vorübergehende Bildschirmmeldung beobachtet wurde.
Dieser Artikel enthält keinen laufenden Shop, echte IDs, Käufe oder fertigen Handler. Er erstellt einen Prüfplan für Entwickler. A und B sind fiktive Vorgänge, keine echten Spielerbelege. Der Plan ersetzt keine geprüfte Verkaufsimplementierung.
Dialog und Serverausgabe trennen #
Ein angezeigter Dialog beginnt lediglich den sichtbaren Ablauf. Die Dokumentation warnt davor, Developer Products über PromptProductPurchaseFinished auszugeben: Das Ereignis belegt für sich keinen erfolgreichen Kauf. Prüfen Sie Receipt-Verarbeitung getrennt von der Reaktion einer Schaltfläche.
Erfassen Sie getrennte Beobachtungen: Dialog angezeigt, Receipt erhalten, Wirkung bestätigt und Verarbeitung an die Plattform bestätigt. Fassen Sie sie nicht zu einem Erfolg zusammen. Ist nur eine Schaltflächenanimation sichtbar, bleibt der gespeicherte Profilzustand unbekannt.
Produkt und Vorgang unterscheiden #
ProductId bezeichnet das verarbeitete Produkt. PurchaseId unterscheidet konkrete Käufe. Zwei Receipts derselben ProductId können zwei eigenständige Käufe sein. Die erneute Zustellung derselben PurchaseId ist ein anderer Fall, bei dem der bereits bearbeitete Vorgang geprüft werden muss.
Unser erstes Paar ist A erstmals verarbeitet und anschließend erneut zugestellt. Das zweite ist A und danach ein neues B für dasselbe Produkt. A darf im ersten Fall keine zusätzliche Wirkung auslösen; B braucht im zweiten sein eigenes Ergebnis. Eine Sperre des gesamten Produkts nach dem ersten Kauf verwechselt diese Aufgaben.
Bild in voller Größe öffnen ↗Fehlerfreiheit und Ausgabe unterscheiden #
Ein geschützter Aufruf kann ohne Ausnahme enden, obwohl die innere Funktion die Ausgabe ablehnt oder nicht ausführt. Unsere Prüfkarte enthält deshalb zwei Felder: Wurde der Aufruf ausgeführt, und wurde die beabsichtigte Wirkung bestätigt? Beide Aussagen sind nicht austauschbar.
Planen Sie einen Handler, der ohne Ausnahme false zurückgibt. Die erwartete Antwort muss die fehlende Ausgabe berücksichtigen, nicht nur die erfolgreiche Funktionsausführung. Betrachten Sie Ausnahme und fehlenden Spielerzustand gesondert. Hier gibt es keinen Code, der diese Ergebnisse automatisch erzeugt.
Wirkung und Verarbeitungsnachweis zusammen prüfen #
Gespeicherte Marken benötigen übereinstimmende Tatsachen: die Wirkung im Profil und den Nachweis des verarbeiteten Kaufs. Ändert sich nur ein vorübergehender Saldo, kann eine Wiederholung einen unvollständigen Zustand vorfinden. Ein vorher gespeicherter Abschluss kann einen nicht ausgeführten Vorgang fälschlich als fertig markieren.
Zeichnen Sie Fehlerpunkte zwischen den Stufen ein und beschreiben Sie die Wiederherstellung. Ein normaler erfolgreicher Durchlauf prüft diese Lücken nicht. Ein Flag neben einem nicht gespeicherten Wert beweist keine zuverlässige Ausgabe. Speicherung und Wiederholung müssen vor dem Verkauf separat untersucht werden.
Den verwendeten API-Vertrag festhalten #
ProcessReceipt liefert Enum.ProductPurchaseDecision. Die MarketplaceService-Dokumentation enthält außerdem BindReceiptHandler mit eigenen Receipt-Typen und Enum.ReceiptDecision. Vermischen Sie Registrierung und Rückgabewerte beider Verträge nicht in einem Beispiel.
Hier planen wir eine ProcessReceipt-Prüfung und behaupten keine verpflichtende API-Migration. Notieren Sie verwendeten Vertrag, Ort des Serverhandlers und Verantwortlichkeit für die Registrierung. Laut Dokumentation wird ProcessReceipt einmal durch ein Serverskript gesetzt. Eine unerwartete Überschreibung durch ein anderes Skript muss untersucht werden.
Fehlende Voraussetzungen aufnehmen #
Planen Sie einen Receipt für einen abwesenden Spieler, ein unbekanntes Produkt oder ein noch nicht bereites Profil. Definieren Sie je Fall, welche Nachweise die Ausgabe bestätigen können. Fehlende Nachweise dürfen nicht zu einer sicheren Meldung „alles erhalten“ werden.
Nehmen Sie auch fehlgeschlagene Speicherung und späteren Beitritt auf. Bewahren Sie minimalen technischen Kontext und ursprüngliche Beobachtung auf, ohne persönliche Daten oder echte Belege auf der Website zu veröffentlichen. Versprechen Sie keine bestimmte Wiederholungsfrist: Geprüft wird die Entscheidung, nicht der Zeitplan der Plattform.
Wiederholungen und mehrere Server prüfen #
A zweimal in einer Sitzung zu testen ist hilfreich, deckt aber konkurrierende Verarbeitung und Fehler zwischen Wirkung und Speicherung nicht ab. Das API-Beispiel für ProcessReceipt benennt eine Einschränkung bei serverübergreifenden Datenfehlern. Das Kopieren des Beispiels löst diese Frage nicht.
Listen Sie parallele Versuche, Wiederholung nach unbekanntem Schreibresultat und wiederholte Zustandsumwandlungen auf. Unumkehrbare externe Wirkungen gehören nicht ohne ein gesondert geprüftes Protokoll in einen wiederholbaren Vorgang. Das sind Implementierungsfragen, kein Nachweis eines bereits geschützten Übungsshops.
Eine Ergebnismatrix erstellen #
Erfassen Sie Ausgangszustand, Vorgangskennung, erwartete Änderung und Bestätigungsbedingung. Beginnen Sie mit A, erneutem A und neuem B. Ergänzen Sie nicht bereites Profil und fehlgeschlagene Speicherung. Die Tabelle stellt Prüffragen, keine Ergebnisse bezahlter Tests.
Das erwartete Ergebnis muss sich auf den konkreten Vorgang und gespeicherten Effekt beziehen. „Keine Fehler in Output“ beantwortet keine Frage zur doppelten Ausgabe. Wiederholen Sie nach Änderungen sowohl den Normalfall als auch den Fall, der die Änderung ausgelöst hat.
| Fall | Prüfen |
|---|---|
| Erstes A | Ist eine Wirkung bestätigt? |
| Erneutes A | Bleibt eine zweite Wirkung von A aus? |
| Neues B | Hat B seine eigene Wirkung? |
| Schreiben fehlgeschlagen | Wie wird ein unbekanntes Resultat geklärt? |
Nachweise und offene Fragen übergeben #
Die Übergabekarte enthält Produkttyp, gewählte API, Profilmodell, Wiederholungsszenario, Beobachtung und verbleibende Grenzen. Geben Sie an, ob die Prüfung gedanklich, simuliert oder in einem getrennten Testspiel erfolgte. Diese Ebenen bestätigen einander nicht automatisch.
Vor dem Verkauf braucht es eine geprüfte Implementierung, die Wirkung und Kaufbestätigung auch bei Fehlern verbindet. Dieser Leitfaden formuliert die Aufgabe, bestätigt aber keine Verkaufsbereitschaft Ihrer Spiele. Kaufen Sie nichts zur Demonstration eines Artikels und bezeichnen Sie eine Hypothese nicht als geprüften Befund.
Bild in voller Größe öffnen ↗| Feld | Festhalten |
|---|---|
| Vertrag | Gewählte API und Rückgabewert |
| Vorgang | Produkt und konkreter Kauf |
| Wirkung | Gespeichertes Ergebnis und Wiederholung |
| Nachweis | Prüfart, Beobachtung und Umfang |
Originalquellen
Roblox Creator Hub — Developer ProductsRoblox Creator Hub — MarketplaceService API
