UPI ინდოეთი: QR, VPA და ლიმიტები

1) რა არის UPI

Unified Payments Interface (UPI) ინდოეთის ეროვნული გადახდის საბურავია, რომელსაც მართავს NPCI. იგი უზრუნველყოფს მყისიერ გადარიცხვებს 24/7 საბანკო ანგარიშებსა და fintech პროგრამებს შორის (PSP). მომხმარებლისთვის, UPI არის ერთი მისამართის ფენა (VPA), დადასტურება (2FA) და კლირინგი, რომლის თავზე შენდება P2P და P2M სცენარები.

• ინტეროპერაციული: ნებისმიერი UPI პროგრამა არის ნებისმიერი ბანკი/ანგარიში.
• მიმართვა დეტალების გარეშე: VPA ფორმა 'სახელი @ handle' IFSC/ანგარიშის ნაცვლად.
• მყისიერი და საბოლოო: თარგმანი დაუყოვნებლივ დასტურდება; ზარალი - ცალკე ოპერაცია.
• მერჩანტისთვის დაბალი ხარჯები: MDR/სქემების რეგულირება ამცირებს შეგროვების ღირებულებას.

2) ეკოსისტემის მონაწილეები

NPCI (სქემა/სვიტრი): როუტინგი, წესები, სერტიფიკაცია.
PSP ბანკები და non-bank PSP (Front-End Apps): კლიენტის პროგრამები (PhonPe, Google Pay, Paytm და სხვ.), SDK/SDK/STARs.
Acquirer/Issuer: შემქმნელი ბანკი და გადამხდელი ბანკი.
Merchant PSP: UPI ბიზნესის მიმწოდებელი (SDK, QR, Intent, reconciliation).

3) იდენტიფიკატორები: VPA და დეტალები

VPA არის UPI მთავარი იდენტიფიკატორი: 'user @ psphandle' ან 'merchantname @ acquirer'.

• მიბმული საბანკო ანგარიშზე/Node UPI- ში.
• ეს შეიძლება იყოს პირადი (P2P) ან მერჩანტი (P2M) ბიზნესის დეტალებით.
• მხარს უჭერს გადახდის მოთხოვნას, ინვოისებსა და მეტამონაცემებს (orderId, purpose, MCC).

4) QR გადასახადები: სტატიკური vs დინამიური

სტატიკური QR

შეიცავს მერკანტის VPA/handle, ზოგჯერ ფიქსირებულ ველებს (MCC, სახელი).
თანხა შემოღებულია გადამხდელის ხელით (შესაფერისია კაფე/მცირე საცალო).
დადებითი: სიმარტივე, ბეჭდვა ერთხელ. უარყოფითი: არასწორი თანხის რისკი, უფრო სუსტი, ვიდრე ანალიტიკა.

დინამიური QR (per-order)

წარმოიქმნება თითოეული შემოწმებისთვის: შედის თანხა, orderID, purpose ველი, არჩევითი ფასდაკლება, prop ეტიკეტები.
გადამხდელის სკანი - პროგრამა ხსნის ინვოისს ფიქსირებული თანხით.
დადებითი: ნაკლები შეცდომა, უფრო ადვილია შერიგება, ერთგულება და ანტისახელმწიფოებრივი მტკიცებულებები.

Intent & Deep-Link Flow

სკანირების ნაცვლად, მერჩანტის პროგრამა იწყებს UPI კლიენტს deeplink/Intent URI- სთვის, გადადის თანხა და მეტამონაცემები.
მოსახერხებელია ელექტრონული კომერციის/პროგრამებში, საშუალებას გაძლევთ შექმნათ გლუვი UX კამერის გარეშე.

5) ტიპიური გადახდის ნაკადები

P2P (pull/push): მომხმარებლებს შორის თარგმნა VPA/ტელეფონით/QR.
P2M (push): მყიდველი იწყებს გადახდას (scan/გადახდა).
კოლექცია შენიშვნა (pull for the stunt): stunter აყენებს თხოვნას, მყიდველი ადასტურებს თავის UPI პროგრამაში.
AutoPate (e-mandate): გამოწერა ლიმიტის წინასწარი ავტომატიზაციით და სიხშირით, დებიუტი იწყება მანდატის გარეშე, ხელით დადასტურების გარეშე, ყველა ოპერაციამდე (ლიმიტით).

