ფულადი ვაუჩერები და საცალო ქსელები

1) რა არის ეს და როდის უნდა გამოვიყენოთ

ფულადი ვაუჩერები და eCash ქსელები საშუალებას გაძლევთ მიიღოთ გადახდა საბანკო ბარათების გარეშე და IBAN. მომხმარებელი ყიდულობს წინასწარ გადახდილი ვაუჩერს (PIN) ან იღებს შტრიხკოდს/QR (გადახდა-at-store) და იხდის შეკვეთას პარტნიორის ოფლაინ წერტილში (კიოსკი, სუპერმარკეტი, ბენზინგასამართი სადგური, ფოსტა) ან ინტერნეტ ბანკში/ATM. თანხა მერჩანტს იღებს PSP/მიმწოდებლის მეშვეობით საბანკო რელსებზე; ცარჯბეკი არ არის, ფროდის რისკები მინიმალურია.

• ციფრული საქონელი/თამაშები, შინაარსი, ხელმოწერები დაბალი/საშუალო შემოწმებით.
• რეგიონები, რომლებსაც აქვთ მაღალი წილი ფულადი სახსრებით ან დაბალი ბარათის ჯარიმით.
• აუდიტორია, რომელიც უპირატესობას ანიჭებს კონფიდენციალურობას/წინასწარ გადახდას.

2) eCash ინსტრუმენტების ტიპოლოგია

1. PIN ვაუჩერები (წინასწარი გადახდილი კოდები):

მაგალითები: Paysafecard, Neosurf, Flexepin.
UX: 16-/10 ნიშნის PIN ჰოსტელის ფორმის ან საფულისგან გადახდა (myPaysafe/myNeosurf).
მახასიათებლები: ნაწილობრივი ჩამოწერები, რამდენიმე PIN კომბინაცია, დანარჩენი რჩება.

2. შტრიხკოდები/QR „გადახდა მაღაზიაში“:

მაგალითები: paysafecash, ადგილობრივი ქსელები (OXXO Pay - MX, RapiPago/PagoFácil - AR, Efecty/Baloto - CO, PayPoint/Payzone - დიდი ბრიტანეთი EU და სხვ.).
UX: მერკანტი წარმოქმნის barcode/QR - კლიენტი იხდის ფულადი სახსრებით სალაროებში, ხოლო პროვაიდერი უგზავნის დადასტურებას.
მახასიათებლები: ჩეკი ძალაშია შეზღუდული დროით (expiry), თანხა ფიქსირდება.

3. Reference/Slip for ATM/ონლაინ ბანკინგი (ინვოისის დეტალები):

მაგალითები: Multibanco References - PT, Konbini - JP.
UX: ნაჩვენებია კოდი/რეფერენდუმი + თანხა, გადახდა ATM/ონლაინ ბანკში/პარტნიორი მაღაზიაში.
მახასიათებლები: მინიმალური ფროდი, მკაცრი რეფერენდუმის შერჩევა.

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

პროვაიდერი/სქემა (eCash/ვაუჩერები): აწარმოებს PIN/harkods, აწარმოებს საცალო კატალოგებს, KYC/AML, ანტიფროდს, აძლევს API/ვიჯეტებს.
PSP/შემქმნელი: აკავშირებს მერჩანტს, ჰოსტედის სალაროებს/SDK, სტატუსებს, ვებ ჰუკებს, რეესტრებსა და გამოთვლებს.
საცალო/სალარო: ფულადი სახსრების მიღება/შტრიხკოდის კითხვა, პროვაიდერთან სინქრონიზაცია.
ბანკი/გამწმენდი: ანგარიშსწორება და ფულადი სახსრების დაქირავება.
მერჩანტი: იწყებს გადახდას/ინვოისს, ამუშავებს სტატუსებს, ვარგისებს და ჩანაწერებს.

4) გადახდის ნაკადები

4. 1 Posted/Redirect

1. Checkout არის eCash- ის არჩევანი (მაგალითად, Paysafecard/Neosurf).
2. Redirect/Hosted პროვაიდერის ფორმა არის PIN/საფულის შესვლა დადასტურება (SCA/ქცევითი სკრიპტი).
3. დაბრუნება ციმციმში: 'success/pending/failed/canceled/expired'.
4. ფაქტობრივი სესხი - ყოველდღიური რეესტრებისთვის (T + 1/T + 2).

