Ödəniş düymədən ibarət deyil
Onlayn ödəniş inteqrasiyası istifadəçinin bir düymə ilə başqa səhifəyə keçməsindən daha geniş işdir. Mağaza sifariş məbləğini müəyyən edir, təminatçı ilə əməliyyat yaradır və nəticəni öz məlumatı ilə əlaqələndirir. İstifadəçiyə görünən ekranla sifarişin real ödəniş vəziyyəti birlikdə düşünülməlidir.
Layihəyə başlamazdan əvvəl uyğun ödəniş təminatçısı, hesabın açılması, tələb olunan müqavilə və sınaq mühitinin mövcudluğu dəqiqləşdirilir. Bu mərhələ üçün konkret təminatçının cari sənədi əsasdır. Ümumi məqalə bütün bank və xidmətlər üçün eyni API və komissiya şərti vəd etmir.
Məbləğin etibarlı mənbəyi
Məhsul qiyməti və endirim kimi məlumatı yalnız brauzerdən qəbul etmək olmaz. Sifarişin yekunu serverdə etibarlı məlumat əsasında hesablanmalıdır. Ödəniş nəticəsi də server tərəfdə təminatçı ilə yoxlanır; sifariş nömrəsi, məbləğ və valyuta uyğunlaşdırılır. Bu prinsiplər OWASP ödəniş inteqrasiyası bələdçisində izah edilir.
İstifadəçinin uğur səhifəsinə qayıtması təkbaşına ödənib statusunu vermək üçün kifayət etmir. Müştəri səhifəni bağlaya və ya bağlantını itirə bilər. Ona görə istifadəçi istiqaməti ilə təsdiqlənmiş əməliyyatın qeydi ayrı məsuliyyətlər kimi planlaşdırılır.
Status modeli
Sifariş, ödəniş və çatdırılma eyni status olmamalıdır. Sifariş mövcud ola, ödəniş hələ gözləyə və çatdırılma başlamaya bilər. Bu üç vəziyyəti bir “hazırdır” sahəsinə toplamaq panel və müştəri məlumatında qarışıqlıq yaradır.
Fərz edək ki, ödəniş cəhdi uğursuzdur, amma sifariş məlumatı artıq saxlanıb. Sistem müştərini təkrar cəhdə necə qaytaracaq? Yeni sifariş açılacaq, yoxsa mövcud sifariş üçün başqa cəhd yaradılacaq? Cavab əvvəlcədən verilsə, təkrarlanan sifariş və qeyri-müəyyən stok davranışını sınamaq daha asan olur.
Bildirişlər və təkrar emal
Ödəniş təminatçısı nəticəni server bildirişi ilə göndərə bilər. Bildirişin həqiqiliyi həmin xidmətin sənədinə əsasən yoxlanır. Eyni bildirişin təkrar gəlməsi eyni əməliyyatın iki dəfə yerinə yetirilməsi ilə nəticələnməməlidir. Hadisənin identifikatoru və sifarişlə əlaqəsi davamlı qeyddə saxlanılır.
Bu məsələni sadəcə “sorğu bir dəfə gələcək” fərziyyəsi ilə həll etmək olmaz. Təkrar cəhd, gecikmiş bildiriş və istifadəçinin brauzerə qayıtmaması kimi hallar planlaşdırılır. Daha geniş mövzu üçün OWASP webhook təhlükəsizliyi sənədi uyğun texniki istinaddır.
Sınaq siyahısı və görünən nəticə
Yoxlama yalnız uğurlu kart ödənişi ilə bitməməlidir. Ləğv, xəta, təkrar klik, gecikmiş nəticə və uyğun olmayan məbləğ ssenariləri də nəzərdən keçirilir. Müştəri hansı mərhələdə olduğunu aydın görməli, panel isə təsdiqlənmiş vəziyyəti göstərməlidir.
Boss Electronics kimi e-ticarət layihəsinin mövzusu məhsuldan sifarişə keçidin əhəmiyyətini göstərir. Bu nümunə həmin mağazanın konkret ödəniş təminatçısı barədə iddia deyil. İnteqrasiya qərarı hər layihədə faktiki xidmət və müqavilə əsasında verilir.
İş əhatəsi və sonrakı dəstək
API inteqrasiyası işi üçün sınaq girişləri, sənədlər və qəbul meyarları lazımdır. Canlı açarlar kodun ictimai hissəsinə yazılmamalı, qeydlərdə lazımsız həssas məlumat saxlanmamalıdır. Kimin xəta bildirişinə baxacağı və təminatçı dəyişəndə işi kimin izləyəcəyi də müəyyənləşdirilir.
Ödənişdən sonra sifarişin hazırlanması və çatdırılması ayrıca iş axınıdır. Buna görə sifariş idarəetməsi ilə birlikdə planlamaq lazımdır. Büdcə müqayisəsində yalnız düymənin görünüşünü deyil, təsdiq, vəziyyət, test və dəstək əhatəsini soruşun.
Praktik nümunə və qəbul
Əməliyyatın araşdırılması üçün sifariş və ödəniş cəhdinin əlaqəsi tapıla bilməlidir. Bir sifariş üçün bir neçə cəhd yarana bilər, amma müştəriyə eyni sifarişin nəticəsi aydın görünməlidir. İşçi panelində cəhdin qeydi ilə yekun vəziyyətin fərqi anlaşılmadıqda əməkdaş yanlış qərar verə bilər.
Fərz edək ki, brauzer nəticə gəlməzdən əvvəl bağlanıb, daha sonra təminatçı ödənişi təsdiqləyib. Sistem yalnız müştərinin qayıtmasına bağlı qurulubsa, vəziyyət qeyri-müəyyən qala bilər. Sınaq bu hadisəni və təkrar bildirişi əhatə etməlidir. Qeydlərdə əlaqə identifikatoru və yoxlama nəticəsi kifayət edə bilər; kartın həssas məlumatını saxlamaq bu araşdırmanın normal tələbi kimi qəbul edilmir. Bu nümunə niyə istifadəçi ekranı ilə server vəziyyətinin ayrıca planlaşdırıldığını göstərir.
Başlamazdan əvvəl yoxlayın
- Təminatçının aktual sənədi və sınaq hesabı mövcuddur.
- Məbləğ və məhsul məlumatı serverdə yoxlanır.
- Sifariş, ödəniş və çatdırılma vəziyyətləri ayrıdır.
- Təkrar bildiriş eyni işi ikinci dəfə icra etmir.
- Uğur, xəta, ləğv və gecikmə ssenariləri sınanır.
Tez verilən suallar
Uğur səhifəsi ödənişi təsdiqləyir?
Təkbaşına yox. Server nəticəni təminatçı ilə yoxlayıb sifariş, məbləğ və valyuta ilə uyğunlaşdırmalıdır.
Hər layihəyə eyni inteqrasiya tətbiq olunur?
Xeyr. Xidmətin API-si, təhlükəsizlik mexanizmi, müqaviləsi və sifarişin iş axını nəzərə alınır.
Mövzunu davam etdirin
İnteqrasiyanı mağaza büdcəsi və ümumi sifariş prosesi daxilində qiymətləndirin.
Layihəniz üçün hesab, webhook və qəbul sınaqlarının əhatəsini ödəniş sistemlərinin inteqrasiyası xidmətində dəqiqləşdirə bilərsiniz.
