1. Provayderdən dəqiqləşdiriləcək məlumatlar
Ödəniş qəbuluna uyğunluq, müqavilə, komissiya və hesablaşma şərtləri seçdiyiniz provayderlə təsdiqlənir. Bu yazı hüquqi və ya maliyyə məsləhəti deyil; texniki brief üçündür. Universal sənəd siyahısı vermək düzgün olmaz, çünki biznes və provayder tələbləri fərqlənir.
- İstifadə edəcəyiniz CMS və ya xüsusi backend dəstəklənirmi?
- Rəsmi modul və aktual API sənədi varmı?
- Test mühiti, test girişləri və status yoxlama üsulu necə təqdim olunur?
- Ləğv və geri ödəniş texniki olaraq hansı üsulla həyata keçirilir?
- Canlıya keçid üçün hansı texniki yoxlamalar tələb olunur?
2. Hazır modul yoxsa xüsusi inteqrasiya?
Məsələn, Epoint-in rəsmi məlumatında API ilə yanaşı WooCommerce və OpenCart üçün həllər qeyd olunur. Bu, əvvəlcə uyğun hazır modulun olub-olmadığını yoxlamağa əsas verir. Modulun cari versiya ilə işləməsi və saytın sifariş qaydalarını qarşılaması ayrıca sınanmalıdır.
Xüsusi backend, qeyri-standart sifariş və bir neçə sistem arasında status paylaşımı olduqda əlavə hazırlama lazım ola bilər. Provayder seçimi texniki uyğunluqla yanaşı biznesin öz şərtlərinə əsaslanmalıdır; burada heç bir provayder üçün təsdiq və ya üstünlük zəmanəti verilmir.
3. Sifariş və ödəniş cəhdini ayırın
Bir sifariş üzrə bir neçə ödəniş cəhdi ola bilər. Cəhdin uğursuzluğu sifarişin itməsi ilə nəticələnməməlidir. Ödəniş səhifəsindən brauzerin geri qayıtması təkbaşına uğur təsdiqi kimi istifadə edilməməlidir. Status provayderin sənədləşdirdiyi server üsulu ilə yoxlanır.
Mühəndislik tövsiyəsi olaraq status keçidlərini əvvəlcədən yazın: gözləyir, təsdiqlənib, uğursuzdur və lazım olan digər vəziyyətlər. Hansı statusun kim tərəfindən dəyişdirilə biləcəyi və operator müdaxiləsinin necə qeydə alınacağı müəyyən olmalıdır.
4. Testdə yalnız uğurlu əməliyyat kifayət etmir
- İstifadəçi əməliyyatı ləğv edir və ya brauzeri bağlayır.
- Server bildirişi gecikir; istifadəçi səhifəni təkrar açır.
- Eyni bildiriş iki dəfə gəlir: ikinci sifariş və ya təkrar xidmət yaranmır.
- Sifariş məbləği ilə təsdiqlənmiş məbləğin uyğunluğu yoxlanır.
- Provayder əlçatmaz olanda istifadəçiyə səhvən «ödənildi» göstərilmir.
- Jurnallarda gizli açar və kart məlumatı saxlanmır.
5. Canlıya keçid və dəstək məsuliyyəti
Test və canlı girişlər ayrılmalı, canlı konfiqurasiya yalnız razılaşdırılmış keçid zamanı dəyişdirilməlidir. Problemi kim izləyəcək, kim provayderlə əlaqə saxlayacaq və istifadəçinin sorğusuna kim cavab verəcək — bu üç rol aydın olmalıdır. Real ödəniş sınağı tələb olunursa, məbləğ və əməliyyat ayrıca səlahiyyətlə aparılır.
Onlayn ödəniş inteqrasiyası xidməti üçün sayt ünvanını, CMS/backend məlumatını və seçilmiş provayderi bildirin. İlk mesajda gizli açar göndərməyin. Daha ümumi arxitektura üçün API və ödəniş inteqrasiyası bələdçisinə baxın.