4. 2 შტრიხკოდი/QR „გადაიხადეთ მაღაზიაში“

1. მერჩანტი ქმნის ინვოისს: თანხა + barcode/QR + expiry.
2. კლიენტი მიდის საცალო წერტილში და იხდის ფულადი სახსრებით, სალარო ადასტურებს ოპერაციას პროვაიდერს.
3. პროვაიდერი უგზავნის მერჩანტს ონლაინ წარმატებას, შემდეგ - სესხს რეესტრში (T + 0/T + 1).

4. 3 რეგულირება/სლიპი (ATM/ონლაინ-ბანკინგი/კონბინი)

1. რეფერენდუმის წარმოება (entity/reference/amount) + მოქმედების ვადა.
2. გადახდა ATM/ონლაინ ბანკში/პარტნიორი მაღაზიაში.
3. ონლაინ სტატუსი 'paid' და შემდგომი settlement რეესტრებში.

5) სტატუსები და გამოთვლები

ონლაინ სტატუსები: 'created '/' pending '/' success' paid '/' failed '/' canceled '/' expired '.
Settlement: ჩვეულებრივ T + 0/T + 2 საბანკო დღე (ხელშეკრულებით/არხით).
ბიზნეს ლოგიკაში გაიზიარეთ ონლაინ დადასტურება და ფაქტობრივი სესხი.

6) ლიმიტები, KYC და რისკი

• Per-transaction, 24h/7d, PIN ნომრის ლიმიტი დღეში.
• ახალი მიმღებებისთვის/მერჩანტებისთვის - შემცირებული ბარიერები/ჩამკეტი.
• გეო წესები (ვაუჩერის ქვეყანა კლიენტის/მერჩანტის ადგილმდებარეობის შესახებ), velocity, devais სიგნალები.
• ჩარჟბეკი არ არის; დებატები - ODR პროვაიდერის/PSP მიხედვით.
• რეკომენდაცია: შეინახეთ შეზღუდვები ქვეყნის/ქსელების/CCC- ის მიხედვით და არ დააკონკრეტოთ თანხები.

7) ამაღლება და ნაწილობრივი გაუქმება

Refund = ახალი საკრედიტო ოპერაცია (eCash/საბანკო გადარიცხვით - პროვაიდერის წესების შესაბამისად).
ჩვეულებრივ მხარს უჭერს წვეულება.
PIN ვაუჩერებისთვის ხშირად შესაძლებელია ნაწილობრივი ჩამოწერები და PIN კომბინაცია; barcode-invois- ისთვის - თანხა ფიქსირდება.

8) ეკონომიკა და ტარიფები

ციმციმის საკომისიო ჩვეულებრივ დაბალია, ვიდრე CNP ბარათის MDR, მაგრამ განსხვავდება გეო/მოცულობით/კატეგორიაში.
დამატებითი ხარჯები: მასპინძელი/SDK, გაყიდვების წერტილების რეკლამა, sapport/ODR, დამუშავება 'expired/pending', ჩანაწერები.

9) UX ნიმუშები

PIN გადახდა: გასაგებია UI რამდენიმე PIN და დარჩენილი მაჩვენებელი; შეცდომების შესახებ შეტყობინებები: „არასწორი/გამოყენებული“, „ლიმიტი აღემატება“, „რეგიონი არ არის მხარდაჭერილი“.
Barcode/QR: დიდი კოდი + მოქმედების დრო, ღილაკი „დაბეჭდვა/გაგზავნა მესენჯერი/email“.
ხაზგარეშე გადახდის ინსტრუქციები: 3-4 ნაბიჯი ქსელის ლოგოებით; უახლოესი წერტილების/საათის რუკა.
შეკვეთის მდგომარეობა: „ელოდება გადახდას“ ავტო განახლებით; "expired '- ზე - ღილაკი" შექმენით ახალი კოდი ".
ქვითარი: თანხა, დრო, 'payshID', არხი (PIN/Barcode/Reference), UTR/რეფი. რეესტრიდან, საფორტეპიანო კონტაქტები.
ლოკალიზაცია: ვალუტა/ენა/საგადასახადო ტექსტები, ადგილობრივი ქსელის ბრენდები.

10) უსაფრთხოება და შესაბამისობა

