Yandex Go nega ishlamayapti — biznes nima qilishi kerak

Tashqi xizmat uzilganda buyurtmani o'z bazangizga saqlashni davom ettiring. To'lovni yakunlash yoki kuryerni tasdiqlash uchun esa provayder javobi kerak. Buyurtma qabul qilishni tashqi API javobiga bog'lamang.

"yandex go nega ishlamayapti" deb izlayotgan tadbirkor uchun amaliy vazifa shu: boshqa kompaniyadagi uzilish sabab xaridorning savati sizda yo'qolmasin. Buning sharti bor: sayt, mobil ilova yoki Telegramdagi qabul tizimingiz va uning bazasi ishlayotgan bo'lishi kerak.

Buyurtma saqlandi degani pul tushdi degani emas. Mijoz ham, menejer ham bu farqni ekranda ko'rsin. Aks holda mijoz qayta to'lashi, xodim esa tasdiqlanmagan to'lovni tushum deb hisobga olishi mumkin.

Yandex Go nega ishlamayapti: sababni taxmin bilan izohlamang

Tekshiruv chegarasi: quyidagi hodisa havolalari, xizmatlarning joriy rasmiy holati va Celion xizmat sahifasi mustaqil tekshirilmagan. Shu sabab bu maqola muayyan uzilish sababini yoki xizmat qachon tiklanishini tasdiqlamaydi.

Tekshirish uchun berilgan manzillar: Yandex Go bo'yicha 2026-yil 11-oktabr sanasi ko'rsatilgan havola, Yandex Uzbekistan bo'yicha 12-oktabr havolasi va Uzum Market bo'yicha 10-oktabr havolasi. Havolaning o'zi dalil emas. Mazmuni tekshirilmaguncha uzilish sababi yoki tiklanish vaqtini fakt sifatida keltirmang.

Yandex va Uzumdagi hodisalarni alohida tekshiring. Uzumning rasmiy tasdig'isiz uning uzilishini Yandex infratuzilmasiga bog'lamang. Ma'lumotlar markazi jismonan shikastlangan bo'lsa ham, bu o'z-o'zidan kiberhujum bo'lganini isbotlamaydi.

"Uzum Market nega ishlamayapti" savoliga eski xabar bilan javob berib bo'lmaydi. Joriy holatni xizmat ilovasi yoki rasmiy tasdiqlangan aloqa kanalida tekshiring; zarur bo'lsa, qo'llab-quvvatlash xizmatidan so'rang. Biznes integratsiyasi uchun aynan siz ishlatadigan API yoki hamkor kabineti holatini aniqlang.

Ilova ochilgani barcha amallar ishlayotganini bildirmaydi. Bitta telefondagi xato ham umumiy uzilishning isboti emas. Mahalliy internet va qurilmani tekshiring, keyin biznesingizning o'z serveri ishlayotganiga ishonch hosil qiling.

Operatorga "hamma xizmat ishlamayapti" deyishdan ko'ra, bajarilmayotgan amalni ayting. Buyurtma saqlanmayaptimi? To'lov tasdig'i kelmayaptimi? Yetkazib berish so'rovi javobsizmi? Qaysi amal to'xtaganini bilmasdan to'g'ri chorani tanlab bo'lmaydi.

Buyurtmani avval o'z bazangizga saqlang

Sayt yoki mobil ilovadagi "Buyurtma berish" tugmasi avval yozuvni biznes nazoratidagi bazaga saqlasin. Tashqi xizmatga uzatish keyin bajariladi. Uning javobi kelmasa ham, buyurtma yozuvi sizda qolishi kerak.

Faraziy misol: Toshkentdagi do'kon sayt va Telegramdan buyurtma oladi. To'lovni tashqi provayder qabul qiladi, savdo esa 1Cga uzatiladi. Provayder javob bermasa, do'kon buyurtma tarkibi va mijozning aloqa ma'lumotini saqlaydi, buyurtmaga o'zgarmas identifikator beradi. Menejer shu identifikator orqali yozuvni topadi.

