Authentication messaging · Provider dependent

Distribusi Token Guest Wi-Fi melalui SMS, Email, dan WhatsApp API.

Rancang perjalanan pengiriman token yang dapat diuji dari permintaan pengguna hingga akses diberikan—dengan provider, template, credential, consent, delivery status, expiry, fallback, biaya, dan support ownership yang ditetapkan sebelum produksi.

Validate Messaging Flow → Review Nimbus Guest Access
✓Channel-specific prerequisite ✓End-to-end delivery testing ✓Consent and fallback planning
Messaging readiness view
Validation required
SMS
SMS deliveryNomor tujuan, provider account, sender configuration, token copy, expiry, status, retry, dan cost owner.
Documented option
MAIL
Email deliveryAlamat tujuan, sender identity, template, deliverability, spam handling, support path, dan operational monitoring.
Documented option
WA
WhatsApp APIApproved provider/account, template status, credential, destination format, delivery flow, consent, dan fallback.
Provider review
Boundary: daftar kanal tidak berarti seluruh provider, API, template, negara tujuan, sender, delivery status, atau cost model otomatis didukung. Scope publik harus mengikuti hasil uji yang disetujui.
Kanal dipilih berdasarkan flow, bukan sekadar popularitas.
01User input
02Provider dependency
03Delivery evidence
04Fallback & ownership
Channel comparison

Bandingkan dependency sebelum menentukan kanal utama.

Keputusan tidak cukup berdasarkan “lebih cepat” atau “lebih mudah”. Evaluasi harus mencakup input pengguna, provider, template, delivery state, biaya, support, privacy, dan fallback yang benar-benar dapat dijalankan.

SMS
Provider dependent

SMS

Opsi distribusi token melalui nomor telepon setelah provider, sender, coverage, cost, dan delivery behavior disepakati.

User inputNomor telepon dalam format yang telah ditetapkan.
DependencyProvider account, credential, sender configuration, network delivery, dan destination coverage.
StatusRequest, accepted, delivered, failed, atau status lain hanya jika disediakan dan dipetakan oleh provider.
Cost ownerHarus ditetapkan sebelum rollout; jangan mengasumsikan biaya termasuk dalam produk.
FallbackRetry terkontrol, channel alternatif, atau support path sesuai kebijakan.
Jangan menjanjikan delivery time atau coverage universal tanpa data provider dan hasil pengujian lokal.
MAIL
Configuration dependent

Email

Opsi pengiriman token atau instruksi akses melalui alamat email dengan sender identity, template, deliverability, dan support yang jelas.

User inputAlamat email yang divalidasi sesuai kebutuhan flow.
DependencySender domain/account, credential, template, mail delivery, spam filtering, dan recipient access.
StatusAccepted, sent, bounced, failed, atau state lain hanya jika benar-benar tersedia.
Cost ownerProvider atau mail service ownership perlu disepakati dan didokumentasikan.
FallbackResend, koreksi alamat, alternate channel, atau bantuan venue.
Email yang “sent” tidak otomatis berarti telah dibaca. Acceptance test harus membedakan system state dan user outcome.
WA
Validation required

WhatsApp API

Opsi messaging yang hanya boleh diposisikan sebagai capability aktif setelah provider, account, template, credential, consent, dan flow diuji.

User inputNomor tujuan dan acknowledgement sesuai flow serta kebijakan yang disetujui.
DependencyApproved provider/account, template status, API credential, destination format, policy, dan operational access.
StatusGunakan hanya state yang benar-benar dikembalikan, dipetakan, dan dapat diaudit.
Cost ownerProvider fee, conversation/template cost, dan perubahan harga bukan klaim Nimbus tanpa konfirmasi.
FallbackAlternative approved channel atau support route ketika template/account/delivery tidak tersedia.
Nama WhatsApp API bukan bukti readiness. Halaman ini tetap berstatus conditional sampai tested provider flow tersedia.
Token flow

Uji perjalanan dari request hingga access outcome.

Setiap tahap harus memiliki input, expected result, observed result, timestamp, error state, owner, serta evidence. Keberhasilan provider menerima request belum sama dengan token diterima dan digunakan oleh tamu.

STEP 01

User memilih kanal

Portal menjelaskan field, tujuan penggunaan, consent, serta alternatif yang tersedia.

STEP 02

Input divalidasi

Format nomor atau email diperiksa sebelum request dikirim ke flow berikutnya.

STEP 03

Token dibuat

Token, expiry, association, dan rule penggunaan mengikuti scope produk yang tervalidasi.

STEP 04

Provider mengirim

Request, response, provider reference, template, error, dan delivery state dicatat bila tersedia.

STEP 05

User memvalidasi

Tamu menerima pesan, memasukkan token atau mengikuti langkah yang disetujui, lalu sistem memeriksa hasil.

STEP 06

Access atau fallback

Akses diberikan, ditolak, kedaluwarsa, diulang, atau dialihkan sesuai expected state dan kebijakan.

Provider prerequisites

Siapkan dependency sebelum PoC dimulai.

