E-wallets: მიმოხილვა და შედარება

1) რა არის e-wallet და რატომ არის ის მერჩანტი

• უფრო მაღალი კონვერტაცია App2App/One-tap- ის, ადგილობრივი აღიარებისა და შენახული მონაცემების გამო.
• დაბალი ფროიდი (SCA, მოწყობილობის შემცირება, პროვაიდერის რისკის შემცირება).
• სახსრების წყაროების მოქნილობა: რუკა, A2A (საბანკო გადარიცხვა/Open banking), cash ვაუჩერები, მობილური ბალანსი.
• გაფართოებული გეოგრაფია და აუდიტორიაზე წვდომა ბარათების/სესხის გარეშე.

2) საფულეების კლასიფიკაცია

1. Stored-value (ბალანსი)

მომხმარებელი ფულს ინახავს საფულეში. Fichi: ტოპ, შიდა ლეგენდა, P2P, გადახდები ბალანსიდან. მაგალითები: Skrill/Neteller, MyPaysafe/myNeosurf, ადგილობრივი EMI საფულეები.
უპირატესობები: სწრაფი გამეორება/გადახდა, აუდიტორიის ოფის ბარათი. უარყოფითი მხარეები: KYC დონე, ლიმიტები ტოპ/წამში.

2. Pass-through / Pay-by-bank / Bank-linked

თანხა პირდაპირ იწერება საბანკო ანგარიშიდან/ბარათის საშუალებით განაცხადში დადასტურების გზით (ხშირად ბალანსის შენახვის გარეშე). მაგალითები: MB WAY, Swish, Vipps, TWINT, Bizum.
პლუსები: დაბალი ფროიდი და MDR, მყისიერი სესხები. უარყოფითი მხარეები: ბანკების შეზღუდვები, კლასიკური chargeback- ის არარსებობა.

3. ჰიბრიდები

საფულე + ბარათი/ვირტუალური ბარათი/მარშრუტი (მაგალითად, wallet-card rails), ან სუპერ პროგრამები ინვოისებით, QR, P2P, გადახდა-by-link.

3) სახსრების წყაროები და ნაკადები

Top-up: ბარათი (CNP/3DS), A2A (SCT/SEPA Instant, RTP), cash მომხმარებლები, აგენტის წერტილები.
Pay-in (merchant): App2App/Deep Link, QR per-order, hosted გვერდი, ტოკნიზირებული COF/Network tokens (მუყაოს საფულეებისთვის).
P2P: ტელეფონით/ალიასით, საფულის/სქემის შიგნით.
Cash-out: საბანკო გადარიცხვა (SCT/ACH/RTP), ბარათზე (OCT/Push-to-Card), ოფლაინ ქსელში, ნაკლებად ხშირად - ვაუჩერისთვის.

4) UX ნიმუშები, რომლებიც გავლენას ახდენენ კონვერსიაზე

App2App/Deeplink სალაროში დაბრუნებით და თანხის/ბრძანებების წინასწარ შევსებით.
დინამიური QR per-order (desctop/offline), ცხოვრების დრო, მანქანის განახლება.
One-tap/One-click პირველადი სავალდებულო შემდეგ (სადაც ნებადართულია).
მკაფიო შეცდომები და ჩანაწერები: ლიმიტი, ტაიმუტი, SCA- ს უარყოფა; უსაფრთხო გამეორება + ალტერნატიული მეთოდის შეთავაზება.

5) ლიმიტები, KYC დონე და რისკი

Per-transaction/24h/7d/monthly, ცალკეული ბარიერები ახალი მიმღების/მერჩანტებისთვის.
KYC დონე (ანონიმური/გამარტივებული/სრული): განსაზღვრავს სიმაღლეებს ტოპ-აპის/ხარჯების/დასკვნების მიხედვით.
Velocity/devais/geo წესები, სანქციები, ასაკობრივი შეზღუდვები.
High-risk ვერტიკალური (iGaming- ის ჩათვლით): გამკაცრებული ლიმიტები, ყინულები, გაფართოებული მონიტორინგი.

6) ამაღლება, დავა და საბოლოო

Chargeback: stored-value ხშირად არ აქვს კლასიკური chargeback; ბარათის რელსებზე საფულეებს აქვთ ბარათების წესები.
Refunds: როგორც წესი, ცალკეული საკრედიტო ოპერაცია საფულეში/კლიენტის ანგარიშზე.
A2A- ს საბოლოო: გადახდები საბოლოო დადასტურების შემდეგ; იმუშავეთ პროვაიდერის ODR პროცედურებთან.

