Saytda Onlayn Ödəniş Sistemi Necə Qurulur? Azərbaycanda Kart Ödənişinin İnteqrasiyası

Sayt hazırdır, məhsullar yüklənib, dizayn bəyənilib. Amma müştəri səbətə məhsul atandan sonra bir sual qalır: pulu necə qəbul edəcəksiniz? Bəzi bizneslər hələ də "sifariş ver, kuryerə nağd ödə" modelindədir. Bu işləyir, amma onlayn ödəniş olmayanda sifarişlərin bir hissəsi yarıda qalır, çünki müştəri kartla dərhal ödəmək istəyir.

Onlayn ödəniş sistemi qurmaq göründüyündən sadədir, amma bir neçə yerdə səhv etmək bahalı başa gələ bilər. Bu yazıda prosesin necə işlədiyini, Azərbaycanda hansı yolların olduğunu, texniki və təhlükəsizlik məqamlarını sadə şəkildə izah edəcəyik.

Onlayn Ödəniş Necə İşləyir?

İstifadəçi "Ödə" düyməsini basanda kart məlumatını sizin sayta yox, bankın və ya ödəniş təşkilatının təhlükəsiz səhifəsinə daxil edir. Bu, bütün prosesin ən vacib prinsipidir. Sadə axın belədir:

1. Müştəri səbəti təsdiq edir, sistem sifariş yaradır və statusunu "ödəniş gözlənilir" qoyur.
2. Sayt ödəniş təşkilatına sorğu göndərir: məbləğ, sifariş nömrəsi, qayıdış ünvanı.
3. Müştəri ödəniş səhifəsinə yönləndirilir və kart məlumatını orada daxil edir.
4. Lazım olsa, 3D Secure təsdiqi keçirilir (bank SMS ilə və ya tətbiqdə təsdiq istəyir).
5. Ödəniş təşkilatı nəticəni sizin sistemə bildirir.
6. Sistem sifarişin statusunu yeniləyir: uğurlu, uğursuz və ya ləğv edilmiş.
7. Müştəri saytın nəticə səhifəsinə qaytarılır.

Beləliklə kart nömrəsi sizin serverdən keçmir. Bu həm təhlükəsizlik, həm də məsuliyyət baxımından böyük üstünlükdür.

Azərbaycanda Hansı Yollar Var?

Saytda kart ödənişi qəbul etmək üçün əsasən iki istiqamət var.

1. Bankın internet ekvayrinq xidməti

Bəzi banklar mağazalara birbaşa kartla ödəniş qəbul etmək xidməti təklif edir. Məsələn, PAŞA Bank-ın "Elektron ticarət" xidməti saytda və ya mobil tətbiqdə POS terminalsız kart ödənişi qəbul etməyə imkan verir. Bankın səhifəsində bildirilir ki, xidmət Visa, Visa Electron, MasterCard və Maestro kartlarını dəstəkləyir, 3D Secure təhlükəsizlik xidməti təklif olunur, təkrarlanan ödənişlər, kart məlumatının təhlükəsiz saxlanması, tam və ya qismən geri qaytarma imkanları mövcuddur.

Bank yanaşmasının üstünlüyü bankla birbaşa müqavilə və pulun birbaşa hesaba daxil olmasıdır. Mənfi tərəfi isə hər bank üçün ayrıca müqavilə və ayrıca texniki inteqrasiya tələb oluna bilməsidir.

2. Ödəniş aqreqatoru

Aqreqator bir neçə ödəniş üsulunu bir API arxasında birləşdirən xidmətdir. Məsələn, Epoint kiçik və orta bizneslər üçün rəqəmsal ödəniş aqreqatoru kimi təqdim olunur və saytında Azərbaycan Mərkəzi Bankı tərəfindən lisenziyalaşdırıldığı bildirilir. Saytdakı məlumata görə, Visa, Visa Electron, Mastercard və Maestro kartlarını, Apple Pay və Google Pay ödənişlərini, təkrarlanan ödənişləri, taksit ödənişlərini, QR kod və invoys ödənişlərini dəstəkləyir. İnteqrasiya üçün API və WooCommerce, OpenCart kimi platformalar üçün hazır skriptlər təklif olunur.

