PayID ავსტრალია: NPP ნაკადები

1) კონტექსტი: NPP და PayID

NPP (New Payments Platform) არის ავსტრალიის ეროვნული მყისიერი გადახდის ინფრასტრუქტურა (24/7/365) რეალურ დროში გათვლებით და მდიდარი ISO 20022 შეტყობინებით. PayID არის მისამართის ფენა NPP- ზე, რომელიც საშუალებას გაძლევთ გადაიხადოთ არა BSB/Account, არამედ „ადამიანის“ ალიასის მიხედვით: ტელეფონის ნომერი, ელ.ფოსტა, ABN/ACN ან ორგანიზაციული ID.

• ინტეროპერაციული: NPP- ს ნებისმიერი წევრი არის ნებისმიერი გამცემი ბანკი.
• ალიასის მიმართვა: გადამხდელი ხედავს PayID- ს დადასტურებამდე (anti-misdirection).
• მყისიერი და საბოლოო: სესხი ციმციმის ანგარიშზე დაუყოვნებლივ არის ნაჩვენები; დაბრუნება - ცალკე ოპერაცია.
• გადახდის მონაცემები: ISO 20022 მოსახერხებელი რემიტენსით (გადახდის დანიშნულება, orderID და ა.შ.).

2) მონაწილეები და როლები

NPP/სქემა: მარშრუტიზაცია და წესები.
გადამხდელის ბანკი (Payer FI): კლიენტის ავთენტიფიკაცია, ანტიფროდი, შეტყობინებების გაგზავნა.
მიმღების/შეძენის ბანკი (Payee FI): სესხის მიღება, შეტყობინებები, ანგარიშგებები.
PSP/fintech: წინა ხაზის პროგრამები, SDK, მოხსენებები და რეკონსტრუქცია მერჩანტებისთვის.
მერჩანტი: ინახავს PayID- ს (ან საბანკო დეტალებს), წარმოქმნის გადამხდელს მოთხოვნას/ბმულს.

3) იდენტიფიკატორები PayID

PayID- ის ტიპები: მობილური, email, ABN/ACN, Organisation ID.

• თითოეული PayID შედარებულია PayID Name, რომელსაც გადამხდელი ხედავს დადასტურებამდე.
• ერთ ქულას შეიძლება ჰქონდეს რამდენიმე PayID; ბანკებს შორის ტრანსპორტირება მხარს უჭერს მიგრაციის პროცედურებს.
• ABN/ACN-PayID მოსახერხებელია ბიზნესისთვის: უფრო ადვილია კომპანიის პროფილის შესრულება.

4) ძირითადი გადახდის ნაკადები (NPP/PayID)

P2P (push): გადამხდელი შემოაქვს/სკანირებს მიმღების PaID- ს, ხედავს PayID Name და დაუყოვნებლივ ადასტურებს სესხს.
P2M (push): marsher აქვეყნებს PayID- ს ან გამოსცემს deeplink/QR- ს წინასწარ სავსე თანხით და მეტამონაცემებით.
Request to-Pay: კოლექცია იწყებს გადახდის მოთხოვნას; მომხმარებელი ადასტურებს საბანკო პროგრამაში.

• ელექტრონული კომერციისთვის გამოიყენეთ deeplink/QR ფიქსირებული თანხით და orderID.
• ოფლაინისთვის დავუშვათ სტატიკური PayID, მაგრამ უკეთესია - დინამიური QR per-order.

5) PayTo: e-mandates და autospies

• მერჩანტი/PSP ქმნის მანდატს პარამეტრებით (გადამხდელი, ანგარიში, ლიმიტები, სიხშირე, აღწერა).
• გადამხდელი მანდატს აძლევს თავის საბანკო პროგრამაში.
• შემდეგი, ჩამოწერები ავტომატურად ხდება მანდატის პირობების ფარგლებში, ზედმეტი ხელით ავთენტიფიკაციის გარეშე.
• სკრიპტები: გამოწერა, კომუნალური/ხბო, რეგულარული გეგმები, ჭერის ბილინგი.

• აჩვენეთ მომხმარებელს მანდატის ლიმიტები, სიხშირე და შემდეგი ჩამოწერის თარიღი.
• შეინარჩუნეთ მანდატის კონტროლის პანელი (pause/cancel/განახლება) და ვებ ჰუკები სტატუსის შესახებ.