7) ეკონომიკა: კომისიები და ფარული ხარჯები

MDR/fee ჩვეულებრივ დაბალია, ვიდრე CNP ბარათები; დამოკიდებულია გეოზე, ბრუნვაზე, MCC კატეგორიაზე.
დამატებითი ხარჯები: მასპინძელი/SDK, დამუშავება 'pending/expired', საფოსტო/ODR, ჩანაწერები, მანდატების/ხელმოწერების მომსახურება, AML/KYC შემოწმება.

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

• `created → pending → success | failed | canceled | expired`
• Settlement: T + 0/T + 2 პროვაიდერის რეესტრში/PSP. ბიზნეს ლოგიკაში გაიზიარეთ ონლაინ დადასტურება და ფაქტობრივი სესხი.

9) შედარებითი კრიტერიუმების მატრიცა

ტიპი: stored-value/pass-through/ჰიბრიდი

სახსრების წყაროები: ბარათი/A2A/eCash/მობილური ბალანსი

UX არხები: App2App/QR/Hosted/Pay-by-Link

P2P/Payouts: არის/არა, ლიმიტები და ვადები

Refund/Chargeback: არის თუ არა chargeback; partial refunds

კონვერტაცია: მობილური პრიორიტეტი, One-tap

კომისია: სახელმძღვანელო CNP ბარათების წინააღმდეგ

რისკი: ფროიდი, საბოლოო, მარეგულირებელი მოთხოვნები

გეო-გაშუქება/ადგილობრივი ბრენდი: აღიარება სამიზნე აუდიტორიაში

10) ინტეგრაცია: პარამეტრები და მინიმალური უკანა პლანზე

1. Hosted/Embedded PSP/საფულე - სწრაფი დასაწყისი, მინიმიზაცია PII.

2. სერვერი to-Server + App2App/QR არის კასტომიური UX, საკუთარი საფულის არჩევის გვერდი.

3. Pay-by-Link/Invoice - მოსახერხებელია გადავადებული გადახდების/კოლეგებისთვის.

• API: `createPayment`, `refund`, `webhook`, `queryStatus`, `reconcile`.
• Idempotention ('orderId' + გასაღები), ექსპონენციალური retrais, მოვლენების დედაპლატი, DLQ.
• Webhooks: HMAC/nonce, replay დაცვა, redirect-URI მკაცრი შესაბამისობა.
• ჩანაწერები: daily auto-recon + პერიოდული full-recon; შეინახეთ UTR/ფინი. რეფერენდუმი.
• კატალოგები: პროვაიდერები/ქვეყნები/ლიმიტები/KUS/შეცდომების კოდი; SLA მეტრიკა არხებით.
• Observability: კონვერტაცია (საფულეების/არხების საშუალებით), 'pending/success/expired', ლატენტობა settlement/დაბრუნებამდე.

11) გამოწერები და მანდატები

• პირველი გადახდა არის მანდატი (SEPA DD/Open Banking/მანდატი საფულე).
• შეინახეთ per-debit ლიმიტი, სიხშირე, ჩამოწერის ფანჯარა, პრეს - შენიშვნები და UI მენეჯმენტი (pause/cancel/განახლება).

12) ანტიფროდიული პრაქტიკა

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

13) შერწყმა და მოხსენება (ოპერაციული სიმწიფე)

• 'payhoud Id/transaction Id', 'orderid', საფულე/არხი (App2App/QR/Hosted/Link), სახსრების წყარო (ბარათი/A2A/eCash), სტატუსი, თანხა/ვალუტა, tiMimemestestampestampstamps, umps, um/საბანკო ბმული/საბანკო ბმული ბმული ბმული ბმული ბმული ბმული.
• Deashboards SLA: საფულეების კონვერტაცია, „expired“ წილი, ჩარიცხვამდე დრო და რეფუნდამდე, SCA/limites- ის უარყოფა.
• Alerty on rassinhrons: ონლაინ წარმატება რეესტრში ჩაწერის გარეშე, ორმაგი ჩამოწერა, „შეჩერებული“ პენდინგი.

14) iGaming და სხვა მგრძნობიარე ვერტიკალები