Saqlangan buyurtma yetkazib berish va'dasi emas. Ombor qoldig'i faqat ishlamayotgan ERPdan olinadigan bo'lsa, sayt mahsulotni aniq mavjud deb ko'rsatmasin. Oxirgi yangilangan qoldiq ko'rsatilsa, uning hozirgi holatni aks ettirmasligi mumkinligini ochiq yozing.

Telegram orqali buyurtma qabul qilishda ham shu tartib kerak. Bot xabarni olgani yetarli emas: mijozga "Buyurtmangiz saqlandi" tasdig'i faqat yozuv bazaga tushgandan keyin yuboriladi. Menejerning shaxsiy chatidagi xabar rasmiy buyurtma yozuvi o'rnini bosmaydi.

Bazaga yozish bilan uzatish navbatiga qo'yish orasida ham uzilish bo'lishi mumkin. Buyurtma va uni uzatish topshirig'ini bitta ma'lumotlar bazasi tranzaksiyasida saqlang. Shunda buyurtma saqlanib, uni tashqi xizmatga yuborish topshirig'i yaratilmay qolishining oldi olinadi.

Sayt va Telegram bot bir xil ishlamayotgan serverga ulangan bo'lsa, kanalni almashtirish yordam bermaydi. Zaxira qabul yo'li o'ziga kerakli infratuzilma ishlagandagina foyda beradi. Mahsulotni ko'rish yoki murojaat qoldirish davom etishi mumkin, lekin haqiqiy qoldiq va yetkazish muddatini tasdiqlash kutadi.

To'lov javobsiz qolsa, "tekshirilmoqda" deb ko'rsating

To'lov so'roviga javob kelmagani pul yechilmaganini bildirmaydi. Provayder operatsiyani bajargan, lekin javob sizning tizimingizga yetib kelmagan bo'lishi mumkin. Kutish muddati tugashi bilan "To'lov amalga oshmadi" deb yozmang.

Buyurtma va to'lov holatini alohida saqlang. "Buyurtma qabul qilindi" biznes yozuvni saqlaganini bildiradi. "To'lov tasdig'i kutilmoqda" holatida esa pul tushgani hali tasdiqlanmagan. Bu holat mahsulotni ombordan jo'natishga ruxsat bermasligi kerak.

Payme Business ishlab chiquvchi hujjatlarida Merchant API tranzaksiyani tekshirish va bajarish uchun alohida usullar belgilangan. Integratsiyani siz foydalanayotgan API qoidalariga mos quring. Umumiy tavsiya provayderning tranzaksiya tartibi o'rnini bosa olmaydi.

Mijoz "to'lov kutilmoqda, nima qilish kerak" deb javob izlamasin. Ekranda avtomatik tekshiruv davom etayotganini yozing va operatorga murojaat qilish yo'lini ko'rsating. Natija noma'lum bo'lsa, mijozni yana to'lashga undaydigan tugma qo'ymang.

Ishlatish mumkin bo'lgan xabar: "Buyurtmangiz saqlandi. To'lov tasdig'i hali kelmadi, holatni tekshiryapmiz. Kartangizdan pul yechilgan bo'lsa, qayta to'lamang. Operatorga buyurtma raqamini yuboring. Natija aniqlangach, sizga xabar beramiz."

Xabar mijoz tanlagan o'zbek, rus yoki ingliz tilida berilishi mumkin. Tilni auditoriyaga mos tanlang. Har bir versiyada to'lov holati va mijozning keyingi harakati bir xil tushuntirilsin.

Menejer oynasida ham "tekshirilmoqda" holati ko'rinsin. Aks holda sayt mijozdan kutishni so'raydi, savdo xodimi esa yangi to'lov havolasini yuboradi. To'lov albatta o'tishini va'da qilmang. Muqobil to'lov usulini avvalgi operatsiya natijasi aniqlangandan keyin taklif qilish xavfsizroq.

