Ödəniş sifarişin vəziyyəti ilə əlaqələndirilir
Müştərinin ödəniş səhifəsinə keçməsi hələ sifarişin ödənildiyi demək deyil. Sayt ödəniş cəhdini yaratmalı, provayderdən təsdiqlənmiş nəticəni almalı və sifarişin statusunu razılaşdırılmış qaydaya uyğun dəyişdirməlidir. Xidmət bu ardıcıllığın mövcud mağaza, xidmət saytı və ya fərdi sistem üçün hazırlanmasına yönəlir.
İnteqrasiya yeni satış kanalı açan biznesə, əl ilə ödəniş yoxlayan komandaya və mövcud ödəniş axınını qaydaya salmaq istəyən layihəyə uyğun qiymətləndirilir. Məqsəd texniki ödəniş axınının işləməsidir. Provayder hesabının təsdiqi, komissiyalar və maliyyə hesablaşması seçilən xidmətin şərtlərinə görə müəyyənləşdirilir.
Başlamazdan əvvəl provayder və müqavilə dəqiqləşdirilir
Sifarişçi bank və ya ödəniş provayderini seçir, öz adına hesab və tələb olunan müqaviləni hazırlayır. Texniki iş üçün sənədləşmə, sınaq imkanı, verilən girişlər və icazəli əməliyyatlar yoxlanır.
- Valyuta, sifariş məbləği, məhsul və ya xidmətin ödəniş qaydası.
- Ödənişdən əvvəl və sonra yaranacaq sifariş statusları.
- Uğursuz, gözləyən, ləğv edilən və uğurlu cəhdlərin davranışı.
- Provayderin API, webhook və sınaq mühiti imkanları.
- Geri qaytarma, qismən ödəniş və təkrarlanan ödəniş ehtiyaclarının ayrıca siyahısı.
Mağaza özü hələ hazır deyilsə, məhsul və sifariş axını onlayn mağazanın hazırlanması ilə birlikdə planlaşdırılır. Təkcə ödəniş düyməsini əlavə etmək səbət, çatdırılma və müştəri məlumatlarının idarəsini avtomatik yaratmır.
Server təsdiqi və təkrar sorğular
Brauzerdə görünən uğur səhifəsi yekun təsdiq mənbəyi seçilmir. Nəticə provayderin dəstəklədiyi server üsulu ilə yoxlanır, sifariş və məbləğlə tutuşdurulur. İmzalı webhook varsa, imza yoxlaması tətbiq olunur. Stripe-ın webhook sənədi belə bildirişlərin yoxlanması və təkrar çatdırılmasının nəzərə alınması üçün texniki nümunədir; konkret inteqrasiya seçilmiş provayderin qaydalarına əsaslanır.
Eyni bildirişin yenidən gəlməsi ikinci dəfə sifariş təsdiqi və ya əlavə əməliyyat yaratmamalıdır. Təkrar sorğu və hadisələr üçün identifikatorlar və tətbiq səviyyəsində nəzarət planlaşdırılır. Provayder dəstəklədikdə idempotent sorğu mexanizmi istifadə edilir. Bu axın ümumi API inteqrasiyası ilə eyni giriş və xəta idarəetmə prinsipləri əsasında hazırlanır.
Kart forması və məlumatların əhatəsi
Mümkün olduqda kart girişinin provayder tərəfindən təqdim edilən ödəniş səhifəsində aparılması seçimi qiymətləndirilir. İstifadə ediləcək üsul mövcud sayt və provayder imkanlarına görə razılaşdırılır. Kart nömrələrinin tətbiq serverində saxlanması standart iş əhatəsinə daxil edilmir. PCI DSS üzrə məsuliyyətlər seçilən inteqrasiya üsuluna görə ayrıca dəqiqləşdirilir; texniki qoşulma uyğunluq sertifikatı kimi təqdim edilmir.
Gizli API açarları ictimai kodda və brauzer skriptlərində saxlanmır. Diaqnostika üçün lazım olan qeydlərin tərkibi müəyyən edilir, həssas məlumatların jurnal fayllarına düşməməsi nəzərə alınır. Administrator ödəniş statusunu və əlaqəli sifarişi görə bilməlidir; konkret ekranlar mövcud panelin imkanlarına uyğun razılaşdırılır.
Quraşdırma və qəbul yoxlamaları
Əvvəl sınaq mühitində ödənişin yaradılması, uğurlu və uğursuz nəticə, istifadəçinin geri qayıtmaması və təkrar bildiriş yoxlanır. Provayder dəstəkləyirsə gecikən nəticə ssenarisi də nəzərə alınır. Sifariş statusu, bildiriş və administrator görünüşü eyni sınaq üzrə tutuşdurulur. Canlı rejimə keçid sifarişçinin və provayderin hazırlığından sonra ayrıca razılaşdırılır.
Geri qaytarma ilkin əhatəyə daxil edilirsə, tam və ya qismən qaytarma, səlahiyyət və status izlənməsi ayrıca qəbul meyarı alır. Prosesin biznes tərəfi haqqında onlayn ödəniş inteqrasiyası məqaləsində əlavə izah var. CRM-də qeyd və ya mesaj tələb olunursa, SMS bildirişləri ayrıca tapşırıq kimi qoşula bilər.
Qiymətləndirmə və tez-tez verilən suallar
Dəyərə mövcud kodun vəziyyəti, provayder sənədləri, ödəniş axınları, panel dəyişiklikləri və sınaq imkanları təsir edir. Abunə, komissiya və müqavilə ödənişləri proqramlaşdırma əməyindən ayrıdır. Təhvildə status xəritəsi, sazlama məsuliyyətləri, sınaq nəticələri və açıq məhdudiyyətlər göstərilir.
İstənilən provayderi qoşmaq mümkündür?
Əvvəl provayderin uyğun API-si, hesabın təsdiqi və saytın tələbləri yoxlanır. İmkan və məhdudiyyətlər sənədlərə əsasən müəyyənləşdirildikdən sonra iş təsdiqlənir.
Abunə ödənişi və geri qaytarma da daxildirmi?
Yalnız ayrıca razılaşdırıldıqda. Birdəfəlik ödəniş, təkrarlanan ödəniş və geri qaytarma fərqli qaydalar və sınaqlar tələb edir.
Ödəniş uğurludursa, sifariş dərhal tamamlanır?
Bu, biznes qaydasından asılıdır. Ödəniş təsdiqi, anbar yoxlaması və xidmətin icrası ayrı mərhələlər ola bilər; hər statusun mənası əvvəlcədən yazılır.
