İnternet mağaza hostinqi tam iş dövrünə görə seçilir: alıcı məhsulu tapır, sifarişi rəsmiləşdirir, komanda isə icra üçün düzgün məlumat alır. Kataloq və ana səhifə sistemin yalnız bir hissəsidir. Bu material seçilmiş CMS-dən asılı olmadan InterServer-də yerləşdirmə üçün biznes tələblərini toplamağa və texniki mütəxəssisə ötürməyə kömək edir.
İtirilməməli əməliyyatları təsvir edin
Alıcı və əməkdaş üçün məcburi əməliyyatları yazın: axtarış, variant seçimi, rəsmiləşdirmə, ödəniş təsdiqi, sifariş dəyişikliyi və uçot sisteminə ötürmə. Hər əməliyyatın nəticəsinin harada saxlandığını göstərin.
Siteman sürətli sayt vədindən deyil, müşahidə edilən vəziyyətdən başlamağı tövsiyə edir. Təşəkkür səhifəsi açılıb sifariş saxlanmayıbsa, ssenari tamamlanmayıb. Hər vacib mərhələnin yoxlama sahibi və xəta aşkarlama üsulu olmalıdır. Bunlar qəbul meyarına daxil edilməlidir.
Kataloqu müxtəlif məlumatların dəsti kimi qiymətləndirin
Məhsulları, variantları, şəkilləri, qiymətləri, qalıqları və əlavə xüsusiyyətləri yazın. Nəyin əl ilə, nəyin idxaldan dəyişdiyini dəqiqləşdirin. Kart sayı şəkil ölçüsünü və axtarışın mürəkkəbliyini göstərmir.
Yenilənmə tezliyini və uzun əməliyyatları müəyyən edin. İdxal alış və administrator işi ilə üst-üstə düşə bilər. Resursu yalnız məhsul sayına görə seçməyin. Texniki qiymətləndirmə konkret platformanın davranışını və əlavələrini nəzərə almalıdır. Eyni ölçülü kataloqlar müxtəlif iş yarada bilər.
Sifarişi bildirişdən ayırın
Əsas sifariş reyestrini və ödənişlə əlaqəni müəyyən edin. Menecer məktubu işə kömək edə bilər, lakin saxlanmanın yeganə sübutu olmamalıdır. Komandanın ödənişlə mağaza statusu arasındakı fərqi necə tapdığını yazın.
Təkrar sorğu və ödəniş bildirişi üçün razılaşdırılmış emal qaydası lazımdır. Təkrar cəhd nəzarətsiz yeni sifariş yaratmamalıdır. Bu qaydanı tətbiq həyata keçirir. Hostinq mühit verir, amma düzgün biznes məntiqini avtomatik əlavə etmir. Proqramçı bu davranışı təsdiqləməlidir.
Xarici inteqrasiyaların xəritəsini qurun
Ödəniş provayderini, qalıq uçotunu, çatdırılmanı, CRM-i və digər vacib sistemləri sadalayın. Hər biri üçün bağlantı üsulu, məsul şəxs və müvəqqəti dayanma davranışı lazımdır. Məxfi açarları ümumi texniki tapşırıqda göstərməyin.
Proqramçı seçilmiş xidmətin bağlantı və proseslərə uyğunluğunu təsdiqləməlidir. Fon emalçısı lazımdırsa, işə salınmasını və izlənməsini dəqiqləşdirin. Dayanmış mübadilənin əl ilə bərpası real ödənilmiş sifarişlər yaranmamış təsvir edilməlidir. Kimin müdaxilə edəcəyini əvvəlcədən təyin edin.
Mühiti platforma tələbi ilə yoxlayın
CMS-in aktual tələblərini alın: versiyalar, baza, əlavələr, fon tapşırıqları və hüquqlar. InterServer shared yalnız uyğunluq və yük təsdiqləndikdə seçilir. VPS və dedicated sistem nəzarətinə və resursa konkret ehtiyac olduqda qiymətləndirilir.
Bir platformanın tələbini bütün mağazalara aid etməyin. Hazır quraşdırıcı seçilmiş ödəniş modullarının uyğunluğunu təsdiqləmir. Yenilənmə və lisenziyaların sahibi də olmalıdır. Hostinq müqayisəsi tətbiqin təsdiqlənmiş konfiqurasiyasına əsaslanmalıdır. Əlavə dəyişəndə tələblərə yenidən baxmaq lazım ola bilər.
Əməkdaş hüquqlarını və məlumat girişini nəzərə alın
Kataloq redaktəsini, sifariş işini, geri ödəmələri və texniki idarəni ayırın. Məhsul təsvirini dəyişən əməkdaşa adətən server hüququ və ödəniş açarı lazım deyil. Girişin verilməsini və ləğvini razılaşdırın.
Alıcı məlumatının qorunmasını və diaqnostik məlumatın saxlanmasını yoxlayın. Şəxsi məlumatı açıq jurnal və keçidə yazmayın. OWASP tövsiyələrində istifadəçinin tanınması ilə konkret əməliyyat icazəsi fərqlənir. Bu yoxlamalar yalnız hostinq panelinə deyil, tətbiqə də aiddir. Qəbul zamanı fərqli rolları sınayın.
Bərpanı yeni sifarişlərə görə planlaşdırın
Qəbul edilən məlumat itkisini və işə qayıtma vaxtını yazın. Standard üçün göstərilən həftəlik nüsxə gündəlik dəyişən mağazanın müdafiəsini təkbaşına müəyyən etmir. VPS və dedicated üçün avtomatik nüsxəni standart fərz etmək olmaz.
Tətbiq, baza və yükləmələrin uyğun vəziyyətini saxlayın. Bərpa seçilmiş nöqtədən sonrakı sifarişləri nəzərə almalıdır. Sınağı işlək mağazadan ayrı, real ödəniş və bildiriş göndərmədən aparın. Sahib geri dönüşün nəticəsini bilməlidir. Bu qərar yalnız texniki fayl əvəzləməsi deyil.
Seçim hazırlığı üçün şərti nümunə
Fərz edək ki, mağaza kataloqu uçot sistemindən alır, menecer isə ödənilmiş sifarişləri CRM-də işləyir. Əvvəl qiymət və qalıq mənbələri, ödəniş təsdiqi və mübadilənin təkrar qaydası müəyyən edilir. Sonra proqramçı prosesləri təsvir edir.
Bu məlumatla yerləşdirmə və texniki xidmət müqayisə olunur. Açılışdan əvvəl test sifarişi məhsul seçimindən əməkdaşın məlumatı almasına qədər yoxlanır. Bu tələblərin təşkili nümunəsidir, tarifin performansı və istənilən alıcı sayının emalı zəmanəti deyil.
Mağazanın tam iş sxemini təqdim edin
WooCommerce xüsusiyyətləri ayrıca izah olunur: WooCommerce hostinqi üçün yoxlama meyarları. Öz API tələbləri: API hostinqi üçün backend hazırlığı və yoxlanması. Hostinq təkliflərinə baxın.
Yerləşdirmə üçün hostinq seçimi xidmətindən istifadə edin. CMS-i, əməliyyatları, inteqrasiyaları, məlumat artımı proqnozunu və texniki xidmət sahibini hazırlayın. Razılaşmadan sonra qəbul meyarlarını saxlayın. Onlar yeni versiyanı yoxlamağa və resurs ehtiyacını tətbiq xətasından ayırmağa kömək edir. Sonrakı dəyişikliklərdə eyni meyarlara əsaslanın.
Mənbələr və yoxlama tarixi
3 noyabr 2026-cı ildə yoxlanılıb:
OWASP giriş hüquqları təlimatı
Biznes yoxlamaları və şərti nümunə Siteman tövsiyələridir. CMS və inteqrasiya tələblərini öz konfiqurasiyanız üçün təsdiqləyin.