Qayta yuborish yangi buyurtma yoki to'lov yaratmasin

Xaridor tugmani qayta bosishi mumkin. Aloqa tiklangach, mobil ilova ham so'rovni takrorlaydi; provayder esa bir xil bildirishnomani yana yuborishi mumkin. Tizim har bir takrorni yangi xarid deb qabul qilsa, bitta buyurtma bir necha marta yaratiladi.

Har bir mantiqiy operatsiyaga o'zgarmas identifikator bering. So'rov qayta yuborilganda shu identifikator saqlansin. Tizim u orqali oldingi natijani qaytaradi yoki ish hali tugamaganini bildiradi. Idempotent ishlov degani shu: takror kelgan so'rov qayta ishlanadi, lekin amal yana bajarilmaydi.

Biznes bazasida takroriy yozuvni to'sish kartadan pul yana yechilishini avtomatik to'xtatmaydi. Provayder tegishli kalit yoki tranzaksiya identifikatori orqali xavfsiz takrorlashni qo'llasa, uning hujjatlaridagi tartibdan foydalaning. Bunday kafolat bo'lmasa, natijasi noma'lum to'lovni avtomatik qayta yaratmang.

Vaqtinchalik xatoda qayta urinishlar orasidagi kutish muddatini oshiring va unga tasodifiy farq qo'shing. Shunda xizmat tiklanganda kutayotgan so'rovlarning barchasi bir paytda yuborilmaydi. Noto'g'ri rekvizitli yoki rad etilgan operatsiyani o'zgartirmasdan cheksiz takrorlash esa foydasiz.

To'lov bildirishnomasini ham tekshiring. Avval uning haqiqiy yuboruvchidan kelganini tasdiqlang. Keyin buyurtma va summa mosligini tekshiring; shundan so'ng yozuvni "to'langan" holatiga o'tkazing. Bir xil bildirishnoma yana kelsa, omborga ikkinchi jo'natish topshirig'i yaratilmasin.

"To'lov ikki marta yechilgan" murojaatida operator buyurtma raqami orqali unga bog'langan tranzaksiyalarni ko'ra olishi kerak. Tekshiruv tugamasdan pulni avtomatik qaytarish ham xavfli: qaytarish alohida moliyaviy operatsiya. Tekshiruv uchun mijozdan karta kodi yoki maxfiy tasdiqlash ma'lumotlarini so'ramang.

Xizmat tiklangach, navbatni tekshiruvsiz bo'shatmang

API yana javob bera boshlagani hisoblar mos kelganini bildirmaydi. Avval natijasi noma'lum operatsiyalarni tekshiring. Keyin qolgan topshiriqlarni nazorat bilan uzating.

Biznes bazasidagi to'lov yozuvini provayderning ishonchli tranzaksiya ma'lumoti bilan solishtiring. Buyurtma va to'lov identifikatorlari yozuvlarni bog'laydi, summa ham mos kelishi kerak. Farq aniqlansa, yozuv umumiy navbatda qolib ketmasin: uni mas'ul xodimning ish ro'yxatiga chiqaring.

CRM va ERPga uzatish navbatidagi har bir topshiriqda manba identifikatorini saqlang. CRM yozuvni yaratib, uning javobi yo'qolgan bo'lishi mumkin. Bunday so'rov qayta yuborilganda integratsiya yangi savdo yaratmasdan mavjud yozuvni topib yangilashi kerak. Buning uchun qabul qiluvchi tizimda mos identifikator yoki takrorlarni aniqlash tartibi bo'lishi shart.

Topshiriq qancha vaqt navbatda turganini ham hisobga oling. Shu orada mahsulot sotilib ketgan yoki mijoz buyurtmani bekor qilgan bo'lishi mumkin. Xizmat tiklangach, eski topshiriqni bajarishdan oldin buyurtmaning amaldagi holatini tekshiring.