Aqreqatorun üstünlüyü sürətli başlanğıcdır, xüsusən də kiçik biznes üçün. Seçərkən isə komissiya, pulun hesaba keçmə müddəti və dəstək şərtlərini mütləq müqayisə etmək lazımdır.

Meyar	Bankın ekvayrinqi	Ödəniş aqreqatoru
Müqavilə	Birbaşa bankla	Aqreqatorla
Başlanğıc sürəti	Sənəd və təsdiq prosesindən asılıdır	Adətən daha sürətli
Ödəniş üsulları	Bankın dəstəklədiyi kartlar və xidmətlər	Bir neçə üsul bir yerdə
İnteqrasiya	Bankın texniki sənədinə uyğun	Vahid API və hazır modullar
Uyğun olduğu biznes	Daha böyük və oturuşmuş bizneslər	Kiçik və orta bizneslər, startaplar

Komissiya dərəcələri, şərtlər və dəstəklənən üsullar dəyişə bilər. Buna görə qərar verməzdən əvvəl həmin təşkilatın rəsmi şərtlərini və ya satış komandası ilə yazışmanı yoxlayın. Üçüncü tərəf məqalələrdəki rəqəmlərə əsaslanmayın.

İnteqrasiyanın Texniki Hissəsi

Texniki cəhətdən ödəniş inteqrasiyası adətən API inteqrasiyasıdır. Əsas mərhələlər belədir.

Sifarişin yaradılması

Ödənişdən əvvəl sizin sistemdə mütləq sifariş yaranmalıdır. Hər sifarişin unikal nömrəsi və gözlənilən məbləği olmalıdır. Ödəniş nəticəsi gələndə sistem bu nömrə ilə sifarişi tapıb yeniləyir.

Callback və ya webhook

Ödəniş nəticəsi iki yolla gəlir: müştəri saytınıza qayıdanda və ödəniş təşkilatının sizin serverə göndərdiyi ayrıca bildirişlə (callback və ya webhook). Ən vacib qayda: sifarişin ödənmiş sayılması qərarı müştərinin brauzerinə yox, serverə gələn təsdiqlənmiş bildirişə əsaslanmalıdır. Çünki istifadəçi qayıdış səhifəsini bağlaya bilər, internet kəsilə bilər və ya ünvanı əl ilə dəyişə bilər.

İmza yoxlaması

Ödəniş təşkilatları adətən bildirişi gizli açarla imzalayır. Sizin server bu imzanı yoxlamalıdır. Yoxlama olmasa, kimsə saxta "ödəniş uğurlu oldu" sorğusu göndərib pulsuz sifariş ala bilər. Bu, ən çox rast gəlinən təhlükəsizlik boşluqlarından biridir. Bu mövzuda API təhlükəsizliyi yazımızı da oxuya bilərsiniz.

Məbləğin yoxlanması

Bildirişdəki məbləğ sifarişdəki məbləğlə eyni olmalıdır. Məbləği müştərinin göndərdiyi sorğudan götürmək olmaz, həmişə serverdəki sifarişdən oxunmalıdır.

Təkrar bildirişlər

Ödəniş təşkilatı eyni bildirişi bir neçə dəfə göndərə bilər. Sistem bunu düzgün idarə etməlidir: sifariş artıq ödənmiş statusdadırsa, ikinci bildiriş sifarişi təkrar emal etməməlidir (idempotentlik).

3D Secure Nədir və Niyə Vacibdir?

3D Secure kart sahibinin ödənişi əlavə təsdiqlə (məsələn, bankdan gələn birdəfəlik kod) təsdiqləməsini tələb edən təhlükəsizlik qatıdır. Bu, kartın başqası tərəfindən istifadəsi riskini azaldır. İnteqrasiyada onu ayrıca yazmağa ehtiyac olmur, ödəniş təşkilatı bunu öz səhifəsində idarə edir. Sizin işiniz uğursuz təsdiq halını da düzgün emal etməkdir.

PCI DSS və Kart Məlumatı

