API vasitəsilə SMM panelində balansın avtomatik artırılmasını necə quraşdırmaq olar

Avtomatik artırmanı quraşdırmadan əvvəl nə hazırlamaq lazımdır

Avtomatik artırma SMM panelinin balansını ödəniş xidməti və ya daxili billing ilə əlaqələndirir. Xidmət qalığı yoxlayır, müəyyən edilmiş həddə çatdıqda ödəniş yaradır və vəsaiti yalnız ödəniş təsdiqləndikdən sonra hesaba köçürür. İş üçün panelin API sənədləri, ödəniş API-sinə giriş, test və iş mühiti üçün ayrı açarlar, həmçinin bütün əməliyyatların jurnalı lazımdır.

İnkişafa başlamazdan əvvəl panelin API-sinin balansı qaytara, hesaba köçürmə sorğusunu qəbul edə, artırmalar tarixçəsini göstərə və xarici əməliyyat identifikatorunu qəbul edə bildiyini yoxlayın. Əgər panel API vasitəsilə hesaba köçürməni dəstəkləmirsə, avtomatlaşdırma yalnız müraciət yarada və ya operatora bildiriş göndərə bilər. Bu variantın çatışmazlığı ondan ibarətdir ki, pulu yenə də əl ilə daxil etmək lazım gələcək.

Balans yoxlamasını və ödəniş qərarını ayırın

Qalığın yoxlanılmasını cədvəl üzrə ayrı tapşırıq kimi işə salmaq daha yaxşıdır. O, balansı alır, onu hədlə müqayisə edir və nəticəni artırma emalçısına ötürür. Cari tamamlanmamış əməliyyatları yoxlamadan API cavabı anında birbaşa ödəniş yaratmayın: paralel tapşırıqlar eyni aşağı balansı görə və bir neçə ödəniş yarada bilər.

Yeni ödənişdən əvvəl emalçı «yaradılıb», «ödəniş gözləyir» və ya «təsdiqlənir» statusunda əməliyyatın olub-olmadığını yoxlamalıdır. Əgər belə qeyd varsa, yeni cəhd yoxlama tamamlanana qədər işə salınmır. Ardıcıl emalın çatışmazlığı ondan ibarətdir ki, xarici API-nin uzun cavabı zamanı artırma bir neçə paralel sorğu ilə müqayisədə daha gec başlaya bilər.

Həddi və artırma məbləğinin məntiqini seçin

Balans həddi aktiv sifarişlər, təchizatçılarda növbə və ödəniş gecikmələri üçün ehtiyatla seçilir. Qeyri-bərabər aktivliyi olan kanal üçün yalnız orta xərclə rəhbər tutmaq risklidir: strimdən, reklamın işə salınmasından və ya kütləvi sifarişdən sonra silinmələr kəskin arta bilər. Ayrıca kritik səviyyə müəyyən edilir, ona çatdıqda bildiriş gəlir, lakin ödəniş mütləq avtomatik yaradılmır.

Artırma məbləği sabit ola bilər və ya seçilmiş dövr üzrə xərcə əsasən hesablana bilər. Sabit məbləğ nəzarət və yoxlama üçün daha sadədir. Onun çatışmazlığı ondan ibarətdir ki, sakit dövrdə balansda artıq vəsait qala bilər, sifarişlərin kəskin artımı zamanı isə bir artırma kifayət etməyə bilər. Hesablanan məbləğ daha çevikdir, lakin statistikadan anormal silinmələrin və geri qaytarmaların təmizlənməsini tələb edir.

Maliyyə məhdudiyyətlərini hədddən ayrıca qurşdurun

Hədd yalnız sistemin artırma prosesinə nə vaxt başlamağa icazəsi olduğu sualına cavab verir. Məhdudiyyətlər başqa suala cavab verir: o, nə qədər vəsait silmək hüququna malikdir. Bir əməliyyatın maksimum məbləğini, dövr üzrə ümumi limiti və hesaba köçürmədən sonra yol verilən qalığı təyin edin. Bu qaydalar ödənişin ödənilməsindən sonra deyil, yaradılmasından əvvəl yoxlanılır.

Avtomatik artırma əməliyyat və dövr üzrə limit olmadan vəsait silməməlidir. Əgər hesablanan məbləğ icazə veriləndən yüksəkdirsə, əməliyyatı əl ilə yoxlamaya keçirmək və bildiriş göndərmək daha yaxşıdır. Sərt limitlərin çatışmazlığı ondan ibarətdir ki, xərclərin sürətli artımı zamanı məsul işçi limitin artırılmasını təsdiqləyənədək balans bitə bilər.

Ayrı açarlar yaradın və girişi qoruyun

Avtomatik artırma skripti üçün minimal hüquqlu ayrı API açarlarından istifadə edin: balansın oxunması, ödənişin yaradılması, statusun yoxlanılması və təsdiqlənmiş əməliyyatın hesaba köçürülməsi. İstifadəçilərə, xidmət parametrlərinə, sifarişlərə və vəsaitin çıxarılmasına giriş belə açar üçün lazım deyil. Əgər xidmət IP ünvanları üzrə məhdudiyyəti dəstəkləyirsə, müraciətlərə yalnız inteqrasiya serverindən icazə verin.