1Cga savdoni yozish fiskal operatsiyani bajarish degani emas. ARCA dasturiy xizmatlari API orqali fiskal uskunalarni 1C va ERP bilan integratsiya qilishni ko'zda tutadi. Texnik sxemada fiskal xizmatga bog'liqlikni alohida ko'rsating. Fiskal operatsiyani qayta ishlashda ham tegishli xizmat qoidalariga amal qiling.

Mijozga "hammasi tiklandi" deyish o'rniga uning buyurtmasida nima o'zgarganini bildiring. To'lov tasdiqlansa, tasdiqni yuboring. Yetkazish hali tekshirilayotgan bo'lsa, shu holatni yozing. Kuzatuvni sayt ochilayotganini tekshirish bilan cheklamang: navbatdagi eng eski topshiriq va mos kelmagan to'lovlar ham ko'rinib tursin.

Texnik audit budjetini bog'liqliklar belgilaydi

Bu ish uchun tekshirilgan mahalliy narx yo'q bo'lsa, bitta summa aytish chalg'itadi. Smetada audit va dasturiy o'zgartirishlarni ajrating, uzilish sinovlarini ham alohida ko'rsating. Keyingi kuzatuv hamda qo'llab-quvvatlash xarajatini boshlang'ich ishga qo'shib yubormang.

Faraziy do'kon uchun hisob modeli: boshlang'ich budjet = audit ish soatlari × audit stavkasi + ishlab chiqish ish soatlari × ishlab chiqish stavkasi + sinov ish soatlari × sinov stavkasi. Stavka va ish hajmini pudratchi taklifidan oling. Oylik xarajatga infratuzilma va kelishilgan xizmat haqi kiradi. Bu formula bozor narxi yoki Celion kotirovkasi emas.

Operator oynasini smetadan chetda qoldirmang. Navbat ishlasa-yu, xodim undagi xatoni topa olmasa, buyurtma baribir hal etilmay qoladi. Qo'lda tekshirish tartibini tayyorlash va mas'ul xodimni o'rgatish ham ish hajmiga kirsin.

Texnik jamoaga yoki taklif berayotgan har bir pudratchiga shu savollarni yuboring:

• Buyurtma qayerda saqlanadi? Tashqi API javob bermasa, menejer sayt va Telegramdan kelgan buyurtmani topa oladimi?
• Qaysi bog'liqlik qabulni to'xtatadi? Telegram bot va sayt bir xil server yoki bazaga tayanadimi?
• Noma'lum to'lov qanday ko'rinadi? Mijoz va operator ekranida qayta to'lashga undamaydigan holat bormi?
• Takroriy so'rov qanday to'siladi? Buyurtma, to'lov va CRM yozuvi uchun takrorni aniqlash tartibini alohida ko'rsating.
• Tiklanish qanday tekshiriladi? Yozuvlarni provayder ma'lumoti bilan kim solishtiradi? Mos kelmagan to'lovlar uchun kim mas'ul?
• Taklifga nima kiradi? Uzilish sinovi, operator yo'riqnomasi va keyingi kuzatuv xarajatlari alohida ko'rsatilganmi?

Buyurtmalarni qo'lda boshqarish oson, kechikish zarari esa kichik bo'lsa, murakkab zaxira infratuzilmasiga pul sarflash shart emas. Lekin to'lov natijasi noaniq qoladigan jarayonni keyinga surmang. Jamoangizdan sinov muhitida tashqi API javobini to'xtatib, buyurtma va to'lov holati qanday ko'rinishini ko'rsatishni so'rang. Budjetni sinovda aniqlangan muammoga yo'naltiring.

Avval buyurtma oqimini audit qiling

Celion bilan texnik audit va API integratsiyasi ish hajmini muhokama qilish uchun sayt yoki mobil ilovangizdagi buyurtma oqimini ko'rsating. Audit vazifasini aniq belgilang: tashqi xizmat javob bermaganda buyurtma qayerda saqlanadi, to'lov natijasini esa kim va qanday tekshiradi?

Biz bilan bog'laning