Die erste SMS über eine Provider-API zu senden, dauert einen Nachmittag. Die eigentliche Arbeit beginnt danach: was "gesendet" bedeutet, was bei einem Timeout passiert, und was ein Anbieterwechsel kostet.
Eigener Vertrag statt Provider-SDK
Die wichtigste frühe Entscheidung ist, ob Anwendungscode direkt ein Provider-SDK aufruft. Besser: ein eigener interner Vertrag mit Zieladresse, Nachrichteninhalt, Traffic-Klasse, Absenderauswahl und eigener Client-Referenz. Alles Providerspezifische lebt hinter einem Adapter – das macht einen zweiten Anbieter zu einem neuen Adapter statt zu einem Refactoring.
Client-Referenzen und mehrdeutige Timeouts
Für jede Nachricht sollte vor dem Senden eine eigene Referenz erzeugt und gespeichert werden, denn Provider-IDs existieren erst nach erfolgreicher Antwort. Der kritische Fall ist der Timeout: Die Nachricht wurde vielleicht zugestellt, vielleicht nicht. Bevorzugt werden Idempotenzschlüssel des Providers, sonst ein Lookup per eigener Referenz, sonst eine explizite, traffic-klassenabhängige Richtlinie.
Absenderidentität, Encoding und Statusmapping
Absenderidentität ist Konfiguration, nicht ein zur Sendezeit gewählter String – abhängig vom Zielmarkt als registrierte alphanumerische Sender-ID, Long Number, Kurzwahl oder Nummernpool, oft mit Registrierungsfristen von Wochen. GSM-7 erlaubt 160 Zeichen pro Segment, Unicode nur 70; ein einzelnes Sonderzeichen kann die ganze Nachricht in mehrsegmentiges Unicode kippen und Kosten verändern – Segmentzahl sollte vor dem Versand berechnet werden. Provider-Statuscodes sollten auf ein eigenes kanonisches Set gemappt werden, mit rohen Werten zur Fehlersuche und Alarmen für unbekannte Werte.
Webhooks, Retries und Durchsatz
Statuscallbacks sollten signaturgeprüft, replay-geschützt und tolerant gegenüber Duplikaten und vertauschter Reihenfolge sein, mit schneller Bestätigung und asynchroner Verarbeitung plus einem Abgleichsjob für hängende Nachrichten. Retry-Entscheidungen sollten an einer Stelle eigentümerschaftlich festgelegt werden – sonst wiederholen Anwendung, Plattform und Provider gleichzeitig. Durchsatzgrenzen sind pro Konto, Verbindung oder Absender limitiert; eigene Warteschlangen pro Traffic-Klasse verhindern, dass ein Kampagnen-Batch Verifizierungs-Traffic verzögert.
Korrelation, Messung und Ausstiegsfähigkeit
Eine Korrelations-ID über Auslöseereignis, Sendevorgang, Callbacks und Klicks hinweg beantwortet, ob eine Nachricht tatsächlich zur gewünschten Aktion geführt hat – Zustellquittungen allein sind dafür ein schwacher Indikator. Ausstiegsfähigkeit lässt sich testen: Kann eine Route per Konfiguration ohne Release gewechselt werden, existiert providerspezifischer Code in der Anwendung, sind Nachrichtenverlauf und Consent exportierbar?
Grenzen der SMS-Sicherheit
Gewöhnliche SMS ist nicht Ende-zu-Ende-verschlüsselt; Inhalte sind für Zwischenstationen einsehbar und liegen unverschlüsselt auf dem Gerät. Passwörter, vollständige Kontonummern oder Zahlungsdaten gehören nicht in eine SMS; Einmalcodes sollten kurzlebig, sitzungsgebunden und rate-limitiert sein.
Flowstates liefert Messaging-Routen und kann diese Betriebsschicht übernehmen; Kunden können eigene Anbieterverträge über BYOV behalten oder beides hybrid kombinieren.