blog

To‘lov funksionalligi uchun umumiy komponentni amalga oshirish

NEXTREE.

• 6 min read
To‘lov funksionalligi uchun umumiy komponentni amalga oshirish

- Toʻlov SDKʼni qayta foydalaniladigan umumiy React komponenti sifatida amalga oshirish tajribasi -

1. Umumiy SDK komponentini amalga oshirishga kirish

Haqiqiy toʻlov ekranida bajarilishi kerak boʻlgan biznes mantiqi shunchaki SDKʼni chaqirishdan ancha koʻproq narsani oʻz ichiga olgan.

  • Aʼzo va aʼzo boʻlmagan mijozlar uchun mijoz kalitlarini oʻrnatish

  • Toʻlov summasidagi oʻzgarishlarni real vaqt rejimida aks ettirish

  • Toʻlov maʼlumotlarini yaratish va backend bilan integratsiya qilish

  • Inline va qalqib chiquvchi toʻlov usullarini bir vaqtning oʻzida qoʻllab-quvvatlash

  • Toʻlov muvaffaqiyatli yoki muvaffaqiyatsiz boʻlganda yoʻnaltirishlarni boshqarish

  • Toʻlov xatosi yuz berganda backenddagi holatni yangilash

  • Takroriy toʻlov soʻrovlarining oldini olish mantiqini qoʻllash

  • React Native WebView muhitini qoʻllab-quvvatlash

Bu mantiqni har bir ekranda alohida amalga oshirish nafaqat kod takrorlanishini oshirgan, balki toʻlovni qayta ishlash qoidalarida izchillikni saqlashni ham juda qiyinlashtirgan boʻlardi. Masalan, bir ekran SDK xatolarini backendga yozib olsa, boshqa ekran esa ularni shunchaki konsolga chiqarsa, fragmentatsiya muammolari yuzaga kelishi mumkin.

Shuningdek, har bir xizmat uchun turli xil toʻlov interfeysi talab qilinishini ham hisobga olishimiz kerak edi. Toʻlov shartlari va toʻlov usuli konfiguratsiyalari turlicha boʻlgani, shuningdek, toʻlov tugmasining joylashuvi va dizayni xizmatdan xizmatga farq qilgani sababli, ularni umumiy komponent ichida qatʼiy shaklda joylashtirish amalda mumkin emas edi.

Shu sababli biz umumiy komponent SDK integratsiyasi va toʻlov holatini boshqarish uchun javobgar boʻladigan, har bir ekran esa haqiqiy toʻlovni qachon bajarishni moslashuvchan tarzda belgilay oladigan tuzilmani ishlab chiqdik.

2. Kutilgan afzalliklar

Umumiy komponentni amalga oshirish orqali erishmoqchi boʻlgan maqsadlarimiz quyidagilardan iborat edi.

Birinchidan, ekranlar va SDK oʻrtasidagi bogʻliqlikni minimallashtirdik. Alohida ekranlar SDKʼni murakkab ishga tushirish jarayonini bilishi shart boʻlmasdan, faqat buyurtma raqami, buyurtma nomi, summa va yoʻnaltirish URL manzili kabi zarur maʼlumotlarni uzatadigan qilib loyihalandi.

Ikkinchidan, toʻlovni qayta ishlash qoidalarida izchillikni taʼminladik. Toʻlov maʼlumotlarini yaratishdan tortib yakuniy tasdiqlash va muvaffaqiyatsizlik holatini saqlashgacha boʻlgan butun jarayonni umumiy qismda boshqarish orqali ekranlar xatti-harakatlaridagi farqlar sabab yuzaga keladigan xatolarning oldini olishga intildik.

Uchinchidan, inline va qalqib chiquvchi usullarni yagona interfeys orqali integratsiya qildik. Foydalanuvchilar faqat toʻlov usulini parametr sifatida tanlashlari kerak, bajarish vaqtida esa bir xil executePayment() usulini chaqirish orqali izchil ishlab chiqish tajribasidan foydalanishlari mumkin.

Toʻrtinchidan, texnik xizmat koʻrsatish samaradorligini oshirdik. SDK parametrlari oʻzgarganda yoki xatolarni boshqarish siyosatlari qayta koʻrib chiqilganda, har bir ekranni alohida oʻzgartirish oʻrniga faqat bir joydagi umumiy komponentni yangilash orqali tezkor javob bera olamiz.

3. Amalga oshirish yondashuvi

