Eine zuverlässige SMS-Integration trennt Katalog, nutzergebundenes Angebot, idempotente Bestellerstellung, Statusabfrage und bestätigte Stornierung. Halten Sie Anbieterschlüssel auf dem Server und prüfen Sie Besitz bei jeder Anfrage. Unklare Anbieterantworten erfordern Abgleich statt eines automatischen Neukaufs oder einer unbestätigten Erstattung.
Trennen Sie Oberfläche und Anbieterzugriff
Der Browser ruft Ihre Anwendungs-API auf; der Server kontaktiert den SMS-Anbieter. Speichern Sie Zugangsdaten als Runtime-Secrets und geben Sie nur die Felder zurück, die der authentifizierte Nutzer benötigt. Ein öffentlicher Katalog unterscheidet sich von Konto und Posteingang. Prüfen Sie Besitz bei Statusabfrage, Stornierung und Abschluss. Authentifizierung ausschließlich beim Kauf reicht nicht aus.
Verwenden Sie ein verbindliches, kurzlebiges Angebot
ReceiveSMSGo implementiert mit POST /api/v1/quotes ein nutzergebundenes Angebot für 60 Sekunden. Der Server berechnet USD-Preise als max(0,39 USD, umgerechnete Anbieterkosten × 2). Bei der Bestellung sendet der Client eine Angebots-ID statt eines vertrauenswürdigen Preises. Fordern Sie bei Ablauf ein neues Angebot an. Verfügbarkeit kann sich zwischen Abfrage und Kauf ändern; solche Fehler sollten ausdrücklich dargestellt werden.
Reservieren Sie einmal und klären Sie ungewisse Käufe
POST /api/v1/orders erfordert Idempotency-Key und quoteId. Derselbe Schlüssel für dieselbe beabsichtigte Operation liefert die vorhandene Bestellung. Guthabenreservierung und Ledger-Änderung sind atomar implementiert. Bei einer unklaren Anbieterantwort wechselt die Bestellung in Prüfung, statt erneut zu kaufen. Idempotenz schützt die Anwendungsgrenze; sie gleicht einen Anbieter-Timeout nicht von selbst ab.
- Erzeugen Sie einen Schlüssel je beabsichtigtem Kauf und behalten Sie ihn bei Wiederholungen.
- Senden Sie die aktuelle Angebots-ID mit authentifiziertem Nutzerkontext.
- Klären Sie unsichere Ergebnisse vor einem weiteren Kauf.
Fragen Sie eigene Bestellungen maßvoll ab
GET /api/v1/orders/{id} liefert die Nutzerbestellung und kann einen aktiven Anbieterstatus aktualisieren. Die Implementierung erlaubt höchstens eine Anbieterprüfung je fünf Sekunden pro Bestellung. Modellieren Sie wartend, empfangen, abgeschlossen, storniert, abgelaufen und Prüfung getrennt. Erfinden Sie keine Ablaufzeit, wenn Einheiten in Anbieterdokumenten unklar bleiben. Ein geschlossener Browser beweist kein Ende der entfernten Bestellung.
Bestätigen Sie die Stornierung vor einer Guthabenänderung
POST /api/v1/orders/{id} akzeptiert cancel oder finish. Stornierung ist 120 Sekunden nach Erstellung gesperrt; danach fordert der Server Anbieterbestätigung vor einer einmaligen Erstattung. Abschluss verlangt einen empfangenen SMS-Code. Zustandswechsel schützen vor überlappenden gleichzeitigen Aktionen. Eine fehlgeschlagene Netzwerkanfrage bedeutet weder erfolgreiche Stornierung noch Erlaubnis für eine doppelte Gutschrift.
Prüfen Sie Callbacks und unterscheiden Sie Betriebsbereitschaft
Ein eingehender Rückruf ist nicht automatisch maßgeblich. Nach Prüfung der Stripe-Signatur wird vor einer Gutschrift der verbindliche Zahlungsdatensatz abgefragt. Eine unsignierte SMS-Statusmeldung ist nur ein Hinweis, den authentifizierten Bestellstatus abzurufen. Stripe-Test- und Live-Ereignisse müssen zu ihrem Endpunktgeheimnis, Konto und ihrer Einzahlungsumgebung passen. Externe Rückrufe müssen erreichbar sein; eine Weiterleitung ist kein Zahlungsnachweis. Arbeitsbereichs-APIs erfordern eine authentifizierte Website-Sitzung, keinen öffentlichen Entwickler-API-Schlüssel. Prüfen Sie vor der Integration aktivierte Vorgänge und OpenAPI.
Hilfreiche Fragen, klare Antworten
Darf ein Anbieter-API-Schlüssel ins Frontend?
Nein. Verwenden Sie Server-Runtime-Secrets. Das Frontend ruft Ihre API mit authentifiziertem Nutzerkontext auf.
Sollte ich einen Kauf-Timeout mit neuem Schlüssel wiederholen?
Fragen Sie zuerst die ursprüngliche Bestellung ab und gleichen Sie sie ab. Ein neuer Schlüssel bezeichnet einen weiteren Kauf und kann weitere Kosten verursachen.
Ist die Arbeitsbereich-API ein öffentliches Entwickler-Schlüsselprodukt?
Nein. Konto- und Bestell-APIs erfordern eine authentifizierte Website-Sitzung. Ein separates öffentliches API-Schlüsselprodukt ist noch nicht verfügbar; prüfen Sie aktivierte Operationen vor Integration.
Quellen und weiterführende Informationen
Quellen beschreiben ihre eigenen Dienste und können sich ändern. Prüfen Sie die aktuellen Anforderungen des Zieldiensts, bevor Sie eine Nummer wählen.
Verstehen Sie den Ablauf, bevor Sie beginnen.
Entdecken Sie Dienstauswahl, Länderoptionen und SMS-Status im Arbeitsbereich. Angebote und Verfügbarkeit hängen vom Anbieter ab; Nummernannahme und Zustellung werden nicht garantiert. Ihre Geldbörse und Bestellungen erfordern eine Anmeldung.
Arbeitsbereich öffnen