Açarlar mühit dəyişənlərində və ya qorunan sirr anbarında saxlanılır. Onları brauzer koduna, jurnallara, ictimai repozitoriyalara və xəta mesajlarına ötürməyin. Hər açarın sahibi və aydın dəyişdirmə qaydası olmalıdır. Açarların tez-tez rotasiyasının çatışmazlığı ondan ibarətdir ki, yeni sirr bütün iş proseslərində yenilənməzsə, artırma dayanacaq.

Unikal identifikatorla ödəniş yaradın

Hər artırmaya ödəniş API-sinə müraciətdən əvvəl daxili identifikator verilir. O, jurnalda saxlanılır və idempotentlik açarı və ya xarici əməliyyat nömrəsi kimi ötürülür. Şəbəkə taym-autu zamanı eyni sorğu eyni identifikatorla təkrarlana bilər: ödəniş xidməti artıq yaradılmış əməliyyatı qaytarmalıdır, pulu yenidən silməməlidir.

Aşağıda sorğunun ümumi nümunəsi verilmişdir. Sahələrin adlarını və ünvanları konkret provayderin sənədlərindəki dəyərlərlə əvəz edin. PAYMENT_ID dəyişənində əvvəlcədən yaradılmış unikal ID saxlanılır, CALLBACK_URL isə vebhuk emalçısına yönləndirir.

curl -X POST "$PAYMENT_API_URL/payments" \
-H "Authorization: Bearer $PAYMENT_API_KEY" \
-H "Idempotency-Key: $PAYMENT_ID" \
-H "Content-Type: application/json" \
-d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID","callback_url":"$CALLBACK_URL"}'

Ödənişin unikallığını yalnız məbləğ və yaradılma vaxtı ilə müəyyən etməyin. İki eyni artırma qanuni ola bilər, nasazlıqdan sonra təkrar sorğu isə yox. Öz bazasında xarici ID-nin çatışmazlığı ondan ibarətdir ki, onu etibarlı saxlamaq və əməliyyat ləğv edildikdən sonra yenidən istifadə etməmək lazımdır.

Balansı yoxlayın və əməliyyatın vəziyyətini saxlayın

Balans sorğusu yeni artırma qərarından əvvəl və uğurlu hesaba köçürmədən sonra yerinə yetirilməlidir. Ümumi sorğu belə görünə bilər: curl -X GET "$PANEL_API_URL/balance" -H "Authorization: Bearer $PANEL_API_KEY". Cavabda yalnız məbləği deyil, yoxlama vaxtını da saxlayın ki, köhnəlmiş məlumatlar əsasında qərar qəbul etməyəsiniz.

Hər əməliyyat üçün daxili ID, provayderdə ödənişin ID-si, məbləğ, valyuta, yaradılma vaxtı, status, API cavabları və xətanın səbəbi ilə qeyd aparın. Uyğun vəziyyətlər zənciri: «yaradılıb», «ödəniş gözləyir», «ödənilib», «hesaba köçürülür», «hesaba köçürülüb», «ləğv edilib», «yoxlama tələb edir».

Panelə hesaba köçürmə yalnız təsdiqlənmiş və hələ emal olunmamış ödəniş üçün icazəlidir. Statusları tarixçəsiz yenidən yazmayın: mübahisə zamanı hansı sorğunun göndərildiyi və əməliyyatın niyə dəyişdirildiyi görünməlidir. Ətraflı jurnalın çatışmazlığı ondan ibarətdir ki, o, həssas məlumatları ehtiva edə bilər, buna görə ona giriş məhdudlaşdırılır.

Vebhuku qəbul edin və ödəniş statusunu yoxlayın

Uğurlu ödəniş səhifəsi və istifadəçinin yönləndirilməsi pulun daxil olmasını təsdiqləmir. Təsdiq ödəniş xidmətindən gələn vebhuk və ya onun API-si vasitəsilə statusun təkrar yoxlanılmasıdır. Vebhuk alındıqda imzanı, göndərilmə vaxtını, ödənişin ID-sini, xarici ID-ni, məbləği və valyutanı yoxlayın. Yalnız bundan sonra əməliyyatı təsdiqlənmiş ödəniş vəziyyətinə keçirin.

Vebhuku yoxladıqdan sonra provayderdən ödənişin aktual statusunu sorğulamaq faydalıdır. Məsələn: curl -X GET "$PAYMENT_API_URL/payments/$PROVIDER_PAYMENT_ID" -H "Authorization: Bearer $PAYMENT_API_KEY". Statusu jurnal məlumatları ilə tutuşdurun, sonra eyni daxili ID ilə SMM panelinə hesaba köçürmə sorğusu göndərin.

