Dlaczego moja weryfikacja toll-free SMS została odrzucona?

Po odrzuceniu dossier przez operatora weryfikacja udostępnia powód osobno od statusów elementów. denial_reasons zawiera wyjaśnienie operatora. Lista wymagań rejestruje to, co dostarczyłeś, a nie to, która odpowiedź spowodowała odrzucenie.

Pierwszym miejscem, do którego ludzie zaglądają, jest lista wymagań, a ona nie odpowie na to pytanie. Zrozumienie przyczyny oszczędza mnóstwo czasu.

Gdzie jest powód odrzucenia?

Użyj bird sms tfn verifications get, żeby odczytać weryfikację. Zwraca stan, nadawcę, którego licencjonuje, i odpowiedź operatora. denial_reasons zawiera tę odpowiedź jako tekst.

Jeden szczegół wart uwagi: powody pojawiają się przy odrzuceniu. Gdy operator prosi o zmiany zamiast odmówić wprost, weryfikacja przechodzi do info_requested i zapisuje nowy status bez dołączonych powodów. Weryfikacja, która prosi cię o dodatkowe informacje, nie powie ci jakie, więc wtedy szukaj w liście wymagań, żeby zobaczyć, których elementów wciąż brakuje.

Dlaczego lista wymagań nie wskaże, która odpowiedź była błędna?

Ponieważ operator nie ocenia odpowiedzi po kolei. Ocenia dossier jako całość, a Bird rzutuje ten pojedynczy werdykt na każdy dostarczony element.

W odrzuconej weryfikacji każdy dostarczony element ma status rejected, niezależnie od tego, czy to on spowodował problem. Każdy pusty element ma status not_supplied. Żaden element na liście nie jest bardziej odrzucony niż inny. Lista nie wskazuje winowajcy, więc korzystaj z denial_reasons.

Lista wymagań służy naprawdę do opisu kształtu dossier: co jest wymagane, na co odpowiedziałeś i czego wciąż brakuje.

O co właściwie pyta operator?

Zapytaj o wymagania bez wskazania konkretnej weryfikacji, a dostaniesz pusty formularz: każdy element, o który pytają operatorzy, w kolejności do prezentacji. Wskaż jedną za pomocą --verification-id, a dostaniesz tę samą listę z jej własnymi odpowiedziami.

Każdy element zawiera key, pod którym go przesyłasz, label do przedstawienia osobie, która ma odpowiedzieć, help_text opisujący, jak wygląda poprawna odpowiedź, oraz informację, czy odpowiedź jest required. Opcjonalne elementy też są weryfikowane, gdy je dostarczysz.

Dwie odpowiedzi to zamknięte zbiory, które warto znać przed rozpoczęciem:

• Forma prawna, jedna z sole_proprietor, private_profit, public_profit, non_profit lub government. Są zapisane tak samo jak pięć struktur 10DLC i celowo stanowią osobną listę, ponieważ każdy organ sam decyduje, co akceptuje.
• Miesięczny wolumen, jako przedział, a nie liczba: jedenaście przedziałów, od up_to_10 przez up_to_1m i up_to_5m, kończąc na above_5m.

Każdy element raportuje też state, a odczyt toll-free zwraca pięć z nich: not_supplied, supplied, in_review, approved i rejected. Traktuj ten zbiór jako otwarty, bo przegląd może zyskać nowe etapy.

Jak sprawdzić, czy czeka na mnie, czy na operatora?

Odpowiadają na to dwie wartości logiczne w odczycie wymagań, a tylko jedna z nich dotyczy ciebie.

satisfied jest true dopiero po zatwierdzeniu weryfikacji. Kompletny wniosek wciąż może czekać na zatwierdzenie.

needs_input jest true, gdy następny ruch należy do ciebie. Obejmuje to cztery sytuacje: wymagany element nie ma odpowiedzi, operator poprosił o zmiany, twój szkic jest kompletny, ale nikt go nie przesłał, albo odrzucenie wciąż mieści się w oknie ponownego przesłania.

Obie false to kombinacja warta rozpoznania, bo ma dwa znaczenia. Albo operator trzyma dossier i nie pozostaje nic poza czekaniem, albo weryfikacja została odrzucona, a okno ponownego przesłania już się zamknęło. resubmit_allowed rozróżnia te dwa przypadki, co jest dobrym powodem, żeby odczytywać je przy każdym odrzuceniu.

Co oznacza sześć stanów weryfikacji?

Czy mogę poprawić odrzuconą weryfikację?

Czasami tak, i odpowiada na to jedno pole: odrzuconą weryfikację można poprawić i przesłać ponownie tylko dopóki resubmit_allowed jest true. Korzystaj ze zwróconej flagi i stanu przeglądu przed edycją lub ponownym przesłaniem, zamiast wyliczać uprawnienie z samej daty.

Weryfikacja jest edytowalna, gdy jest szkicem, gdy operator poprosił o dodatkowe informacje i gdy odrzucenie wciąż mieści się w oknie ponownego przesłania. Wszystko inne jest zablokowane, łącznie z submitted i under_review oraz approved, więc dwa stany, w których czekasz najdłużej, to stany, z których nie możesz edytować. Próba i tak kończy się konfliktem.

Poprawienie jednej odpowiedzi nie oznacza ponownego wprowadzania pozostałych. Aktualizacja stosuje tylko pola, które wysyłasz, więc jedna błędna odpowiedź kosztuje cię tę odpowiedź, a nie całe dossier.

Jakich poleceń użyć?

Sześć poleceń obejmuje cały cykl życia, a jeden krok celowo wśród nich nie figuruje.

bird sms tfn verifications requirements odczytuje widok element po elemencie, a get, create, update, list i cancel robią to, co mówią ich nazwy. Przesyłania weryfikacji do przeglądu nie ma wśród nich: odbywa się to w dashboardzie.

Jeden skrót warto znać podczas wypełniania formularza. Przekazanie --identity-id wstępnie wypełnia wymagania dotyczące firmy i kontaktu na podstawie podmiotu, który już opisałeś, a te elementy wracają oznaczone jako wstępnie wypełnione. Wymagania dotyczące wiadomości i zgody nigdy nie są wstępnie wypełniane, bo piszesz je od nowa dla każdej weryfikacji, a wszystko, co już złożyłeś dla tej weryfikacji, ma pierwszeństwo przed odpowiedzią podmiotu.

Nie istnieje też publiczne zdarzenie webhooka dla stanu weryfikacji toll-free, więc subskrypcja nie poinformuje cię o podjęciu decyzji. Odpytywanie poleceniem get to jedyny sposób, żeby się dowiedzieć.