6) ლიმიტები და რისკის კონტროლი

• Per-transaction/Per-day: NPP/PayID- ის საბანკო ბარიერები შეიძლება განსხვავდებოდეს და შეიცვალოს.
• ახალი მიმღები: ხშირად მოქმედებს შემცირებული საწყისი ლიმიტები ან/და გამძლეობა.
• კატეგორიული პოლიტიკოსები: ინდივიდუალური MSS/ვერტიკალები შეიძლება გამკაცრდეს.
• PayTo მანდატები: ლიმიტები მოცემულია თავად მანდატში (თანხა, პერიოდი, მაქსიმ. ჩამოწერა).

• ნუ დაზოგავთ თანხებს - შეინახეთ ლიმიტების საცნობარო წიგნი და რეგულარულად განაახლეთ.
• ინტერფეისში, გააფრთხილეთ შესაძლო ჭარბი რაოდენობა და შესთავაზეთ ჩეკების გამანადგურებელი, თუ ეს დასაშვებია.

7) UX და უსაფრთხოება

Payee- ის კონფიგურაციის მსგავსი შემოწმება: PayID- ის ჩვენება Name ამცირებს ადრესატის შეცდომის რისკს.
2FA და მოწყობილობები გადამხდელის ბანკიდან ავტორიზაციის დროს.
ანტიფროდი/ველი: ბანკებს აქვთ საკუთარი წესები; გაითვალისწინეთ შესაძლო „რბილი“ უარი.
გამჭვირვალობა: შემოწმება UTR/დროით/თანხა/დანიშნულება + დამხმარე კონტაქტები.
Fallback: თუ deeplink არ გაიხსნა, შესთავაზეთ PayID- ის კოპირება, სტატიკური QR და ინსტრუქციები.

8) ამაღლება და დავა

ჩარჟბეკი კარტის გაგებით არ არის. დაბრუნება არის ახალი საკრედიტო გარიგება გადამხდელისთვის, რომელიც მოიხსენიებს წყაროს UTR/OrderID.
შეინარჩუნეთ ნაწილობრივი უგულებელყოფა და სრული ტრეკინგი მოხსენებებში.
დავები წყდება ბანკების/PSP და დამხმარე რეგულაციების საშუალებით; განათავსეთ SLA და მტკიცებულებების შეგროვება (შეკვეთის ჟურნალი, მიტანა, მიმოწერა).

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

1. სტატიკური PayID

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

2. დინამიური QR/deeplink

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

3. Request-to-Pay

„ანგარიში“ გადამხდელისგან - გადამხდელის დადასტურება.
მოსახერხებელია ინვოისისთვის, B2B და ცვლადი თანხით მომსახურებისთვის.

4. PayTo (e-mandates)

გამოწერა/რეგულარული ჩამოწერა; გადამხდელი ასრულებს მანდატს თავის ბანკში.
ჩვენ გვჭირდება თანხმობის ეკრანები, ლიმიტების მართვა, შეტყობინებები გაუქმებამდე.

• Success/failure/pending, განმეორებითი გამოკითხვები backoff- ზე.
• Idempotenty ცხრილი (orderId + მოთხოვნის გასაღები).
• რეკონსტრუქცია UTR/OrderID/ოდენობით.
• Refund API და ODR პროცედურები.
• SLA ბანკების მონიტორინგი/PSP (ლატენტობა, წარმატება, შეცდომების კოდი).

10) შერჩევა და მოხსენება (ISO 20022, UTR)

UTR (თარგმანის უნიკალური იდენტიფიკატორი) - შერიგების მთავარი გასაღები; შეინარჩუნეთ როგორც თავდაპირველი გადახდა, ასევე დაბრუნება.
გამოიყენეთ დანიშნულების/რემიტენის ველები ISO 20022 orderid- ისთვის, კალათის, customerRef- ისთვის.
Daily auto-recon (ოპერაციული) და პერიოდული full-recon (ფინანსური) პარამეტრები.
PSP ანგარიშები: გარიგებები, სტატუსები, PayTo მანდატები, გადახრები, გადახრები.

11) ტარიფები და ხარჯები

