\r\n\r\n import base64\r\nimport hashlib\r\nimport hmac\r\nimport time\r\n\r\nMAX_CALLBACK_AGE_SECONDS = 300\r\n\r\n@router.post("\/sinch\/callbacks")\r\nasync def handle_callback(request: Request) -> Response:\r\n raw_body = await request.body()\r\n signature = request.headers.get("x-sinch-webhook-signature", "")\r\n nonce = request.headers.get("x-sinch-webhook-signature-nonce", "")\r\n timestamp = request.headers.get("x-sinch-webhook-signature-timestamp", "")\r\n\r\n try:\r\n age = abs(time.time() - int(timestamp))\r\n except ValueError:\r\n raise HTTPException(status_code=401, detail="Bad timestamp")\r\n if age > MAX_CALLBACK_AGE_SECONDS:\r\n raise HTTPException(status_code=401, detail="Stale callback")\r\n\r\n signed_data = raw_body + b"." + nonce.encode() + b"." + timestamp.encode()\r\n expected = base64.b64encode(\r\n hmac.new(\r\n settings.webhook_secret.encode(), signed_data, hashlib.sha256\r\n ).digest()\r\n ).decode()\r\n if not hmac.compare_digest(expected, signature):\r\n raise HTTPException(status_code=401, detail="Invalid signature")\r\n\r\n payload = json.loads(raw_body)\r\n if "message_delivery_report" in payload:\r\n await record_delivery(payload["message_delivery_report"])\r\n elif "message" in payload:\r\n await record_inbound_message(payload["message"])\r\n return Response(status_code=200)\r\n <\/code>\r\n <\/pre>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n\n\n\nHierbei gilt es einige Dinge zu beachten. Die signierte Zeichenfolge besteht aus dem rohen Rumpf, der Nonce und dem Zeitstempel,\u00a0die in dieser Reihenfolge durch Punkte verbunden sind, und der Digest ist Base64 statt Hex. Berechnen Sie es \u00fcber die rohen\u00a0Bytes, nicht \u00fcber ein neu serialisiertes Dict, sonst wird es niemals \u00fcbereinstimmen. Der Schl\u00fcssel ist das Secret, das Sie festgelegt haben, als Sie\u00a0den Webhook erstellt haben, und x-sinch-webhook-signature-algorithm<\/code> teilt Ihnen mit, welcher Algorithmus verwendet wurde\u00a0(aktuell HmacSHA256<\/code>).<\/p>\n\n\n\nEine g\u00fcltige Signatur allein besagt nicht, dass die Anfrage aktuell ist. Jeder, der einen signierten\u00a0Callback abf\u00e4ngt, kann ihn erneut senden, und der HMAC ist weiterhin g\u00fcltig. Genau daf\u00fcr sind der Zeitstempel und die Nonce\u00a0da: Sinch beschreibt die Nonce aus genau diesem Grund als einzigartig pro Callback. Das obige Zeitfenster von\u00a0f\u00fcnf Minuten ist meine eigene Wahl, kein dokumentierter Wert, und es ist der einfachere Teil. Falls Sie\u00a0eine strikte einmalige Verarbeitung ben\u00f6tigen, cachen Sie die bereits akzeptierten Nonces f\u00fcr die Dauer dieses\u00a0Zeitfensters und lehnen Sie Wiederholungen ab. Eine idempotente Handhabung ist ebenfalls sinnvoll, da Sinch erneute Versuche mit\u00a0exponentiellem Backoff durchf\u00fchrt und Sie legitimerweise dieselbe Best\u00e4tigung zweimal sehen werden. Idempotenz ist jedoch kein\u00a0Replay-Schutz: Sie verhindert, dass ein wiederholter Callback Ihren Status besch\u00e4digt, ohne Ihnen jemals mitzuteilen,\u00a0dass er wiederholt wurde.<\/p>\n\n\n\n
RCS hinzuf\u00fcgen<\/h2>\n\n\n\n Da der Sendepfad bereits kanalunabh\u00e4ngig ist, ist RCS ein Nachrichtentyp und eine Kanaleigenschaft:<\/p>\n\n\n
\r\n\r\n
F\u00fchren Sie f\u00fcr die Erinnerung ein Upgrade auf eine RCS-Rich Card mit dem verifizierten Absender der RockBank, einer Zahlungs\u00fcbersicht und einer Schaltfl\u00e4che \u201cJetzt bezahlen\u201d durch, die unsere gehostete Zahlungsseite \u00f6ffnet. Behalten Sie das SMS-Fallback f\u00fcr Ger\u00e4te bei, die kein RCS unterst\u00fctzen.<\/p><\/div>\r\n <\/div>\r\n\n\n\n
Die Card ist eine card_message<\/code> mit einer url_message<\/code>-Auswahl darauf, die an dasselbe _send<\/code> wie\u00a0zuvor \u00fcbergeben wird:<\/p>\n\n\n \r\n
\r\n\r\n \r\n \r\n \r\n \r\n Shell <\/button>\r\n <\/li>\r\n\r\n \r\n \r\n <\/ul>\r\n \r\n\r\n \r\n
\r\n
\r\n
\r\n
\r\n <\/svg>\r\n <\/svg>\r\n <\/button>\r\n <\/div>\r\n \r\n \r\n\r\n async def send_reminder_card( \r\n self, \r\n to: str, \r\n due_date: date, \r\n amount: Decimal, \r\n account_last4: str, \r\n payment_url: str, \r\n ) -> dict[str, Any]: \r\n card: dict[str, Any] = { \r\n "title": f"Payment due {due_date:%d %b}", \r\n "description": f"Amount: ${amount:,.2f}. Account ending {account_last4}.", \r\n "choices": [ \r\n {"url_message": {"title": "Pay now", "url": payment_url}} \r\n ], \r\n } \r\n return await self._send( \r\n to, \r\n {"card_message": card}, \r\n channel_properties={"RCS_WEBVIEW_MODE": "TALL"}, \r\n ) \r\n <\/code>\r\n <\/pre>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n\n\n\nchannel_properties<\/code> ist eine einzige flache Map, sodass der RCS-Schl\u00fcssel und der SMS_SENDER<\/code>, den das Fallback ben\u00f6tigt, im\u00a0selben Dictionary landen. Diese Zusammenf\u00fchrung ist der Grund, warum _send<\/code> die Eigenschaften als Argument annimmt, anstatt\u00a0sie inline zu erstellen. RCS_WEBVIEW_MODE<\/code> steuert, wie viel vom Bildschirm die Zahlungsseite einnimmt, wenn\u00a0sie ge\u00f6ffnet wird: FULL<\/code>, HALF<\/code> oder TALL<\/code>.<\/p>\n\n\n\nZwei Details zu RCS, die man leicht falsch machen kann:<\/p>\n\n\n\n
RCS verarbeitet die Zahlung nicht.<\/strong> Die Schaltfl\u00e4che \u201cJetzt bezahlen\u201d ist eine URL-Aktion. Sie \u00f6ffnet Ihre gehostete\u00a0Zahlungsseite in einer Webansicht \u00fcber dem Thread, die Kundschaft bezahlt dort und die Steuerung kehrt zur\u00a0Konversation zur\u00fcck. Was RCS Ihnen bietet, ist der verifizierte Absender, die markenkonforme Card und eine Kundschaft, die niemals\u00a0ihre Messaging-App verl\u00e4sst. Die Zahlung l\u00e4uft weiterhin \u00fcber Ihren Zahlungsanbieter.<\/p>\n\n\n\nFallback-Fehler kommen sp\u00e4t an.<\/strong> Jeder Kanal, den Sie in channel_priority_order<\/code> angeben, muss\u00a0in der App konfiguriert sein, andernfalls wird die Anfrage direkt abgelehnt, was der einfache Fall beim Debuggen ist. Der\u00a0schwierigere Fall ist ein konfigurierter Kanal, dessen Zustellung fehlschl\u00e4gt: messages:send<\/code> gibt 200 zur\u00fcck, und das\u00a0Ergebnis taucht sp\u00e4ter als MESSAGE_DELIVERY<\/code>-Callback auf, wobei SWITCHING_CHANNEL<\/code> den Punkt markiert,\u00a0an dem das Fallback eingesetzt hat. Ein weiterer Grund, die Webhook-Trigger richtig einzurichten, bevor man sich auf den\u00a0Fallback-Pfad verl\u00e4sst.<\/p>\n\n\n\nVoice, Verifizierung und E-Mail<\/h2>\n\n\n\n F\u00fcr die restlichen vier Teile war jeweils ein Prompt erforderlich.<\/p>\n\n\n\n
Voice.<\/strong> Falls die Erinnerung unbeantwortet bleibt und die Zahlung weiterhin aussteht, ruft die RockBank an. Ein\u00a0Text-to-Speech-Anruf erfordert keinen Call-Flow-Server, sondern nur einen POST an die Voice-API:<\/p>\n\n\n \r\n\r\n
F\u00fcgen Sie eine Voice-Erinnerung f\u00fcr Zahlungen hinzu, die zwei Tage, nachdem die Nachricht versendet wurde, noch ausstehen. Verwenden Sie einen Text-to-Speech-Anruf \u00fcber die Sinch Voice-API mit den Zugangsdaten f\u00fcr unsere Voice-Anwendung und setzen Sie die Anrufer-ID auf unsere registrierte Nummer.<\/p><\/div>\r\n <\/div>\r\n\n\n
\r\n
\r\n\r\n \r\n \r\n \r\n \r\n Shell <\/button>\r\n <\/li>\r\n\r\n \r\n \r\n <\/ul>\r\n \r\n\r\n \r\n
\r\n
\r\n
\r\n
\r\n <\/svg>\r\n <\/svg>\r\n <\/button>\r\n <\/div>\r\n \r\n \r\n\r\n async def place_reminder_call(self, to: str, message: str) -> dict[str, Any]:\r\n """Place a text-to-speech reminder call via the Voice API."""\r\n tts: dict[str, Any] = {\r\n "destination": {"type": "number", "endpoint": to},\r\n "cli": self.caller_id,\r\n "locale": "en-US",\r\n "text": message,\r\n }\r\n response = await self.client.post(\r\n "\/calling\/v1\/callouts",\r\n auth=(self.voice_app_key, self.voice_app_secret),\r\n json={"method": "ttsCallout", "ttsCallout": tts},\r\n )\r\n if response.is_error:\r\n raise SinchClientError(\r\n f"Voice callout failed ({response.status_code}): {response.text}"\r\n )\r\n return response.json()\r\n <\/code>\r\n <\/pre>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n\n\n\nBeachten Sie den Unterschied bei der Authentifizierung: Voice verwendet einen Anwendungsschl\u00fcssel und ein Secret, nicht die Zugangsdaten auf Projektebene,\u00a0welche die Conversation API nutzt. Anderes Produkt, anderes Authentifizierungsschema, und die Skills\u00a0decken beides ab, sodass der Prompt keines von beiden erkl\u00e4ren musste.<\/p>\n\n\n\n
destination<\/code> f\u00fcr einen Telefonanruf lautet {\"type\": \"number\", \"endpoint\": \"+46...\"}<\/code> in E.164, und die\u00a0Antwort liefert Ihnen eine callId<\/code>. Die API-Referenz f\u00fchrt cli<\/code> als optional auf, aber setzen Sie es dennoch auf eine\u00a0verifizierte Nummer oder eine aus Ihrem Dashboard zugewiesene: Ohne eine verwendbare Anrufer-ID k\u00f6nnten Sie eine Call-ID f\u00fcr einen Anruf zur\u00fcckerhalten,\u00a0der das Telefon niemals erreicht.<\/p>\n\n\n\nVerifizierung.<\/strong> Ein Einmalpasswort, bevor die Zahlungsseite irgendetwas akzeptiert:<\/p>\n\n\n \r\n\r\n
Bevor die Zahlungsseite irgendetwas akzeptiert, verifizieren Sie die Kundschaft mit einem Einmalpasswort per SMS \u00fcber die Sinch Verifizierungs-API. Machen Sie die Methode zug\u00e4nglich, damit wir sie pro Anfrage wechseln k\u00f6nnen.<\/p><\/div>\r\n <\/div>\r\n\n\n
\r\n
\r\n\r\n \r\n \r\n \r\n \r\n Shell <\/button>\r\n <\/li>\r\n\r\n \r\n \r\n <\/ul>\r\n \r\n\r\n \r\n
\r\n
\r\n
\r\n
\r\n <\/svg>\r\n <\/svg>\r\n <\/button>\r\n <\/div>\r\n \r\n \r\n\r\n async def start(self, phone: str, method: str = "sms") -> dict[str, Any]:\r\n response = await self.client.post(\r\n "\/verification\/v1\/verifications",\r\n auth=self._verification_auth,\r\n json={"identity": {"type": "number", "endpoint": phone}, "method": method},\r\n )\r\n ...\r\n\r\nasync def verify(self, reference: str, code: str) -> dict[str, Any]:\r\n path = f"\/verification\/v1\/verifications\/id\/{quote(reference, safe='')}"\r\n response = await self.client.put(\r\n path,\r\n auth=self._verification_auth,\r\n json={"method": "sms", "sms": {"code": code}},\r\n )\r\n ...\r\n <\/code>\r\n <\/pre>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n\n\n\n_verification_auth<\/code> ist ein drittes Set von Zugangsdaten: Die Verifizierung authentifiziert sich mit dem Schl\u00fcssel und\u00a0dem Secret ihrer eigenen App im Dashboard, es sind also weder die Schl\u00fcssel auf Projektebene, welche die Conversation API\u00a0verwendet, noch die f\u00fcr die Voice-Anwendung.<\/p>\n\n\n\nstart<\/code> gibt eine id<\/code> zur\u00fcck, und das ist die ID, f\u00fcr die Sie den Code melden. Die Methodenwerte sind der Teil,\u00a0den man kennen sollte: sms<\/code> f\u00fcr ein Passwort per Nachricht, callout<\/code> f\u00fcr eines, das bei einem Telefonanruf vorgelesen wird, plus\u00a0flashcall<\/code>, seamless<\/code> und whatsapp<\/code>. Der Rumpf des Berichts erh\u00e4lt dieselbe Methode als Schl\u00fcssel, also\u00a0{\"method\": \"sms\", \"sms\": {\"code\": \"1234\"}}<\/code> f\u00fcr die Nachricht und\u00a0{\"method\": \"callout\", \"callout\": {\"code\": \"1234\"}}<\/code> f\u00fcr den Anruf.<\/p>\n\n\n\nVerifizierungen laufen nach wenigen Minuten ab. Behandeln Sie daher eine 400 beim Bericht eher als \u201eeine neue starten\u201c anstatt\u00a0als fehlgeschlagenen Versuch. Eine Person aus der Kundschaft auf