6) UPI ლიმიტები: როგორ მუშაობენ ისინი

ლიმიტები განისაზღვრება სქემის წესებით, RBI/NPCI პოლიტიკოსების, გამცემი ბანკების და ზოგჯერ მერჩანტის კატეგორიის მიხედვით. ისინი შეიძლება განსხვავდებოდეს მონაწილეებისგან, სარისკო პროფილისა და არხისგან.

1. Per-transaction cap (ოპერაციისთვის): საცალო სცენარების უმეტესობისთვის „ტიპიური“ მნიშვნელობა - 1.00,000 (1 ლაქი) გადახდაზე; ზოგიერთი კატეგორიისთვის ზემოთ/ქვემოთ.

2. Per-day cap (ერთი დღის განმავლობაში): შეზღუდვა გადახდის განაცხადის/ბანკის ოპერაციების მთლიანი მოცულობის/ქულის შესახებ.

3. კატეგორიული ლიმიტები: გარკვეული MCC- სთვის (მაგალითად, ინვესტიციები, განათლება/მედიცინა, ბილეთები, კომუნალური მომსახურება) შეიძლება მოქმედებდეს გაზრდილი/ინდივიდუალური ბარიერები.

4. ახალი მიმღები/რისკის ტაიმაუტები: ახალი VPA- ზე პირველი გადაცემის დროს შესაძლებელია შემცირდეს ერთჯერადი ლიმიტები და გამძლეობა.

5. UPI Lite (ოფლაინ მიკრო გადახდა): საფულე მოწყობილობაზე/ბანკში მცირე ოფლაინის გადახდისთვის; ლიმიტები ჩვეულებრივი UPI- ს ქვემოთ და ცალკე არის მითითებული (per-txn და დღე).

6. AutoPay (e-mandate): ავტომატური ჩამოწერის ლიმიტი ხელახალი ავთენტიფიკაციის გარეშე - დაფიქსირებულია მანდატში; სხვადასხვა კატეგორიისთვის - სხვადასხვა ბარიერები.

7. სცენარი/არხი: intents/QR შეიძლება ჰქონდეს საკუთარი ვალიდაცია (anti abuse, velocity).

7) უსაფრთხოება და ავთენტიფიკაცია

2FA: დადასტურება UPI პროგრამაში (PIN/ბიომეტრია) + დაკავშირება მოწყობილობასთან/SIM სლოტთან/აღრიცხვასთან.
Device binding: inti frode PSP განაცხადის დონეზე.
რეალურ დროში Risk პოლიტიკოსები: velocity ჩეკი, სანქცია/თაღლითური შაბლონები, მიმღების სახელის შემოწმება.
UPI Lite და offline: მიკროლიმიტები + დისტანციური პოსტინგი ბირთვში რისკების შესამცირებლად.

8) ტარიფები და კომისიები (MDR)

• გადასახადი/SDK fee UPI- ს შეძენისთვის,
• დამატებითი საფასური სერვისები (დინამიური QR, ჩანაწერების API, მენიუ, მოხსენებები),
• მხარდაჭერის, დავების და ანაზღაურების ხარჯები.

9) ამაღლება, ნაწილობრივი ზარალი და დავები (ODR)

Chargeback არ არის ბარათის გაგებით. დაბრუნება არის გადამხდელისთვის ახალი საკრედიტო ოპერაცია, რომელიც გულისხმობს თავდაპირველ გარიგებას.
პარტიული რეფუნდი მხარს უჭერს (ჯამში).
ODR (ონლაინ დისპute Resolution): ონლაინ პრეტენზიების მოგვარების სტანდარტული პროცესი - სტატუსები, SLA, უარის თქმის მიზეზი, მტკიცებულებები (გადახდის ლოგო, ჩეკი, სასაქონლო გადახდა).
ვადები: დამოკიდებულია ბანკზე/PSP; დააყენეთ დამხმარე რეგულაციები.