NPP/PayID- ისთვის არ არსებობს კლასიკური MDR, როგორც ბარათების სქემებში, მაგრამ არსებობს პროვაიდერის საფასური შეძენის, PayTo მოდულების, ანგარიშების, SLA პაკეტების მისაღებად.
გაითვალისწინეთ მხარდაჭერა/დავა, ანტიფროდი, QR თაობა და მასპინძლობა deeplink გვერდებზე.

12) ოფლაინის პარამეტრები და QR

Merchant-presented QR (დინამიური): ოპტიმალური POS/სალარო; თანხა და მეტამონაცემები კოდშია ჩასმული.
სტატიკური QR: დაშიფვრა PayID თანხის გარეშე; თანხა შემოღებულია ხელით.
ბეჭედი-ჩეკზე/ფირფიტაზე: დასაშვებია მცირე ბიზნესისთვის, მაგრამ უარესი.

13) შესაბამისობა, AML/CTF და კონფიდენციალურობა

დაიცავით AML/CTF (AUSTRAC) მოთხოვნები, გარიგების/მანდატების ლოგოების შენახვა, KYC დონე PSP- ში.
გამოიყენეთ სანქციები/frode სკრინინგი PSP დონეზე, Velocity წესები, ანომალიების მონიტორინგი.
PaID- ის მონაცემების დამუშავება მინიმიზაციის პრინციპების შესაბამისად; აჩვენეთ მხოლოდ ის, რაც საჭიროა UX და აუდიტი.

14) მაღალი რანგის თვისებები (iGaming- ის ჩათვლით)

ავსტრალიაში ბანკებს/PSP- ს შეუძლიათ შეზღუდონ გარკვეული კატეგორიები საკუთარი რისკის პოლიტიკოსების მიხედვით.
დაელოდეთ KYC- ს მიერ გაძლიერებული ლიმიტების შემცირებას და დამატებითი გარიგების ანალიტიკას.
დაგეგმეთ ალტერნატიული რელსები დეპოზიტებისთვის/გადასახადებისთვის და დაბრუნების მკაფიო პროცესი.

15) მომსახურების არქიტექტურა „NPP/PayID Gateway“

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
საიმედოობა: ექსპონენტის აღდგენა, იდემპოტენტობა, მოვლენების დედაპლაცია.
Observability: მეტრიკა (წარმატება/წარუმატებლობა/ლატენტობა), კვალი, ალერტები SLA ბანკებისთვის.
უსაფრთხოება: HMAC ხელს აწერს ვებ-ჰუკებს, allowlist IP, საიდუმლოების როტაციას, აუდიტის ჟურნალს.
მონაცემები: ცალკეული შეზღუდვების საცნობარო წიგნები ბანკების/არხების საშუალებით, PayTO მანდატების სტატუსები, UTR ბარათი.

16) Check Life Prode

1. მიიღეთ Merchant PayID (ან PayID აუზი) ბანკიდან/PSP.
2. შეარჩიეთ ნაკადი: დინამიური QR/deeplink, Request-to-Pay და/ან PayTo.
3. გააცნობიერეთ ვებ ჰუკები, idempotence და მანდატების ცხრილი.
4. ჩართეთ UTR ორიენტირებული ჩანაწერი (daily + full), რასკინქრონული ალერტები.
5. დაიწყეთ Refund flow (სრული/ნაწილობრივი), ODR ჟურნალები.
6. დაამატეთ UX ლიმიტების ეკრანები, გადახედეთ PayID- ს, გასაგებ შეცდომებს.
7. კონფიგურაცია SLA და პროვაიდერის დაშბორდები.
8. შაბათ-კვირის ტესტების ჩატარება სხვადასხვა გამცემი ბანკებით და PayTo- ს სცენარებით.

რეზიუმე

ერთჯერადი გადახდისთვის, ფსონი დადეთ დინამიურ QR/deeplink- ზე მდიდარი მეტამონაცემებით.
ხელმოწერებისა და რეგულარული გადახდებისთვის გამოიყენეთ PayTo მანდატები გამჭვირვალე UX მენეჯმენტით.
არ დააკოპიროთ ლიმიტები მკაცრად: შეინახეთ კონფიგურაცია ბანკებზე/PSP და განაახლეთ.
ააშენეთ პროცესი UTR- ის შერიგების, დეტალური ლოგოგრაფიისა და ალერტინგის გარშემო SLA- სთვის.