Bakıda mobil tətbiq hazırlanması üçün müraciət edərkən “tətbiqimiz CRM-ə, ödəniş sisteminə və bildirişlərə qoşulacaq” demək kifayət etmir. Təklifin müddətini, riskini və real qiymətini müəyyən edən məsələ həmin əlaqələrin necə işləməsidir: hansı sistem əsas mənbədir, hansı məlumat nə vaxt dəyişir, uğursuz sorğu zamanı nə baş verir və istifadəçi tətbiqdə hansı statusu görür.
Bu sualları proqramlaşdırmaya başlamazdan əvvəl cavablandırmaq, sonradan “sadə inteqrasiya”nın ayrıca backend, məlumat təmizlənməsi, təhlükəsizlik yoxlaması və ya əməliyyat proseduru tələb etdiyini aşkar etməyin qarşısını alır. POLADO-nun mobil tətbiqlərin hazırlanması xidməti məhz bu məhsul və inteqrasiya sərhədlərini aydınlaşdırmaqla başlayır.
Əvvəlcə sistem xəritəsini qurun: məlumatın sahibi kimdir?
Mobil tətbiq çox vaxt CRM, ERP, anbar, rezervasiya sistemi, müştəri dəstəyi, loyallıq platforması və ödəniş provayderi arasında istifadəçiyə görünən qatdır. Bu sistemlərin hamısında eyni məlumatın olması normaldır; lakin hər məlumat elementi üçün yalnız bir “həqiqət mənbəyi” təyin edilməlidir.
Məsələn, xidmət rezervasiyası olan tətbiqdə:
- müştəri profili CRM-də əsas mənbə ola bilər;
- boş vaxtlar rezervasiya sistemindən gəlməlidir;
- qiymət və endirim qaydaları ERP və ya ticarət sistemində saxlanıla bilər;
- ödənişin yekun statusu yalnız ödəniş provayderi tərəfindən təsdiqlənməlidir;
- tətbiqin backend-i bu məlumatı mobil ekranlar üçün uyğunlaşdırır, audit izi saxlayır və sistemlər arasında təhlükəsiz əlaqəni idarə edir.
“Tətbiq CRM-ə yazacaq” ifadəsini konkret əməliyyatlara bölün: yeni lead yaratmaq, mövcud kontaktı tapmaq, sifarişi CRM kartına bağlamaq, loyallıq balansını oxumaq, operatorun qeydini göstərmək və ya dəstək müraciəti açmaq. Hər əməliyyatın sahibi, giriş hüququ, cavab müddəti və uğursuzluq davranışı ayrıca qeyd olunmalıdır.
API hazır olması yalnız sənədin mövcudluğu deyil
İnteqrasiya üçün API sənədinin olması müsbət başlanğıcdır, amma “hazır inteqrasiya” demək deyil. Təklifdən əvvəl texniki komanda və biznes sahibi aşağıdakıları yoxlamalıdır:
- test mühiti, test istifadəçisi və təhlükəsiz test məlumatı varmı;
- lazım olan oxuma və yazma endpoint-ləri həqiqətən mövcuddurmu;
- autentifikasiya üsulu, token yenilənməsi, IP məhdudiyyəti və ya VPN tələbi nədir;
- sorğu limitləri, səhv kodları və versiyalaşdırma qaydası sənədləşdirilibmi;
- dəyişikliklər üçün xəbərdarlıq və dəstək kanalı varmı;
- webhook göndərilirsə, imza yoxlanması və təkrar çatdırılma davranışı necədir.
Mobil tətbiqin içində CRM və ya ödəniş sistemi üçün daimi gizli açar saxlamaq düzgün memarlıq deyil. Tətbiq adətən sizin backend API-nizə qoşulur; backend isə üçüncü tərəf sistemləri ilə məxfi açarları qoruyaraq əlaqə yaradır. İstifadəçi girişində OAuth istifadə edilirsə, mobil tətbiqlər üçün authorization-code axını və PKCE kimi müasir qorunmaların uyğunluğu ayrıca qiymətləndirilməlidir. OAuth 2.0 təhlükəsizlik üzrə aktual tövsiyələr public client-lər üçün PKCE-ni tələb edir və redirect URI-lərin dəqiq yoxlanmasını vurğulayır.
Bu mərhələdə texniki dəstək və konsaltinq formatında API auditinin nəticəsi çox praktik olur: hansı endpoint-lər birbaşa istifadə edilə bilər, hansı boşluqlar üçün inteqrasiya qatı lazımdır və hansı biznes qaydası hələ sistemdə mövcud deyil.
İdentiklik uyğunlaşdırılması: eyni şəxs hər sistemdə necə tanınacaq?
Mobil app CRM integration layihələrində ən çox görünməyən problem dublikat müştərilərdir. Telefon nömrəsi bir sistemdə +994 formatında, digərində 0 ilə başlaya bilər; e-poçt dəyişə bilər; bir ailə eyni nömrədən istifadə edə bilər. Ad, soyad isə etibarlı unikal açar deyil.
Başlamazdan əvvəl “master customer ID” qaydasını təsdiqləyin. İdeal halda CRM və ya mərkəzi müştəri sistemi dəyişməyən daxili identifikator verir, tətbiqin backend-i həmin ID-ni öz istifadəçi hesabına bağlayır. Telefon və e-poçt doğrulaması əlaqələndirmə siqnalıdır, lakin təkbaşına bütün rekordları avtomatik birləşdirmək üçün qayda olmamalıdır.
İdentiklik cədvəlinə daxil ediləcək suallar
- Qonaq istifadəçi sifariş verə bilərmi və sonra hesabına birləşdirilə bilərmi?
- Bir istifadəçi bir neçə telefon və ya e-poçt ünvanı saxlaya bilərmi?
- CRM-də uyğun müştəri tapılmadıqda yeni kontakt kim tərəfindən yaradılır?
- İki rekord uyğun görünəndə avtomatik birləşmə, yoxsa operator yoxlaması tətbiq ediləcək?
- İşçi, korporativ hesab, ailə üzvü və adi müştəri eyni identiklik modelindən istifadə edəcəkmi?
Burada təhlükəsizlik funksionallığın bir hissəsidir. API-lər obyekt identifikatorları ilə işlədiyi üçün server hər sorğuda istifadəçinin həmin sifarişə, rezervasiyaya və ya kart məlumatına həqiqətən çıxışı olduğunu yoxlamalıdır. OWASP bunu obyekt-səviyyəli avtorizasiya pozuntusu kimi əsas API risklərindən biri hesab edir. Sadəcə tətbiq ekranında düyməni gizlətmək kifayət deyil.
Ödəniş inteqrasiyasını “checkout ekranı” kimi deyil, status maşını kimi planlayın
Azərbaycanda mobil ödəniş inteqrasiyası üçün provayder seçimi vacibdir, amma daha vacib sual ödənişin biznes prosesinə necə bağlanmasıdır. Kart məlumatını tətbiqinizin backend-indən keçirmək əvəzinə, adətən provayderin təmin etdiyi tokenləşdirilmiş SDK, host edilmiş ödəniş səhifəsi və ya digər təsdiqlənmiş axından istifadə etmək daha məqsədəuyğundur. Kart məlumatını saxlamaq, emal etmək və ya ötürmək ödəniş məlumatının qorunması ilə bağlı əlavə məsuliyyət yaradır; həssas autentifikasiya məlumatının avtorizasiyadan sonra saxlanmasına isə yol verilmir.
Hər sifariş üçün backend-də unikal sifariş ID-si və ayrıca ödəniş cəhdi ID-si yaradın. Tətbiq “uğurlu” ekranını yalnız provayderin etibarlı server-to-server bildirişi və ya status yoxlaması əsasında göstərməlidir. İstifadəçinin brauzerdən və ya tətbiqdən qayıtdığı URL faydalı UX siqnalıdır, lakin yekun maliyyə təsdiqi deyil.
Ödəniş axını üçün qərar veriləcək ssenarilər
- İstifadəçi bank təsdiqi zamanı tətbiqi bağlayır: sifariş gözləmədə qalır, yoxsa ləğv olunur?
- Tətbiq timeout göstərir, amma ödəniş sonradan provayderdə uğurlu olur: istifadəçi və operator necə məlumatlandırılır?
- Eyni düyməyə iki dəfə toxunma iki ödəniş yaratmamalıdır: idempotency açarı və təkrar sorğu qaydası harada tətbiq olunur?
- Qismən geri qaytarma, tam refund, ləğv və chargeback üçün hansı sistem statusun sahibidir?
- Provayder webhook-u gecikir və ya iki dəfə gəlir: backend bunu təhlükəsiz və təkrarsız necə emal edir?
- Gün sonu maliyyə uzlaşdırmasını kim aparır: əməliyyat komandası, mühasibatlıq, yoxsa avtomatlaşdırılmış hesabat?
Əgər tətbiqdə cüzdan, balans, taksit, valyuta çevrilməsi və ya mürəkkəb maliyyə qaydaları varsa, FinTech və trading sistemləri üzrə ayrıca arxitektura baxışı tələb oluna bilər. Hüquqi və müqavilə tələblərini isə seçilən provayder, bank və hüquq məsləhətçisi ilə dəqiqləşdirmək lazımdır.
Push bildirişlərini marketinq kanalı yox, məhsul funksiyası kimi dizayn edin
Push notification app development yalnız Firebase və ya Apple konfiqurasiyası deyil. İstifadəçi icazə verməyə bilər, cihaz tokeni dəyişə bilər, bildiriş gecikə bilər və ya cihaz offline ola bilər. Buna görə əsas hadisə həmişə tətbiq daxilində görünən etibarlı mənbədə — məsələn, sifarişlər, rezervasiyalar və ya mesajlar ekranında — saxlanmalıdır. Push həmin dəyişiklik barədə xəbərdarlıqdır, tək məlumat mənbəyi deyil.
iOS-da bildiriş icazəsini istifadəçiyə dəyəri aydın olduqda soruşmaq daha məqsədəuyğundur. Android 13 və daha yeni versiyalarda qeyri-istisna bildirişlər üçün runtime POST_NOTIFICATIONS icazəsi tələb olunur. Buna görə ilk açılışda səbəbsiz pop-up əvəzinə, məsələn istifadəçi sifariş izləməni aktiv etdikdən və ya rezervasiya xatırladıcısını seçdikdən sonra izahlı seçim ekranı planlayın.
- Əməliyyat bildirişləri: ödəniş təsdiqi, rezervasiya dəyişməsi, çatdırılma statusu, təhlükəsizlik xəbərdarlığı.
- Faydalı xatırlatmalar: görüşə yaxın xəbərdarlıq, istifadəçinin seçdiyi servis vaxtı.
- Marketinq kampaniyaları: ayrıca razılıq, tezlik limiti, seqment və unsubscribe/parametr idarəsi.
Bildiriş payload-ında tam kart, şəxsiyyət və ya məxfi sifariş məlumatını yazmayın. Mümkünsə yalnız neytral mətn və tətbiqdaxili obyektə aparan identifikator göndərin; tətbiq açıldıqda backend-dən avtorizasiyalı məlumatı yeniləsin. Çatdırılma metrikası, açılma, deep link uğuru və hadisənin tətbiqdaxili təsdiqi ayrı ölçülməlidir. FCM köhnə gözləyən mesajı eyni collapse key ilə yeni mesajla əvəz edə bilər; buna görə hər status dəyişikliyini ayrıca “mütləq çatmalıdır” hadisəsi kimi model etməyin.
Proposal scope-u dəyişən minimum artefaktlar
İnteqrasiyalı tətbiq üçün keyfiyyətli təklif almaqdan əvvəl aşağıdakı paketi hazırlayın:
- sistem xəritəsi və hər məlumatın sahibi;
- prioritet 5–10 istifadəçi ssenarisi, o cümlədən istisnalar;
- mövcud API sənədi, sandbox çıxışı və texniki kontaktlar;
- məlumat obyektləri: istifadəçi, sifariş, rezervasiya, ödəniş, loyallıq və dəstək müraciəti;
- giriş rolları və hansı rolun hansı məlumatı görə və dəyişə bilməsi;
- ödəniş, refund və uzlaşdırma axını;
- bildiriş kataloqu: tetikleyici, auditoriya, mətn, deep link, prioritet və tezlik limiti;
- qəbul meyarları: “CRM-ə yazıldı” deyil, məsələn “uğurlu ödənişdən sonra sifariş maksimum müəyyənləşdirilmiş müddətdə təsdiqlənir və təkrar webhook ikinci sifariş yaratmır”.
Bunlar məhsulu lazımsız böyütmək üçün deyil. Əksinə, ilk versiyada hansı əlaqələrin real biznes dəyəri yaratdığını, hansının isə sonrakı mərhələyə keçirilməli olduğunu görmək üçündür. İstifadəçi axınları, icazə ekranları və statusların vizual izahı üçün UI/UX və məhsul dizaynı mərhələsi texniki qeyri-müəyyənliyi erkən aşkar edə bilər.
Nəticə: inteqrasiya planı mobil tətbiqin spesifikasiyasının əsas hissəsidir
CRM, ödəniş və push inteqrasiyası “buraxılışdan sonra qoşarıq” tipli əlavə deyil. Onlar istifadəçinin kim olduğunu, sifarişin real statusunu, hansı məlumatın etibarlı sayıldığını və müştəriyə hansı anda mesaj getdiyini müəyyən edir. Sistem sahibləri, API sərhədləri, identiklik, təhlükəsizlik, failure handling və uzlaşdırma əvvəlcədən qərarlaşdırıldıqda, mobil tətbiq daha real scope, daha az risk və dəstəklənə bilən backend ilə hazırlanır.
Bu suallara cavablarınız varsa — və ya onları mövcud CRM, ERP və ödəniş tərəfdaşlarınızla strukturlaşdırmaq lazımdırsa — POLADO ilə konsultasiya planlaşdırın. Komanda inteqrasiya xəritəsini, MVP sərhədini və iOS/Android tətbiqinin backend tələblərini birlikdə qiymətləndirə bilər.