10) მერჩანტის ინტეგრაცია: ვარიანტები

1. სტატიკური UPI QR: მინიმალური განვითარება; კარგია POS/SMB- სთვის.
2. დინამიური UPI QR: სერვერი წარმოქმნის QR შეკვეთას; თანხის/შეკვეთის საუკეთესო გადამოწმება.
3. Intent/Deep Link: მობილური UX კამერის გარეშე; ვებ - გვერდი - „გახსნა UPI პროგრამა“.
4. კოლექცია (გადახდა): მორცხვი იწყებს „ანგარიშს“, კლიენტი ადასტურებს.
5. SDK/JS/Native: მზა PSP მოდულები Android/iOS/web სტატუსის დამუშავებით.

• გადახდის payload თაობა (VPA/თანხა/ეტიკეტი),
• კოლბეკი endpoint წარმატებული/წარუმატებელი გადახდისთვის,
• ჩანართი (კრიკეტი) TID/RRN/UTR- ზე,
• სახელმძღვანელო/ავტომატური refund,
• SLA PSP/ბანკების მონიტორინგი.

11) კრეკი და მოხსენება (UTR, სტატუსები)

UTR (Unique Transaction Reference) - უნიკალური გაანგარიშების იდენტიფიკატორი საბანკო სარკინიგზო მაგისტრალში; შეინარჩუნეთ იგი ყველა ოპერაციისთვის.
PSP ანგარიშებში: საწყისი პარამეტრები (VPA, თანხა, orderID), სტატუსები (initiated, pending, success, failure), გვიან განახლებები, ანაზღაურება.
სავალდებულოა ყოველდღიური auto-recon და პერიოდული full-recon (კოდექსი ბანკთან/PSP).

12) ოფლაინი და სმარტფონის გარეშე წვდომა

UPI Lite (მიკრო გადასახადი): მცირე თანხებისთვის; გარიგებები დადასტურებულია ქსელის მოთხოვნის გარეშე, პოსტინგი - მოგვიანებით.
UPI 123PAY/IVR/feature-phone: გადახდა ნომრით/IVR მენიუ.
Tap-and-Pay (NFC-UPI): უკონტროლო სცენარები იქ, სადაც არის მხარდაჭერილი.

13) ჯვრის ბორდერი (UPI გლობალური)

UPI თანდათანობით ინტეგრირდება უცხოურ რელსებთან/ქვეყნის პარტნიორობებთან (მაგალითად, ინდოეთის UPI-QR- ის სკანირება ტურისტების ან ინდოელების მიერ პარტნიორობის ქსელებში). მხარდაჭერა და ლიმიტები დამოკიდებულია წყვილებზე/პარტნიორებზე და ემიტენტ ბანკზე.

14) რისკები, AML/KYC, შესაბამისობა

KYC PSP/ბანკების დონე გავლენას ახდენს ლიმიტებზე.
AML/სანქციები: მიმღები/დანიშნულების ფილტრები, ანომალიების მონიტორინგი.
Frode Kasing: სახსრების დაბრუნება შეუძლებელია მერჩანტის თანხმობის გარეშე - საჭიროა შეკვეთის მკაცრი გადამოწმება (დინამიური QR, ჩეკი, გეო/მოწყობილობა).
ინდუსტრიის სამართლებრივი რეჟიმი: შეზღუდვები მოქმედებს ინდივიდუალური ვერტიკალებისთვის (MCC კატეგორიები, ლიცენზირება, გობლოკი შტატებში/UT). დაგეგმეთ ადგილობრივი UPI მიღება ადვოკატებთან თქვენი ტიპის ბიზნესისთვის.

15) UX და best-practices დიზაინი