Təkrar vebhuk ikinci hesaba köçürmə yaratmamalıdır. Emalçı əməliyyatı xarici ID ilə tapır, «hesaba köçürülüb» statusunu görür və yeni hərəkətlər etmədən uğurlu cavab qaytarır. Vebhukların çatışmazlığı ondan ibarətdir ki, emalçı əlçatan olmadıqda onlar gecikə və ya çatmaya bilər.

Taym-autları, təkrar cəhdləri və donmuş ödənişləri emal edin

Ödəniş yaradıldıqdan sonra taym-aut baş verərsə, başqa ID ilə yeni sorğu göndərməyin. Əvvəlcə əməliyyatı daxili identifikatorla tapın və ya sorğunu eyni idempotentlik açarı ilə təkrarlayın. Əgər provayder ilkin sorğunu qəbul edibsə, o, mövcud ödənişi qaytaracaq. Bu, bağlantı kəsildikdə ikiqat silinmədən qoruyur.

Əgər vebhuk müəyyən edilmiş vaxt ərzində gəlməzsə, fon tapşırığı ödənişin statusunu API vasitəsilə sorğulayır. Təkrar yoxlamalar API-ni və jurnalı həddən artıq yükləməmək üçün artan fasilə və məhdud cəhd sayı ilə aparılır. Uzun müddət gözləmədə qalan əməliyyat yoxlama olmadan ləğv edilmiş sayılmır, əl ilə yoxlamaya keçirilir.

Müvəqqəti şəbəkə xətası və ya API-nin əlçatmazlığı barədə cavablarda təkrar cəhdlərə yol verilir. Ödənişdən imtina, yanlış məbləğ, vebhuk imzasının etibarsızlığı və ya limitin aşılması zamanı sorğunu avtomatik təkrarlamaq lazım deyil. Təkrar cəhdlərin çatışmazlığı ondan ibarətdir ki, onlar vəziyyətlərin məntiqini mürəkkəbləşdirir və provayderdə kütləvi nasazlıq zamanı artıq yük yarada bilər.

Təsdiqlənmiş ödənişi SMM panelinə köçürün

Hesaba köçürmədən əvvəl emalçı bir daha yoxlayır: məbləğ limiti aşmır, valyuta uyğundur, əməliyyat ləğv edilməyib və onun statusu hələ «hesaba köçürülüb» deyil. Sorğuya məbləğ və ödənişin xarici identifikatoru ötürülür. Əgər panelin API-si idempotentlik açarını dəstəkləyirsə, eyni daxili əməliyyat ID-sindən istifadə edin.

Sorğunun ümumi görünüşü: curl -X POST "$PANEL_API_URL/balance/topups" -H "Authorization: Bearer $PANEL_API_KEY" -H "Content-Type: application/json" -H "Idempotency-Key: $PAYMENT_ID" -d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID"}'

Panelin cavabından sonra balansı təkrar sorğulayın və nəticəni jurnalda saxlayın. Əgər ödəniş xidmətində pul silinib, lakin panelin API-si xəta qaytarıbsa, yeni ödəniş yaratmayın. Əməliyyat təkrar hesaba köçürmə cəhdinə və ya əl ilə yoxlamaya qədər «yoxlama tələb edir» statusunda qalır. Belə ehtiyatlı sxemin çatışmazlığı ondan ibarətdir ki, balans müvəqqəti olaraq avtomatik artmaya bilər.

Bildirişlər, açar və işə salma yoxlaması əlavə edin

Bildirişlər kənarlaşmalar üçün lazımdır: balans kritik səviyyədən aşağı düşüb, ödəniş rədd edilib, vebhuk alınmayıb, limit aşılıb, API əlçatmazdır və ya əməliyyat əl ilə yoxlama tələb edir. Mesajda daxili ID, status və səbəbi göstərmək kifayətdir. Ona API açarlarını, vebhuk imzalarını və ödəniş rekvizitlərini daxil etməyin.

İnteqrasiyanı silmədən avtomatik artırma üçün ayrıca açar buraxın. O, təchizatçı dəyişdirilərkən, texniki işlər zamanı, xəta şübhəsi və ya xərclərin kəskin dəyişməsi halında lazımdır. Açarın çatışmazlığı aydındır: işlərdən sonra onu yenidən işə salmasanız, aktiv sifarişlər zamanı balans bitə bilər.

Avtomatik artırmanı işə salmazdan əvvəl yoxlama siyahısı

• Tamamlanmamış əməliyyat olduqda balans yoxlaması ödəniş yaratmır.
• Hər ödəniş üçün unikal daxili ID və idempotentlik açarı yaradılır.
• Bir əməliyyat və seçilmiş dövr üçün limitlər qurulub.
• Vebhuklar imza, məbləğ, valyuta və identifikator üzrə yoxlanılır.
• Vebhuk olmadıqda API vasitəsilə statusun təkrar yoxlanması işə salınır.
• Taym-aut birincisi yoxlanmadan ikinci ödənişin yaradılmasına səbəb olmur.
• Panelə hesaba köçürmə bir dəfə yerinə yetirilir və jurnalda qeyd olunur.
• Test rejimi uğur, imtina, vebhukun dublikatı və API-nin əlçatmazlığı üzrə yoxlanılıb.