PCI DSS kart məlumatını emal edən təşkilatlar üçün təhlükəsizlik standartıdır. Ən sadə qayda belədir: kart nömrəsini, CVV kodunu və bitmə tarixini heç vaxt öz serverinizdə və ya verilənlər bazanızda saxlamayın. Kart məlumatı yalnız ödəniş təşkilatının səhifəsində daxil edilirsə, sizin üzərinizə düşən yük xeyli azalır. Loglara da kart məlumatı düşməməlidir, bu barədə monitoring və logging yazımızda qeyd etmişdik.

Əlavə olaraq, saytın bütün səhifələri HTTPS ilə işləməlidir.

Sifariş Statusları

Ödəniş sisteminin düzgün qurulması üçün sifarişin statusları aydın olmalıdır:

• Gözlənilir: sifariş yaranıb, ödəniş hələ tamamlanmayıb.
• Ödənilib: təsdiqlənmiş bildiriş gəlib, məbləğ uyğundur.
• Uğursuz: ödəniş rədd edilib və ya 3D Secure keçilməyib.
• Ləğv edilib: müştəri ödəniş səhifəsini tərk edib və vaxt bitib.
• Geri qaytarılıb: tam və ya qismən refund edilib.

Gözlənilən statusda uzun qalan sifarişləri avtomatik yoxlayan və ya ləğv edən mexanizm də lazımdır. Əks halda stok boş yerə bloklanmış qala bilər.

Geri Qaytarma (Refund) və Mühasibatlıq

Ödəniş qəbulu işin yarısıdır. Müştəri məhsulu qaytaranda pulun geri qayıtması, ödənişlərin mühasibatlıq uçotu ilə uyğunlaşdırılması (reconciliation) və hesabatlar da planlaşdırılmalıdır. Hər ödənişin sizin sistemdə, ödəniş təşkilatında və bank hesabında üst-üstə düşdüyünü yoxlamaq lazımdır. Bu işlər avtomatlaşdırılmasa, aylıq uçot əl ilə çoxlu vaxt aparır. Mühasibatlıq və ERP ilə inteqrasiya mövzusuna B2B e-ticarət yazımızda da toxunmuşuq.

Test Etmə: Production-dan Əvvəl

Ödəniş sistemini birbaşa real pulla yoxlamaq düzgün deyil. Ödəniş təşkilatları adətən ayrıca test sistemi təqdim edir. Staging-də bu ssenariləri yoxlamaq lazımdır:

• Uğurlu ödəniş
• Rədd edilmiş ödəniş
• 3D Secure təsdiqinin keçilməməsi
• İstifadəçinin ödəniş səhifəsini bağlaması
• Eyni bildirişin iki dəfə gəlməsi
• Saxta və ya imzası səhv olan bildiriş
• Qismən və tam refund
• Bildirişin gec çatması

Production-a çıxandan sonra isə ödənişlərin uğur nisbətinə daim baxmaq lazımdır. Birdən uğursuz ödənişlərin artması çox vaxt texniki problemin ilk əlamətidir. Burada proactive monitoring faydalı olur.

Ən Çox Edilən Səhvlər

• Ödənişi brauzerə güvənərək təsdiqləmək: Qayıdış səhifəsinə gələn parametrə əsasən sifarişi ödənmiş saymaq saxta ödənişə yol açır.
• İmzanı yoxlamamaq: Callback-in həqiqətən ödəniş təşkilatından gəldiyini təsdiqləmək lazımdır.
• Məbləği müştəridən götürmək: Qiymət həmişə serverdə hesablanmalıdır.
• Təkrar bildirişi nəzərə almamaq: Eyni sifariş iki dəfə emal olunur, stok və ya bonus səhv hesablanır.
• Gözləmədə qalan sifarişləri təmizləməmək: Stok bloklanır, hesabat qarışır.
• Test etmədən Production-a çıxmaq: Ən bahalı səhvlər real müştəri ödənişində üzə çıxır.
• Şərtləri öyrənmədən seçmək: Komissiya, pulun hesaba keçmə müddəti, geri qaytarma qaydaları və dəstək müqavilədən əvvəl aydınlaşdırılmalıdır.
• Yalnız bir ödəniş yolundan asılı olmaq: Provayderdə problem olanda satış dayanır. Mümkünsə ehtiyat variantı düşünün.