შეცდომების ზედაპირი: აშკარად აჩვენეთ ტაიმერი, ინსტრუქციები და როგორ გავიმეოროთ გადახდა.
Idempotence: 'orderId' + idempotent- ის გასაღები safe გამეორებისთვის.
Fallback: თუ Intent არ გაიხსნა, შესთავაზეთ QR და „კოპირება VPA/თანხა“.
ინტერფეისის ლიმიტები: გააფრთხილეთ ჭარბი რაოდენობა და შესთავაზეთ ჩეკების გამანადგურებელი, სადაც ნებადართულია.
საიმედოობა: ექსპონენტის აღდგენა სტატუსისთვის, webhooks + pull-API.
გამჭვირვალობა: ჩეკი UTR- სთან, თანხა, თარიღი/დრო, VPA მერჩანტი, დამხმარე კონტაქტი.

16) ინტეგრაციის სიის სია (P2M)

1. მიიღეთ მერჩანტის VPA/handle PSP.
2. არხის არჩევა: სტატიკური/დინამიური QR, Intent, Collect.
3. Payload და უსაფრთხო კოლბეკების წარმოების განხორციელება.
4. ჩართეთ ჩანაწერები UTR/OrderID- ისთვის (daily + full).
5. მორთვა (ნაწილობრივი/სრული), ლოგოები და ODR.
6. შემოიღეთ ანტიფროდიული წესები (velocity, ახალი მიმღები, მაღალი დონის MCC განათება).
7. UI/UX: მინიშნებები, შეცდომები, გამეორება, ლიმიტების ჩვენება.
8. დაამყარეთ SLA PSP/ბანკების მონიტორინგი, ალერტები და ანგარიშგებები.
9. მიმდინარე ტესტების ჩატარება რეალურ UPI კლიენტებთან.
10. რეგულარულად განაახლეთ ლიმიტები/წესები (ბანკების/კატეგორიების მიხედვით).

17) ლიმიტის ბარათი (სახელმძღვანელო დიზაინისთვის)

Per-txn (საცალო): სახელმძღვანელო 1.00,000 ევრომდე.
Per-day: მთლიანი დღის ბარიერი ბანკში/განაცხადში; მითითებულია ადგილობრივად.
UPI Lite: მნიშვნელოვნად დაბალია, ვიდრე ჩვეულებრივი UPI (მიკროპლატა).
AutoPay (e-mandate): გარიგების ლიმიტი ხელახლა 2FA - მანდატის/კატეგორიის მიხედვით.
ახალი ბენეფიციარები: შემცირებული ერთჯერადი ლიმიტები ან/და შეფერხებები.
გაზრდილი ჭერის კატეგორიები: ეს დამოკიდებულია MSS/ბანკის წესებზე (მაგალითი: განათლება/მედიცინა/ბილეთები/ინვესტიციის სცენარები - შეთანხმდნენ).

18) QR სტრატეგიების შედარება მერჩანტისთვის

19) რა უნდა გაითვალისწინოთ iGaming/მაღალი რისკის ვერტიკალები

შეამოწმეთ PSP/Bank- ის კატეგორიის დაშვება და ადგილობრივი კანონის შესაბამისობა.
დაელოდეთ ვიწრო ლიმიტებს და გაფართოებული KYC/ODR- ს მოთხოვნას.
განიხილეთ ალტერნატიული რელსები ანაბრის/გამომავალი და ტრაფიკის მკაცრი სეგმენტი.

20) არქიტექტურული ნოტები

• endpoints: `createPaymentIntent`, `generateDynamicQR`, `refund`, `reconcile`, `webhook`.
• idempotence გასაღებები და dedupe ცხრილი.
• მოვლენების რიგები (event bus) სტატუსებისა და აღრიცხვისთვის.
• observability: მეტრიკა (წარმატება/წარუმატებლობა/ლატენტობა), ტრეკერი, ალერტები.
• Security: HMAC Webhooks ხელმოწერები, allowlist IP PSP, secret rotation.

რეზიუმე წარმოებისთვის

ფსონი დადეთ დინამიურ QR ან/და Intent.
ნუ დააყოვნებთ ლიმიტებს - კონფისკაცია + ბანკების განახლება/PSP.
ჩართეთ UTR Curvet, ნაწილობრივი ODR flow.
დაფარეთ UX უარის, გამეორებისა და გამჭვირვალე შემოწმების სცენარებით.
რეგულარულად გადახედეთ ლიმიტებისა და კატეგორიების პოლიტიკას PSP- სთან ერთად.