PII მინიმალიზაცია: PIN/საფულე შემოღებულია პროვაიდერის მხარეს (Hosted/Widget).
ვებ-ჰუკები: HMAC/nonce, დაცვა replay, მოვლენების დედაპლატი, აუდიტის ჟურნალი.
KYC/AML/GDPR: ასაკობრივი/შეზღუდული წესები წინასწარ გადახდილი სახსრებისთვის, სანქციების/გეო შეზღუდვების შესახებ.
ანტიფროდი: მოწყობილობის/სესიის ლიმიტები, კოლინგ-ოფი, ეტაპი, განმეორებითი PIN/ბარკოდების მონიტორინგი.

11) ინტეგრაცია და არქიტექტურა

დაკავშირების პარამეტრები

1. Hosted/Embedded PSP/პროვაიდერში - სწრაფი გაშვება, მინიმალური პასუხისმგებლობა მგრძნობიარე მონაცემებზე.
2. Server to-Server + Hosted - საკუთარი შემოწმება სტატუსის კონტროლით, თქვენი PIN დამუშავების გარეშე.
3. Pay-by-Link/Invoice - გადასახადები და საპორტო შემთხვევები.

ზურგჩანთა მინიმუმი

API: `createPayment|createInvoice` (amount + expiry), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idempotence ('orderId' + გასაღები), ექსპონენციალური retrais, DLQ, ვებ-ჰუკების დედაპლატი.
კატალოგები: ქვეყნები/ქსელები/ლიმიტები/KUS დონე, შეცდომების კოდი, SLA მეტრიკა არხებით.
Observability: კონვერტაცია (PIN vs Barcode/Reference), წილი 'pending-expired ", საშუალო ტაიმები გადახდაზე/settlement, გეო-ანომალიები.

12) გეოგრაფიული შენიშვნები (სახელმძღვანელო)

Европа: Paysafecard, paysafecash, Neosurf, PayPoint/Payzone (UK), ePay/Paylink (EU), Multibanco (PT).
ЛатАм: OXXO Pay (MX), RapiPago/PagoFácil (AR), Efecty/Baloto (CO).
აზია: კონბინი (JP) და ადგილობრივი ქსელები (FamilyMart/Lawson/7-Eleven).

13) Check Life Prode

1. შეარჩიეთ პროვაიდერი/PSP და სამიზნე ქსელები (PIN/Barcode/Reference), დააკონკრეტეთ ტარიფები/SLA/settlement.
2. გააცნობიერეთ 'CreatePayment' CreateInvoice 'expiry, ინსტრუქციის გვერდები და fallback სცენარები.
3. დააკავშირეთ webhooks (HMAC), idempotence, retrai და მოვლენების დედობა.
4. კონფიგურაცია daily auto-recon + full-recon, შეინახეთ UTR/fin რეფერენდუმი.
5. ჩართეთ partial refunds, ODR პროცედურები და გასაგები ცნობები უარის თქმის/ლიმიტების შესახებ.
6. SLA დაშბორდები (კონვერტაცია, 'expired', გადახდის დრო/settlement) და რასკინქრონული ალერტები.
7. ჩაატარეთ e2e ტესტები: რამდენიმე PIN, ვადაგასული შტრიხკოდი, არასწორი თანხა, ორმაგი გადახდა, ნაწილების დაბრუნება.

სახელმძღვანელო ბარათი

Статусы: `created/pending/success|paid/failed/canceled/expired`.
Settlement: ჩვეულებრივ T + 0-T + 2 PSP/პროვაიდერის რეესტრებში.
Chargeback: არ არის; refund არის ცალკეული საკრედიტო ოპერაცია.
ლიმიტები/CCC: დამოკიდებულია ქვეყნის/ქსელის/არხისა და კლიენტის პროფილის მიხედვით.
რეკურენტი: პირველი eCash - მანდატი (SEPA/Open-Banking/ადგილობრივი) შემდგომი გაუქმებისთვის.

რეზიუმე

სტრატეგია: eCash მიქსი (PIN + barcode/QR + reference) ფულადი აუდიტორიის გაშუქებისა და MDR- ის შემცირების მიზნით.
Webhooks + recon- ის გარშემო არსებული არქიტექტურა, მკაცრი იდემპოტენტობა და გასაგები UX 'pending/expired'.
Limit/KUS და Geo წესების კონფისკაცია - კოდის გარეთ, რეგულარული განახლებით.
ხელმოწერებისთვის - პირველი eCash - მანდატი, გამჭვირვალე მენეჯმენტი და შეტყობინებები მომხმარებლისთვის.