Banyak kegagalan messaging bukan berasal dari captive portal. Ia dapat muncul dari account, template, credential, sender, destination format, policy, network path, quota, cost, atau ownership yang belum diselesaikan.

Discuss Your Prerequisites
01
Approved provider and accountNama provider, account owner, service status, region/coverage, contract boundary, dan escalation contact.
Required
02
Credential and access controlCredential owner, secure handling, access limitation, rotation, test/prod separation, dan revocation path.
Required
03
Sender and template readinessSender identity, template copy, variable field, language, approval state, expiry, support text, dan update owner.
Required
04
API and network contextEndpoint/version only when documented, network path, allowlist, certificate, timeout, response mapping, dan rate behavior.
Validate
05
Delivery and failure statesState yang tersedia, retry rule, duplicate prevention, expiry, fallback, alert, dan provider incident handling.
Define
06
Commercial and operational ownerCost, quota, billing, monitoring, support hours, incident owner, maintenance, change, dan production approval.
Approval
Security rule: jangan menempel credential, token provider, secret, nomor nyata, alamat email nyata, atau data tamu ke screenshot, tiket publik, page source, atau materi pemasaran.
SMS token draftRedacted example
Kode akses Guest Wi-Fi Anda: [TOKEN]. Berlaku hingga [EXPIRY]. Jangan bagikan kode ini. Bantuan: [SUPPORT PATH].
Conceptual copy only. Sender, character limit, language, expiry, support path, and provider approval must be validated.
Email token draftRedacted example
Subject: Akses Guest Wi-Fi Anda

Gunakan kode [TOKEN] pada captive portal sebelum [EXPIRY]. Kode hanya untuk sesi yang diminta. Informasi bantuan dan kebijakan data: [APPROVED LINKS].
Conceptual copy only. Sender identity, mail delivery, approved links, accessibility, and privacy language require review.
WhatsApp API draftConditional example
Permintaan akses Guest Wi-Fi diterima. Kode Anda: [TOKEN]. Berlaku sampai [EXPIRY]. Gunakan hanya pada portal resmi [VENUE]. Bantuan: [SUPPORT PATH].
Do not publish as an active WhatsApp capability until provider account, template approval, delivery flow, consent, and evidence are available.
Message template discipline

Pesan singkat tetap membawa tanggung jawab operasional.

Template harus membantu tamu memahami apa yang diterima, kapan berakhir, bagaimana digunakan, dan ke mana meminta bantuan—tanpa memuat klaim keamanan atau privacy yang belum disahkan.

01
Purpose yang jelasJelaskan bahwa pesan dikirim untuk proses akses Guest Wi-Fi yang diminta pengguna.
02
Token dan expiryGunakan variable yang benar, format terbaca, serta aturan expiry yang telah diuji.
03
Security directionHindari instruksi ambigu; jelaskan batas penggunaan tanpa membuat jaminan absolut.
04
Support and policy pathSertakan jalur bantuan dan link hanya setelah destination, ownership, dan content disetujui.
No fabricated UI: contoh di sebelah kiri adalah content prototype, bukan screenshot provider, bukti live delivery, atau interface Nimbus.
Failure and fallback

Desain state gagal sebelum pengguna mengalaminya.

Flow yang hanya mendesain kondisi berhasil belum siap produksi. Setiap kegagalan harus memiliki pesan yang dapat dipahami, retry boundary, fallback yang sah, logging, dan escalation owner.

STATE 01

Provider request gagal

Request tidak diterima, timeout, credential invalid, quota, policy, atau dependency lain menghalangi pengiriman.

Tentukan user message, retry interval, alert, evidence, dan escalation tanpa memaparkan detail sensitif.
STATE 02

Pesan belum diterima

Provider menerima request, tetapi user belum memperoleh pesan atau delivery state belum final.

Bedakan accepted, delivered, pending, failed, dan unknown hanya jika state tersebut benar-benar tersedia.
STATE 03

Token invalid atau expired

Token salah, sudah digunakan, tidak terkait dengan request, atau melewati masa berlaku yang ditetapkan.

Jelaskan next action, rate boundary, reissue rule, dan support route secara proporsional.
STATE 04

Kanal utama tidak tersedia

Account, template, provider, network, atau operational dependency membuat kanal utama tidak dapat digunakan.

Fallback hanya ditawarkan bila channel alternatif, consent, cost, dan operational ownership telah disetujui.
Fallback rule: jangan otomatis memindahkan data pengguna ke kanal lain tanpa pemberitahuan, consent, provider readiness, dan policy yang sesuai. “Coba kanal lain” harus menjadi keputusan flow, bukan improvisasi saat insiden.
Consent and data

Jelaskan mengapa data diminta dan siapa yang menanggung prosesnya.

Nomor telepon atau alamat email bukan sekadar field login. Pengumpulan, pengiriman ke provider, retention, operational access, support, dan penghapusan memerlukan keputusan bisnis, teknis, serta privacy yang dapat dipertanggungjawabkan.

Minimum trust checklist.

