Inkommande MO till spärrlista: STOP på ett DID skyddar ditt rykte

Inkommande MO till spärrlista.

Arkitekturen för automatisk opt-out via inkommande MO

När en slutanvändare svarar med STOP, UNSUBSCRIBE eller QUIT på ett inkommande Mobile Originated (MO)-meddelande på ett dedikerat E.164 DID, måste din plattform behandla denna signal omedelbart. Att lagra telefonnummer på en spärrlista på API-nivå förhindrar att efterföljande utgående Mobile Terminated (MT)-trafik bryter mot operatörernas regelverk. Om ett utgående meddelande försöker skickas till en spärrad mottagare måste gatewayen avbryta eller markera nyttolasten som överhoppad innan nätverksöverföringen sker. Denna arkitektur säkerställer att din avsändarstatus förblir skyddad hos alla operatörer.

Mappa inkommande sökord till spärrlistor

Inkommande MO-payloads anländer via webhooks som innehåller avsändarens E.164-nummer, destinations-DID, tidsstämpel och meddelandets råtext. Spärrsystemet analyserar standardiserade opt-out-sökord som STOP, CANCEL, END, QUIT och OPTOUT. När en matchning upptäcks normaliserar bearbetningsmotorn strängen genom att ta bort blanksteg och diakritiska tecken, omvandla tecken till versaler och köra en reguljär uttrycksparser. Om meddelandet innehåller ett matchande sökord utlöser motorn en skriroperation till den permanenta spärrdatabasen för att förhindra framtida utskick.

Webhooks, statuskoder och varför 'skipped' inte är ett fel

När en utgående sändningsbegäran riktas mot en spärrad E.164-destination blockerar CPaaS-motorn överföringen innan data skickas vidare i nätverket. Plattformen returnerar ett HTTP 200 OK-svar med en status-payload som anger 'skipped_suppressed'. Att returnera en HTTP 4xx- eller 5xx-statuskod för en opt-out-blockering är felaktigt, eftersom det antyder ett infrastrukturfel eller en felaktig formatförfrågan, vilket utlöser onödig omförsökslogik i klientens SDK. Genom att returnera HTTP 200 OK tillsammans med 'skipped_suppressed' bekräftas att begäran har hanterats korrekt utan avgifter.

Operativa regler och kontroll av förskottsbetalning

Hantering av inkommande MO-bearbetning och spärrmotorer kräver stabila finansiella ramar. CPaaS-plattformar arbetar enligt en strikt förskottsmodell med en lägsta gräns på USD 20 för att upprätthålla oavbruten webhook-bearbetning och DID-dirigering. Om kontosaldot faller under denna minimigräns buffras inkommande MO-webhooks i en kö i upp till 72 timmar istället för att kastas, vilket bevarar kritiska opt-out-signaler. När den månatliga volymen ökar mot en utvärderingsgräns runt USD 1,000/månad utvärderar kontoansvariga trafikmönstren för att säkerställa maximal tillförlitlighet.

Efterlevnadsmatris: Hantering av inkommande opt-out

Börja med IOSOR

När STOP landar på DID:n, skriv den avsändande MSISDN till den tenantens suppression-lista före nästa MT. Bevisa att en uppföljande sändning nekas. Exportera MO-stämpeln och listraden. En webhook-2xx utan listskriv är inte det här jobbet; E.164-städning är en annan grind.

Relaterat: Caller ID vs meddelande From: röst live betyder inte SMS live E.164-normalisering före DID-bindning: plus, nollor och mellanslag reservation av förbetalt saldo före första debiteringen.

IOSOR sammanfattning

Ett inkommande MO på ett DID är en listskrivning, inte ett loggminne.

Gör: undertryck före nästa MT. Gör inte: märk STOP som noterat medan MT fortsätter, eller vänta på en veckodump.