Məqalə
praktik bələdçiYenilənib: · Wapp.az
Ödəniş düyməsinin bank səhifəsini açması inteqrasiyanın tamamlandığını göstərmir. Sifarişin statusu, ödəniş təsdiqi və müştəriyə verilən cavab uyğun işləməlidir. Aşağıdakı yoxlamaları seçilən provayderin sınaq mühitində, onun sənədləşməsinə uyğun aparmaq üçün qəbul siyahısı kimi istifadə edin. Bu məqalə konkret bankın hazır inteqrasiyasını vəd etmir.
Başlamazdan əvvəl
Ödəniş məbləğinin və valyutanın hansı mənbədən götürüldüyünü, sifarişlə əməliyyatın necə əlaqələndirildiyini müəyyənləşdirin. Biznesdən provayder seçimini, hesabın aktivliyini və lazım olan funksiyaları təsdiqlətmək lazımdır. Canlı və sınaq mühitinin girişləri qarışdırılmamalıdır. Sınaq kartı və test əməliyyatları yalnız provayderin müəyyən etdiyi mühitdə istifadə edilir.
Yoxlanacaq altı vəziyyət
- Uğurlu ödəniş: sifarişin məbləği uyğun gəlir və müştəri təsdiq görür.
- İmtina: sifariş ödənilmiş sayılmır, müştəri anlaşılan mesaj alır.
- Yarımçıq proses: müştəri pəncərəni bağlayır; komanda statusu yoxlaya bilir.
- Gecikmiş təsdiq: nəticə sonradan gəlir, aralıq vəziyyət düzgün göstərilir.
- Təkrar bildiriş: eyni ödəniş ikinci sifariş və ya ikinci icra yaratmır.
- Statusların fərqi: provayderdə uğurlu görünən əməliyyatla sayt qeydi tutuşdurulur.
Brauzerə qayıdış və server təsdiqi
Müştərinin təşəkkür səhifəsini açması təkbaşına ödəniş sübutu deyil. Təsdiqin yoxlanması provayderin server bildirişi və ya status sorğusu qaydasına uyğun qurulmalıdır. Məsələn, Stripe webhook sənədi bildirişin mənbəyinin yoxlanmasını, təkrar hadisələrin nəzərə alınmasını və çatdırılma davranışını izah edir. Bu, arxitektura nümunəsidir; bank seçimi və xidmətin əlçatanlığı barədə iddia deyil. Stripe webhook sənədi.
Təkrar cəhd necə idarə edilir?
Bağlantı kəsiləndə istifadəçi yenidən düyməyə basa bilər. Mövcud əməliyyatla yeni cəhdin əlaqəsi əvvəlcədən düşünülməlidir. Eyni işi təhlükəsiz təkrar etmə yanaşması idempotentlik adlanır; açarın mənası və saxlanma müddəti provayderdən asılıdır. Stripe-ın idempotent sorğu izahı bunun bir nümunəsidir. Başqa provayderdə həmin qaydaları avtomatik eyni hesab etməyin.
Geri qaytarma funksiyası lazımdırmı?
Biznes bu funksiyanı istəyirsə, tam və qismən qaytarma, icazə verilən istifadəçi və sifarişin son statusu ayrıca tapşırıq olmalıdır. Funksiyanın provayder tərəfindən dəstəklənməsi təsdiqlənsin. Sınaq nəticəsini həm saytda, həm provayderin sınaq panelində müqayisə edin. Əməliyyatın müştəri hesabında görünmə vaxtını özünüzdən vəd etməyin.
Qəbul protokolu
Hər sınaq üçün tarix, sınaq sifarişinin identifikatoru, gözlənilən nəticə və faktiki nəticə qeyd edilsin. Kartın tam məlumatını və gizli giriş açarlarını protokola yazmayın. Açıq qalan uyğunsuzluqların məsulu müəyyənləşdikdən sonra canlıya keçid planı razılaşdırılır. “Düymə işləyir” əvəzinə bu siyahı inteqrasiyanın hansı hissələrinin yoxlandığını göstərir.
Mövzunu davam etdirin
- Ödəniş sistemi inteqrasiyası xidməti
- Mağazanın açılış planı
- Sifarişin sistemlər arasında ötürülməsi
- Ödəniş layihəsi üçün tələblər
Qərardan əvvəl əlavə yoxlama
Canlıya keçid protokolunda test hesabı ilə canlı hesabın ayrıldığını qeyd edin. Nəticəni sifariş kartı və provayderin təsdiqi əsasında tutuşdurun.
Şəxsi kart məlumatı olmadan sınaq identifikatorlarını saxlayın. Sonrakı uyğunsuzluqda komanda əməliyyatın hansı mərhələdə dayandığını anlaya bilsin.
Nümunə ssenari
Nümunə sınaq: alıcı ödəniş pəncərəsini bağlayır, təsdiq isə bir qədər sonra gəlir. Sifarişin son vəziyyəti provayderin təsdiq qaydasına əsaslanır. Operatorun həmin əməliyyatı identifikatorla tapıb yoxlaması mümkün olmalıdır.