01
Purpose noticeJelaskan tujuan field dan penggunaan untuk proses Guest Wi-Fi sebelum pengguna mengirim data.
02
Provider disclosureTentukan apakah data diproses melalui provider eksternal dan bagaimana informasi itu dijelaskan.
03
Retention and accessCatat data apa yang disimpan, berapa lama, siapa yang dapat mengakses, dan bagaimana review dilakukan.
04
Terms, privacy, and acknowledgementGunakan link serta consent behavior yang telah disetujui; jangan menempatkan checkbox tanpa fungsi yang jelas.
05
Support and correctionSediakan jalur ketika data salah, pesan tidak diterima, atau pengguna memerlukan bantuan.
Shared responsibility

Owner harus jelas sebelum data melewati portal.

Nimbus, venue, integrator, provider, dan operational team dapat memiliki tanggung jawab berbeda. Page publik tidak boleh menggantikan privacy assessment atau perjanjian yang diperlukan.

Business ownerMenetapkan purpose, channel, cost, user policy, service expectation, dan approval produksi.
Technical ownerMengelola integration, credential, monitoring, failure state, logging, security, dan change.
Privacy / legal ownerMeninjau notice, consent, retention, provider handling, policy, dan dokumentasi yang relevan.
Support ownerMenangani user issue, resend/fallback decision, provider incident, escalation, dan service communication.
Operational evidence

Laporkan state yang tersedia—bukan metrik yang dibayangkan.

Operational view hanya boleh menampilkan event atau status yang benar-benar disediakan, dipetakan, dan dapat diverifikasi pada build serta provider yang digunakan. Jangan menampilkan delivery rate, conversion, cost, atau dashboard live tanpa data nyata.

REQUESTMessage request recordTimestamp, channel, redacted destination, provider reference, template/version, dan request outcome bila tersedia.
DELIVERYDelivery stateAccepted, delivered, failed, pending, atau mapped status lain hanya berdasarkan evidence provider.
ACCESSToken/access outcomeIssued, validated, rejected, expired, retried, dan access result sesuai capability produk yang tervalidasi.
OPERATIONSIncident and ownershipError category, retry, fallback, provider incident, support action, resolution, reviewer, dan change context.
Technical FAQ

Pertanyaan sebelum memilih kanal autentikasi.

Jawaban final bergantung pada provider, account, template, tujuan lokasi, user journey, privacy requirement, cost model, dan hasil pengujian environment.

Explore Guest Authentication
Apakah Nimbus mendukung semua provider SMS, email, dan WhatsApp API?
Tidak boleh diasumsikan. Compatibility harus ditentukan berdasarkan provider, account, API/version bila relevan, credential, sender/template, network path, delivery state, cost, policy, dan hasil uji end-to-end.
Apakah SMS dan email sudah dapat digunakan untuk distribusi token?
Materi Nimbus mendokumentasikan SMS dan email sebagai opsi distribusi token atau pesan akses. Implementasi publik tetap memerlukan provider configuration, prerequisite, template, test evidence, operational ownership, serta approval.
Kapan WhatsApp API boleh ditawarkan kepada pelanggan?
Setelah provider/account, template approval, credential, delivery flow, consent, fallback, cost, support, positive/negative testing, dan public claim scope telah divalidasi serta disetujui.
Siapa yang menanggung biaya pengiriman pesan?
Cost owner tidak boleh diasumsikan. Provider fee, quota, template/conversation cost, tax, billing, dan perubahan harga harus diklarifikasi dalam commercial serta operational design sebelum rollout.
Apa yang terjadi bila pesan tidak diterima?
Flow perlu membedakan request failure, pending/unknown delivery, provider failure, destination issue, serta user outcome. Retry, resend, channel alternatif, dan support route hanya digunakan sesuai rule yang telah disetujui.
Apakah delivery status selalu tersedia?
Tidak. State bergantung pada provider dan integration scope. Halaman atau laporan hanya boleh menampilkan status yang benar-benar dikembalikan, dipetakan, disimpan, dan dapat diverifikasi.
Data apa yang perlu disiapkan untuk compatibility review?
Siapkan target channel, provider/account, use case, volume perkiraan, lokasi/negara tujuan, sender/template status, credential ownership, network context, consent/privacy requirement, expiry, retry/fallback, cost owner, support path, dan acceptance criteria.
Bagaimana memulai PoC?
Mulai dengan satu channel, satu provider/account, satu approved template, test destination, defined success/failure states, redacted evidence, serta owner yang jelas. Perluasan channel dilakukan setelah baseline dapat diulang.
Next step

Validasi channel, provider, dan fallback sebelum menjadikannya bagian dari Guest Wi-Fi.

Kirim provider/account, target channel, sender/template status, use case, lokasi, volume perkiraan, user input, expiry, consent, cost owner, support path, serta expected failure behavior. Tim Nimbus akan membantu menyusun scope compatibility review dan PoC yang dapat dipertanggungjawabkan.

✓Provider prerequisite review ✓Token and template flow ✓Failure, fallback, and privacy ✓PoC evidence and sign-off
Validate Messaging Flow → Back to Integrations