Necə Başlamaq Olar?

1. Biznes növünüzü müəyyən edin: fiziki şəxs sahibkar, hüquqi şəxs, ölçü və dövriyyə.
2. Bir neçə provayderin rəsmi şərtlərini müqayisə edin: komissiya, qoşulma şərti, hesaba keçmə müddəti, dəstəklənən kartlar və cüzdanlar.
3. Sifariş və status məntiqini əvvəlcədən layihələndirin.
4. Provayderin texniki sənədinə əsasən inteqrasiyanı Staging-də qurun.
5. Bütün ssenariləri (uğurlu, uğursuz, təkrar, saxta) test edin.
6. Production-a keçin və ilk günlərdə ödənişləri əl ilə də yoxlayın.
7. Monitoring və hesabat qurun.

Ödəniş sistemi sadə modul kimi görünsə də, sifariş məntiqi, stok, mühasibatlıq və təhlükəsizliklə sıx bağlıdır. Mürəkkəb biznes prosesləri olan layihələrdə bu hissə adətən fərdi proqram təminatı kimi planlaşdırılır. Satışları artırmaq üçün digər addımlara e-ticarət saytı ilə satışları artırmaq yazımızdan baxa bilərsiniz.

Tez-tez Verilən Suallar

Kiçik onlayn mağaza üçün hansı yol daha uyğundur?
Çox vaxt aqreqator daha sürətli başlanğıc verir, çünki hazır modullar və vahid API olur. Dövriyyə böyüdükcə bankla birbaşa müqaviləni də müqayisə etmək olar. Qərar verməzdən əvvəl hər iki yolun şərtlərini rəsmi mənbədən yoxlayın.

Kart məlumatını saytda saxlamaq olarmı?
Xeyr, bunu etməməlisiniz. Kart məlumatı ödəniş təşkilatının səhifəsində daxil edilməli və sizin serverinizdən keçməməlidir.

Ödənişi hansı hadisə təsdiqləyir?
Serverə gələn və imzası yoxlanılmış bildiriş. Müştərinin saytınıza qayıtması tək başına ödənişin uğurlu olduğunu göstərmir.

Apple Pay və Google Pay əlavə etmək mümkündürmü?
Bu, seçdiyiniz provayderdən asılıdır. Bəzi aqreqatorlar bunu dəstəkləyir, amma hər təşkilatın şərtini ayrıca yoxlamaq lazımdır.

İnteqrasiya nə qədər vaxt aparır?
Sadə mağaza üçün hazır modulla bir neçə gün, fərdi sifariş və mühasibatlıq məntiqi olan sistem üçün isə daha uzun. Müddət əsasən biznes prosesinin mürəkkəbliyindən asılıdır.

Ödəniş uğursuz olanda müştəriyə nə göstərmək lazımdır?
Aydın mesaj və təkrar cəhd imkanı. "Xəta baş verdi" yazmaq əvəzinə səbəbi (məsələn, təsdiq keçilməyib) və növbəti addımı göstərmək müştərini itirməmək üçün daha yaxşıdır.

Nəticə

Onlayn ödəniş sistemi sadəcə "kart qəbul edən düymə" deyil. Düzgün qurulmuş axın sifariş yaradır, ödənişi təhlükəsiz yönləndirir, nəticəni imza ilə təsdiqləyir, statusları yeniləyir, geri qaytarmanı və uçotu dəstəkləyir. Azərbaycanda həm bankların ekvayrinq xidməti, həm də ödəniş aqreqatorları var, seçim biznesin ölçüsündən, şərtlərdən və texniki ehtiyacdan asılıdır. Əsas qayda isə dəyişmir: kart məlumatını saxlamayın, ödənişi yalnız serverə gələn təsdiqlə qəbul edin və Production-a çıxmazdan əvvəl bütün ssenariləri test edin.

Saytınıza onlayn ödəniş inteqrasiyası qurmaq və ya mövcud sistemi yoxlamaq istəyirsinizsə, Crocusoft komandası ilə əlaqə saxlayın. Biznes prosesinizi birlikdə nəzərdən keçirib uyğun yolu müəyyən edək.