3.1. Tashqi toʻlovni bajarish interfeysini taqdim etish

Toʻlov tugmasining UI tarkibi har bir xizmat ekranining ixtiyoriga qoldirildi, umumiy komponent esa oʻz interfeysi orqali faqat toʻlovni bajarish mantiqini taqdim etishi kerak edi. Bunga erishish uchun Reactʼning `forwardRef` va `useImperativeHandle` funksiyalaridan foydalandik.

export interface RequestPaymentContainerRef {
  executePayment: () => Promise<void>;
}

useImperativeHandle(ref, () => ({
  executePayment: async () => {
    if (!innerPaymentRef.current) {
      throw new Error('Payment component is not ready.');
    }
    await innerPaymentRef.current.executePayment();
  },
}));

◈ Komponentdan foydalanadigan ota-ona ekran taqdim etilgan `ref` orqali toʻlovni osongina ishga tushirishi mumkin.

const paymentRef = useRef<RequestPaymentContainerRef>(null)

const handlePayment = async () => {
  await paymentRef.current?.executePayment();
};

◈ Xususan, executePayment chaqiruvchi bajarilishdagi xatolarni aniq taniy olishi uchun Promise<void> shaklida taqdim etildi. Agar u toʻlov komponenti hali tayyor boʻlmagan paytda chaqirilsa, istisno yuzaga keladi va ota-ona ekranga tegishli yoʻriqnoma taqdim etish imkonini beradi.

3.2. Inline va qalqib chiquvchi toʻlovlarni ajratish

Inline toʻlovlar toʻlov usullari va shartlarini bevosita sahifada koʻrsatadi, qalqib chiquvchi toʻlovlar esa toʻlov oynasini ochadi va executePayment() chaqirilganda maʼlumotlarni yaratadi.

Bu turli mexanizmlarni bitta komponentda boshqarish uni juda murakkablashtirgan boʻlardi. Shu sababli rollarni `RequestPayment` va `RequestPaymentPopup` oʻrtasida taqsimladik hamda ota-ona konteynerni ulardan keraklisini tanlab foydalanadigan qilib sozladik.

Ularning ichki amalga oshirilishi turlicha boʻlsa-da, polimorfizmga erishish uchun tashqi taqdim etiladigan interfeysni bir xil saqladik.

3.3. Muvaffaqiyatli va muvaffaqiyatsiz yoʻnaltirishlarni sozlash

SDK toʻlov oynasida toʻlovning yakunlanishi barcha biznes mantiqi bajarilganini anglatmaydi. Yakuniy tasdiqlash uchun yoʻnaltirilgan URLʼdan olingan `paymentKey` kabi maʼlumotlarni backend tasdiqlash APIʼsiga uzatish juda muhim.

Umumiy jarayon quyidagicha kechadi.

  1. Dastlabki toʻlov maʼlumotlarini backendda roʻyxatdan oʻtkazing va yagona toʻlov IDʼsini oling.

  2. Berilgan IDʼni `orderId` sifatida belgilang va SDK orqali toʻlovni soʻrang.

  3. Toʻlov shlyuzi toʻlov oynasida toʻlovni qayta ishlagach, belgilangan muvaffaqiyat yoki muvaffaqiyatsizlik URL manziliga oʻting.

  4. Muvaffaqiyatli boʻlganda, backendning yakuniy tasdiqlash APIʼsini chaqiring.

  5. Muvaffaqiyatsiz boʻlganda, backenddagi toʻlov holatini muvaffaqiyatsiz deb yangilang.

  6. Barcha keyingi qayta ishlash ishlari tugagach, yakuniy manzil ekraniga oʻting.

Buni qoʻllab-quvvatlash uchun `success-redirect` va `fail-redirect` deb nomlangan oraliq koʻprik yoʻllarini ishlab chiqdik. Ushbu bosqichda biznes mantiqini yakunlash orqali “toʻlov shlyuzidagi toʻlov muvaffaqiyati”ni “ichki maʼlumotlarni qayta ishlash yakunlangani”dan qatʼiy ajratdik va maʼlumotlar izchilligini yaxshiladik.

4. Amalga oshirish jarayonidagi mulohazalar

4.1. Ishga tushirish va toʻlov imkoniyati

SDK nusxasi yaratilgani toʻlov darhol mavjud degani emas. Inline usulda toʻlov usuli va shartlar UIʼsini koʻrsatish toʻliq yakunlangan boʻlishi kerak.