შეამოწმეთ პროვაიდერის პოლიტიკა და ადგილობრივი სამართალი (წვდომა, შეზღუდვები, ჰოლდინგები).
დაგეგმეთ ალტერნატიული რელსები (ბარათები/A2A/eCash) და smart-routing რისკის/გეო/საფულე.
მოამზადეთ გაფართოებული ანგარიშგებები (საშუალებების წყარო, მოთამაშის ლიმიტები, გადახდის სიჩქარე, გადახდის სიგნალები).

15) მინი შედარება სტანდარტულ პროფილებზე

A. ადგილობრივი ბანკი-ლინკირებული საფულეები (MB WAY/Swish/Vipps/TWINT/Bizum მსგავსი)

კონვერტაცია: მაღალი (App2App/QR, ჩვეულებრივი ბრენდი).
Frode/chargeback: დაბალი/არ არის; refund, როგორც ცალკე სესხი.
ლიმიტები: განსაზღვრავს ბანკებს/სქემას; უფრო მკაცრია ახალი მიმღები/გადასახადებისთვის.
გამოყენება: მასობრივი გადახდა, ბილეთები/მომსახურება, iGaming - PSP/ბანკების პოლიტიკის შესახებ.

B. Stored-value (Skrill/Neteller/myPaysafe/myNeosurf и др.)

კონვერტაცია: მაღალი აქტიური მომხმარებლის მონაცემთა ბაზაში.
Frode: დაბალი, მაგრამ მოითხოვს მკაცრ KYC/AML.
დადებითი: სწრაფი ნაწილობრივი გამეორება, მყისიერი გამეორება, P2P.
უარყოფითი მხარეები: KYC დონის ტოპ-ap/დასკვნის ლიმიტები.

C. eCash/wacker წყაროები საფულეების შიგნით

აუდიტორია ბარათების/ბანკების გარეშე: კრიტიკულად გეო ფულადი ეკონომიკისთვის.
საბოლოო: მაღალი; დაბრუნება - საკრედიტო ოპერაცია.
UX: მნიშვნელოვანია აჩვენოს „სად შეიძინოთ ვაუჩერი“ და ინვოისის/შტრიხკოდის მოქმედების ტაიმერი.

16) ელექტრონული ვალეტების ჩეკის სია პროდ

1. Barket-fit: შეარჩიეთ 2-4 საფულე გეო/აუდიტორიაში; შეაფასეთ ბრენდის აღიარება.
2. კონტრაქტი/PSP: ტარიფები, SLA webhooks/reestrams, settlement ვადები, დაბრუნების პოლიტიკა.
3. ინტეგრაცია: 'CreatePayment' + App2App/QR/Hosted, შეცდომების/ლიმიტების ეკრანები, უსაფრთხო გამეორება.
4. უსაფრთხოება: HMAC/nonce, allowlist IP, მკაცრი redirect-URI, vault საიდუმლოებები.
5. ჩანაწერები: daily + full, UTR- ის შენახვა, რასკინქრონული ალერტები.
6. Refunds/ODR: partial/full, დაუკავშირდით თავდაპირველ ბრძანებას, საფორტეპიანო წესებს.
7. KUS/limites: ჩამორთმევა პროვაიდერების/არხების საშუალებით, UI უარის თქმის მიზეზები და ალტერნატივის შეთავაზებები.
8. Observability: კონვერტაციის/ლატენტობის/expired დაშბორდები, მოწყობილობების/ბანკების/საფულეების ნაჭრები.
9. ტესტირება: e2e ძირითადი ბანკების/საფულეების მიხედვით, დესკტოპის QR, სუსტი ქსელი/ტაიმაუტები, „შეჩერებული“ პენდინგი, ნაწილები.

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

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

რეზიუმე

ააშენეთ ფულადი სახსრების სალარო App2App/QR- ით და მკაფიო ჩანაწერებით-UX - ეს ზრდის კონვერსიას და ამცირებს ფროდს.
შეინახეთ limites/KUS/შეცდომები კონფისკაციაში და არა კოდში; რეგულარულად განაახლეთ პროვაიდერები.
ოპერაციული საიმედოობა უზრუნველყოფილია webhooks + მძიმე ჩანაწერებით, idempotence და ანალიტიკით 'success/expired'.
გამოიყენეთ მანდატები ხელმოწერებისთვის; მაღალი რისკისთვის, შეინარჩუნეთ ალტერნატიული რელსები და ჭკვიანი როტინგი რისკისა და გეოგრაფიისთვის.