IOSOR

IOSOR Wissen

Endnutzer-Versand bucht weiterhin vom selben Prepaid-Hauptbuch ab

Embedded Send belistet weiterhin das ISV-Prepaid-Wallet. Erfinden Sie kein zweites Hauptbuch — Reservierungen, Retries und Idempotenz bleiben ehrlich.

Embedded Messaging fühlt sich für den Endnutzer kostenfrei an: Er klickt in der SaaS-Oberfläche auf Senden und sieht ein grünes Häkchen. Unter der Oberfläche führt jedoch jeder erfolgreiche Versand weiterhin zu einer Abbuchung auf dem einzigen Prepaid-Hauptbuch des ISV. Es entsteht kein zweites Wallet, nur weil das Produkt eine API eingebettet hat. Wenn der ISV keine Guthabenreservierungen finanziert, muss der Versand mit einem ehrlichen Produktfehler fehlschlagen und keinesfalls einen gefälschten Zustellstatus anzeigen.

Ein Hauptbuch, selbst wenn die UI Produkt-Guthaben anzeigt

Nachrichtenpakete, die an Kunden verkauft werden, sind eine kommerzielle Schicht des ISV. Sie müssen direkt auf Reservierungen und Abbuchungen auf dem einzelnen IOSOR-Wallet abgebildet werden, das vom ISV aufgeladen wird. Ein Kundenkontostand, der nicht mit den Hauptbucheinträgen übereinstimmt, führt zu erheblichen Problemen im Support. Exportieren Sie die Nutzung wöchentlich gegen die Wallet-Daten, damit die Finanzabteilung denselben Verbrauch sieht wie das Produkt.

Reservierungen und Idempotenz gelten weiterhin für Embedded-Pfade

Der serverseitige Versand muss Idempotenz-Schlüssel für OTPs und transaktionale SMS verwenden. Ein doppelter Klick in der SaaS-Oberfläche darf nicht zu zwei Abbuchungen für eine einzelne Benutzeraktion führen. Retries nach einem Zeitüberschreitungsfehler nutzen denselben Schlüssel bis zum Erhalt eines terminalen DLRs oder eines definierten Fehlers.

Zuordnung von Produktfehlern zur Wahrheit des Hauptbuchs

SaaS-UI-Signal Wahrheit des Hauptbuchs Erlaubter nächster Schritt
Gesendet / Zugestellt Abbuchung + DLR-Pfad vorhanden Beleg-ID anzeigen
In Warteschlange Reservierung offen oder Übermittlung akzeptiert Status abfragen
Fehlgeschlagen / Pausiert Reservierung abgelehnt oder Sperre aktiv Erneuter Versuch nur bei neuer Absicht
Gefälschter Erfolg Keine Abbuchung / keine Reservierung Strenge verboten

Kanalübergaben verbleiben auf demselben Wallet

Wenn das Produkt später E-Mail oder Voice neben SMS ergänzt, verbleiben die Ausgaben auf demselben Prepaid-Hauptbuch, es sei denn, Sie führen eine Kanalübergabe mit expliziter Freigabe der Finanzabteilung durch. Die Einbettung schafft keinen kostenlosen Nebenkanal. Lesen Sie die Dokumentation zur Wallet-Adjazenz, bevor Sie ein weiteres Live-Modul in den SaaS-Einstellungen aktivieren.

Verwandte Betriebspfade

Starten Sie mit IOSOR

Öffnen Sie die IOSOR-Konsole und verknüpfen Sie Ihr Mandanten-Guthabensystem direkt mit dem primären Prepaid-Wallet-Hauptbuch. Stellen Sie sicher, dass alle serverseitigen Einbettungsanfragen einen deterministischen Idempotenzschlüssel übergeben, bevor eine Sperre auf dem Haupt-Wallet platziert wird. Konfigurieren Sie Ihren Webhook-Endpunkt so, dass eingehende DLRs verarbeitet werden, damit offene Sperren sauber in finale Hauptbuch-Belastungen oder Freigaben aufgelöst werden.

IOSOR Fazit

Eine eingebettete SaaS-Schnittstelle kann Endbenutzern benutzerdefinierte Nachrichtenguthaben präsentieren, aber jeder echte Versand ist an das einzelne Prepaid-Wallet gebunden, das vom ISV finanziert wird. Wiederholungen, Kanalerweiterungen und Benutzerstatus-Signale müssen direkt mit Wallet-Sperren und nicht mit nicht gedeckten UI-Abstraktionen abgeglichen werden.

Erzwingen Sie strikte serverseitige Idempotenzschlüssel und ordnen Sie jeden Mandanten-UI-Status echten Hauptbuch-DLR-Antworten zu. Erfinden Sie keine nicht gedeckten sekundären Wallets und erlauben Sie keine Wiederholungen der Mandanten-UI ohne konkrete Hauptbuch-Sperren.

War dieser Leitfaden hilfreich?

Verwandte Leitfäden