Shu sababli SDK obyekti, vidjetlar va haqiqiy koʻrsatish yakunlanganligi holati — ready — ni alohida va qatʼiy tarzda boshqardik. Toʻlov bilan bogʻliq muammolarning oldini olish uchun koʻrsatish yakunlanguncha tugmani oʻchirib qoʻyish kabi himoya choralarini qoʻlladik.

Bundan tashqari, props orqali uzatiladigan summa oʻzgarganda SDKʼning ichki holati ham sinxronlashtirilishi kerakligi sababli, widgets.setAmount()ʼni qayta mos ravishda chaqirish mantiqini kiritdik.

4.2. Takroriy tasdiqlash soʻrovlarining oldini olish

Tasdiqlash APIʼsi muvaffaqiyatli yoʻnaltirish ekrani yuklanganda chaqiriladi, biroq sahifani yangilash yoki ortga qaytish kabi harakatlar tufayli ayni soʻrov bir necha marta yuborilishi mumkin.

Buni faqat frontend holatini boshqarish orqali toʻliq bloklash qiyin. Shu sababli tarmoq qayta urinishlari va bir nechta varaq muhitlarini hisobga olgan holda, tizim backend va toʻlov shlyuzi APIʼlari darajasida idempotentlikni kafolatlaydigan qilib loyihalanishi muhim.

4.3 URL va marshrutlash muhitlari

Umumiy komponentlar turli marshrutlash muhitlarida ishlatilgani sababli, `basePath` qiymatini to‘g‘ri normallashtirish muhim. So‘rov parametrlarini qo‘shishda to‘lov jarayoni uzluksiz ishlashi uchun ajratuvchini (`?` yoki `&`) to‘g‘ri tanlash va xato xabarlarini kodlash kabi jihatlarga ehtiyotkorlik bilan yondashish kerak.

Garchi bu ish bir qarashda oddiydek tuyulsa-da, o‘rnatilgan muhitlarda yoki murakkab yo‘l tuzilmalarida ushbu asosiy amallar to‘lov muvaffaqiyatli yakunlanishi yoki yakunlanmasligini belgilovchi muhim omillarga aylanadi.

4.4 Popup va WebView muhitlari

Popup usuli hodisa tinglovchilarini ish vaqtida ro‘yxatdan o‘tkazgani sababli, tugma qayta-qayta bosilganda tinglovchilarning takroran ro‘yxatdan o‘tkazilishining oldini olish kerak. Bajarilish jarayonida holatni boshqarish va komponent olib tashlanganda tozalash mantiqini puxta joriy etdik.

Xususan, React Native WebView muhitlari uchun `appScheme` qiymatini kiritishni qo‘llab-quvvatladik. Qiymatlarni kodga qattiq kiritishdan voz kechib, muhitni ilova sozlamalari orqali dinamik tarzda sozlash imkonini yaratdik va kengaytiriluvchanlikni hisobga oldik.

5. Xulosa

To‘lov SDK’si yordamida oddiy to‘lov oynasini joriy etish qiyin bo‘lmadi. Biroq haqiqiy muammo ishga tushirishdan tortib backenddagi holatni boshqarishgacha bo‘lgan murakkab jarayonni butun tashkilot miqyosida izchil qo‘llashdan iborat edi.

Ushbu loyiha orqali to‘lov funksiyalarini rollar bo‘yicha ajratib, `forwardRef` orqali kapsulalangan interfeys taqdim etish hisobiga foydalanish qulayligini maksimal darajada oshirdik.

Umumiy komponentlar joriy etilgach, yangi xizmatlarga to‘lov funksiyalarini qo‘shish bilan bog‘liq xarajatlar va inson xatolari sezilarli darajada kamaydi, shu bilan birga tizimning umumiy qo‘llab-quvvatlanish qulayligi ham yaxshilandi.

Albatta, texnik jihatdan to‘liqlik faqat frontend bilan cheklanmaydi. Menimcha, chinakam ishonchli to‘lov tizimiga faqat backenddagi idempotentlikni boshqarish va holatlarni muvofiqlashtirish mantiqi birgalikda ishlaganda erishiladi.

Bu qayta foydalaniladigan komponentlar kod takrorlanishini bartaraf etish bilangina cheklanmasligini tasdiqlagan qimmatli tajriba bo‘ldi: ular tashqi kutubxonalarning murakkabligini ajratib, butun xizmat bo‘ylab izchil biznes qiymatini taqdim etadi.

chnsik

Site footer