Входящи MO към списък за блокиране: STOP на DID защитава репутацията

Входящи MO към списък за блокиране.

Архитектурата на автоматичния отказ чрез входящо MO съобщение

Когато краен потребител отговори със STOP, UNSUBSCRIBE или QUIT на входящо Mobile Originated (MO) съобщение на специализиран E.164 DID, вашата платформа трябва незабавно да обработи този сигнал. Съхраняването на номера в списък за блокиране (suppression list) на ниво API предотвратява последващия изходящ Mobile Terminated (MT) трафик да наруши правилата за съответствие на операторите. Ако се направи опит за изходящо съобщение към блокиран получател, шлюзът трябва да отхвърли или маркира съобщението като пропуснато преди предаването по мрежата.

Картиране на входящи ключови думи към списъци за блокиране

Входящите MO данни пристигат чрез webhook-и, съдържащи E.164 номера на подателя, целевия DID, времево клеймо и самия текст на съобщението. Подсистемата за блокиране анализира стандартни ключови думи за съответствие като STOP, CANCEL, END, QUIT и OPTOUT. При откриване на съвпадение, обработващият модул нормализира текста чрез премахване на интервали и диакритични знаци, конвертиране в главни букви и изпълнение на parser за регулярни изрази.

Webhook-и, кодове за състояние и защо 'skipped' не е грешка

Когато заявка за изходящо изпращане е насочена към блокирана E.164 дестинация, CPaaS модулът спира предаването преди изпращане на данни към маршрутите. Платформата връща HTTP 200 OK отговор с данни за състоянието, посочващи 'skipped_suppressed'. Връщането на HTTP 4xx или 5xx код за състояние при отказ е неправилна практика, тъй като предполага инфраструктурна грешка или невалидна заявка, което задейства излишна логика за повторни опити в клиентите.

Оперативни правила и контроли на предплатения баланс

Управлението на входящата MO обработка и модулите за блокиране изисква стабилни финансови рамки. CPaaS платформите работят с твърда предплатена структура с праг от USD 20 за поддържане на непрекъсната обработка на webhook-и и рутиране на DID номера. Ако балансът на акаунта падне под този минимум, входящите MO webhook-и се буферират на опашка до 72 часа, вместо да бъдат отхвърлени, запазвайки критичните сигнали за отказ.

Матрица за съответствие: Обработка на входящи откази

Започнете с IOSOR

Когато STOP кацне на DID, запишете изходящия MSISDN в списъка suppression на този тенант преди следващото MT. Докажете, че следващото изпращане е отказано. Изнесете печата MO и реда от списъка. Webhook 2xx без запис в списък не е тази работа; чистенето на E.164 е друга врата.

Свързани: Caller ID vs messaging From: Гласово живо не означава SMS живо E.164 нормализация преди DID обвързване: плюс, нули и интервали резервиране на предплатен баланс преди първото дебитиране.

Обобщение IOSOR

Входящо MO на DID е запис в списък, не сувенир от лог.

Правете: потиснете преди следващото MT. Не правете: да бележите STOP като отбелязан, докато MT върви, или да чакате седмичен dump.