IOSOR

IOSOR Ghiduri

Mesaje MO primite către lista de suprimare: STOP pe un DID protejează reputația

Analiză tehnică privind procesarea cuvintelor cheie MO de dezabonare pe numere DID E.164, executarea listei de suprimare, payload-uri de webhook și protecții pentru conturi preplătite.

Mesaje MO primite către lista de suprimare.

Arhitectura dezabonării automate prin mesaje MO primite

Când un utilizator final răspunde cu STOP, UNSUBSCRIBE sau QUIT la un mesaj primit Mobile Originated (MO) pe un număr dedicat E.164 DID, platforma dumneavoastră trebuie să proceseze acest semnal imediat. Stocarea numerelor pe o listă de suprimare la nivelul API previne situația în care traficul ulterior de tip Mobile Terminated (MT) încalcă regulile de conformitate ale operatorilor. Dacă se încearcă trimiterea unui mesaj ieșit către un destinatar suprimat, gateway-ul trebuie să renunțe la mesaj sau să îl marcheze ca omis înainte de transmiterea în rețea.

Maparea cuvintelor cheie primite pe listele de suprimare

Payload-urile MO primite sosesc prin intermediul webhook-urilor care conțin numărul E.164 al expeditorului, DID-ul de destinație, marcajul temporal și corpul mesajului. Subsystemul de suprimare analizează cuvintele cheie standard de conformitate precum STOP, CANCEL, END, QUIT și OPTOUT. La detectarea unei potriviri, motorul de procesare normalizează textul prin eliminarea spațiilor și a diacriticelor, convertind caracterele în majuscule și rulând un parser regex.

Webhook-uri, coduri de stare și de ce 'skipped' nu este o eroare

Când o cerere de expediere ieșită vizează o destinație E.164 suprimată, motorul CPaaS blochează transmisia înainte de a trimite date către căile de rutare. Platforma returnează un răspuns HTTP 200 OK cu un payload de stare care indică 'skipped_suppressed'. Returnarea unui cod de stare HTTP 4xx sau 5xx pentru o blocare de tip opt-out reprezintă o practică greșită, deoarece sugerează o eroare de infrastructură sau un format eronat al cererii, declanșând o logică inutilă de reîncercare în SDK-urile clienților.

Reguli operaționale și controlul soldului preplătit

Gestionarea procesării mesajelor MO primite și a motoarelor de suprimare necesită limite financiare stabile. Platformele CPaaS funcționează pe o structură strict preplătită, cu o limită minimă de USD 20 pentru a menține procesarea neîntreruptă a webhook-urilor și rutarea DID-urilor. Dacă soldul unui cont scade sub acest prag minim, webhook-urile MO primite sunt stocate într-o coadă de așteptare timp de până la 72 de ore în loc să fie abandonate, conservând semnalele critice de dezabonare.

Matrice de conformitate: Gestionarea dezabonărilor primite

Cuvânt cheie Acțiune luată Stare ieșire Impact asupra facturării
STOP Adăugare în lista de suprimare Skipped (Blocat) Fără taxă de ieșire
UNSTOP Eliminare din listă Permis Tarif standard
HELP Declanșare webhook info Permis Tarif standard
CANCEL Adăugare în lista de suprimare Skipped (Blocat) Fără taxă de ieșire

Începeți cu IOSOR

Când STOP aterizează pe DID, scrieți MSISDN-ul originator pe lista de suppression a acelui tenant înainte de MT-ul următor. Dovediți că un trimis următor e refuzat. Exportați ștampila MO și rândul de listă. Un webhook 2xx fără scriere de listă nu e treaba asta; curățarea E.164 e altă poartă.

Materiale: Caller ID vs messaging From: Vocea în direct nu înseamnă SMS în direct Normalizare E.164 înainte de legarea DID: plus, zerouri și spații rezervarea soldului preplătit înainte de prima debitare.

Rezumat IOSOR

Un MO de intrare pe un DID e o scriere de listă, nu un suvenir de jurnal.

Faceți: suprimați înainte de MT-ul următor. Nu faceți: marca STOP ca notat cât MT continuă, nici aștepta un dump săptămânal.

A fost util acest ghid?

Ghiduri conexe