Paysafecard: წინასწარ გადახდილი ვაუჩერები

1) რა არის Paysafecard და როდის უნდა აირჩიოთ იგი

Paysafecard არის წინასწარ გადახდილი ვაუჩერის მეთოდი: მომხმარებელი ყიდულობს ვაუჩერს ნაღდი ანგარიშსწორებით/ბარათით საცალო პარტნიორებისგან (ან ავსებს myPaysafe საფულეს) და იხდის ინტერნეტით, შემოაქვს ვაუჩერის PIN კოდი ან ავტორიზებულია საფულეში. თანხები დაუყოვნებლივ იწერება, ჩარჯბეკი, როგორც ბარათებში, არ არის; დაბრუნება კეთდება როგორც ცალკეული საკრედიტო ოპერაცია საფულეში/საბანკო დეტალებზე პროვაიდერის პროცედურებზე.

სადაც კარგად მუშაობს

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

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

სქემა/პროვაიდერი: Paysafecard (Paysafe Group- ის ნაწილი) - ვაუჩერების წარმოება, KYC/KYB წესები, ანტიფროდი, myPaysafe საფულე.
საცალო ქსელი: ვაუჩერების გაყიდვა/საფულეების შევსება, PIN ჩეკები.
PSP/შემქმნელი: მერჩანტის კავშირი, ჰოსტედის სალარო/SDK/API, მოხსენებები, გამოთვლები.
მერჩანტი: იწყებს გადახდას, იღებს სტატუსებს/ვებ-ჰუკებს, აწარმოებს აურზაურს და გადამოწმებას.
გადამხდელი: შემოაქვს PIN ან იჭერს myPaysafe- ს და ადასტურებს ჩამოწერას.

3) პროდუქტები და სკრიპტები

Vaucher on PIN: Checkaut- ზე მომხმარებელი წარმოგიდგენთ 16-ნიშანს PIN; ნებადართულია ნაწილობრივი ჩამოწერა და რამდენიმე ვაუჩერის ერთობლიობა (ლიმიტის ფარგლებში).
myPaysafe (საფულე): ბალანსის გადახდა, ხშირი შესყიდვების კომფორტი; შესაძლებელია რამდენიმე ვაუჩერის დაკავშირება და ვალუტის მართვა.
Paysafecard Mastercard (ვირტუალური/პლასტიკური): მომხმარებლებს აქვთ როგორც ცალკეული პროდუქტი (ბარათის სარკინიგზო, ბაზის PIN flow- ის გარეთ).
ბმულზე გადახდა: ინვოისი/Rau-by-Link from PSP- დან PIN შემდგომი შეყვანა მასპინძელ ოფისში.

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

4. 1 Hostede/Redirect (რეკომენდებულია)

1. Checkout - Paysafecard არჩევანი.
2. PSP/პროვაიდერის მასპინძელი გვერდის რედაქცია - PIN ან myPaysafe ლოგინის შეყვანა დადასტურებულია.
3. დაბრუნება მერკანტის ვებსაიტზე 'status' (success/failed/canceled/pending) და 'payseud Id'.
4. საბოლოო გაანგარიშება აისახება ყოველდღიურ ანგარიშებში.

4. 2 Embedded/Widget

PIN/myPaysafe შეყვანის ვიჯეტი სალაროში. მოითხოვს მკაცრი შესაბამისობა UI უსაფრთხოების მოთხოვნებთან და ჰოსტინგთან.

4. 3 სერვერი-სერვერი (მინიმალიზაცია PII)

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

5) ლიმიტები, KYC და ქცევა

• Per-transaction და ყოველდღიური/ყოველკვირეული ლიმიტები.
• ვაუჩერების ერთობლიობა: PIN რაოდენობის შეზღუდვა ერთი გადახდისთვის.
• ახალი მერკანტები/კატეგორიები: შემცირებული ბარიერები, დამატებითი შემოწმებები.
• ანტიფროდი: velocity, waucher- ის გამოშვების ქვეყანა არის მერკანტის ქვეყანა, მოწყობილობა/ქცევითი სიგნალები.

6) სტატუსები, გამოთვლები და ანაზღაურება

ონლაინ სტატუსები: 'success', 'pending', 'failed', 'canceled', 'expired'.
Settlement: საბანკო სესხი PSP/პროვაიდერის ანგარიშებზე (ჩვეულებრივ T + 1/T + 2 სამუშაო დღეებში); ეს დამოკიდებულია ხელშეკრულებაზე).
Chargeback არ არის.
Refunds: გაიცემა, როგორც ცალკეული საკრედიტო ოპერაცია (myPaysafe/bank საფულეში პროვაიდერის პროცედურის შესაბამისად); ნებადართულია partial refunds.
ვაუჩერიდან ნაწილობრივი ჩამოწერები: უფრო მაღალი მნიშვნელობის შემოწმებისას, ნებადართულია ვაუჩერების გაერთიანება; ქვემოთ ჩამოთვლისას - დარჩენილი რჩება PIN/საფულეზე (ეს დამოკიდებულია ქვეყანასა და პარამეტრებზე).

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

Merchant- ის კომისია ჩვეულებრივ დაბალია, ვიდრე CNP MDR ბარათი, მაგრამ ეს დამოკიდებულია გეოგრაფიაზე, მოცულობაზე, კატეგორიაზე (iGaming/ციფრული საქონელი და ა.შ.).
დამატებითი ხარჯები: მასპინძელი ვიჯეტი/SDK, მოხსენებები, ODR/მხარდაჭერა, დამუშავება 'pending/expired', ჩანაწერები.

8) ფულადი სახსრების ნიმუშები

გაყიდვების ქსელის ხილვადობა: მოკლე რჩევა „სად შეიძინოთ ვაუჩერი“ ზრდის ახალი მომხმარებლების კონვერტაციას.
PIN კომბინაცია: მიაწოდეთ ინტერფეისი რამდენიმე ვაუჩერის დამატებისთვის და ნათლად აჩვენეთ დარჩენილი.
მკაფიო შეცდომები: „არასწორი/გამოყენებული PIN“, „ზღვარი აღემატება“, „რეგიონი არ არის მხარდაჭერილი“.
ქვითარი: თანხა, დრო, 'payshID', მეთოდი (PIN/myPaysafe), დაბრუნებისას - 'refundID'.
ლოკალიზაცია: ვალუტა, ენა, დროის/თარიღების ფორმატი, ადგილობრივი იურიდიული ტექსტები.

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

SCA/ავთენტიფიკაცია პროვაიდერის მხარეს, მოწყობილობებისა და ქცევითი სახსრების მიმართ.
PII მინიმიზაცია: ნუ დაამუშავებთ PIN მერჩანტის მხარეს; გამოიყენეთ ფორმის მასპინძელი/ვიჯეტი.
ვებ-ჰუკები: HMAC/nonce, დაცვა replay- სგან, მოვლენების დედაპლიკაცია.
GDPR/KYC/AML: ასაკის, ქვეყნის მიხედვით ლიმიტების აღრიცხვა, სანქციების შეზღუდვები და წესები „წინასწარ გადახდილი სახსრებისთვის“.

10) Conconciliation

გაითვალისწინეთ: 'paystamps Id', 'orderId', მეთოდი (PIN/myPaysafe), ვალუტა, თანხა, სტატუსი, timestamps, ფინანსური რეფერენდუმი/UTR PSP ანგარიშებიდან.
ყოველდღიურად: ფულადი ღონისძიებების auto-recon ფინანსური რეესტრებით (ჩარიცხვა/გადახდა/კორექტირება).
Alerty on rassinhrons: „წარმატება რეესტრის გარეშე“, „ორმაგი ჩამოწერა“, „შემცირებული პენდინგი“.

11) მერჩანტის ინტეგრაცია

პარამეტრები

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

• API: `createPayment`, `capture/confirm` (если применимо), `refund`, `queryStatus`, `webhook`, `reconcile`.
• Idempotention ('orderId' + გასაღები), ექსპონენციალური retrais, DLQ არასტაბილური პასუხებისთვის.
• კატალოგები: ქვეყნები/ვალუტები, ლიმიტები/KUS დონე, შეცდომების კოდი, SLA მეტრიკა.

12) ხელმოწერებისა და ხელახალი ჩამოწერის მახასიათებლები

• myPaysafe, როგორც სახსრების წყარო (სადაც ნებადართულია),
• ან პირველი გადახდის სქემა - მანდატი/ალტერნატიული A2A (SEPA/Open Banking).
• ყოველთვის აჩვენეთ მომხმარებელს მანდატის მართვის ეკრანი (ლიმიტი per debit, სიხშირე, შეტყობინებები).

13) ანტიფროდი და რისკის პოლიტიკა

შემოწმებები: PIN vs IP/Devais გამოშვების რეგიონი, ქცევითი პროფილი, წარუმატებელი მცდელობების სიხშირე, PIN განმეორების საშუალებით ანგარიშების კავშირი.
შემსუბუქება: სესიის/დღის განმავლობაში PIN რაოდენობის შეზღუდვები, წვეთი/ნაბიჯი, გამაგრილებელი პერიოდები, განმარტებით „რბილი“ უარი.

14) მაღალი სიმაღლის ვერტიკალური (iGaming- ის ჩათვლით)

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

15) არქიტექტურა „Paysafecard Gateway“

API ფენა (REST/GraphQL) ფულადი სახსრები/ბილინგი.
მოვლენების რიგები: სტატუსები - ბილინგი/CRM/ანალიტიკა/მხარდაჭერა.
უსაფრთხოება: საიდუმლოების Vault, IP-allowlist, redirect-URI მკაცრი შესაბამისობა, antireplay ნიშნები.
Observability: კონვერტაცია (PIN vs myPaysafe), 'pending-success/expired', საშუალო ლატენტობა, ნაწილობრივი/კომბინირებული ჩამოწერის წილი, სეგმენტების ანაზღაურება.

16) Check Life Prode

1. დააკავშირეთ არხი PSP- ში და ჩართეთ Hosted PIN/myPaysafe.
2. გააცნობიერეთ 'CreatePayment' + ვებ ჰუკები (HMAC) + იდემპოტენტურობა და გამეორება.
3. ჩართეთ partial refunds და ODR/sapport პროცედურები.
4. პარამეტრი daily auto-recon + პერიოდული full-recon; შეინახეთ ფინის რეფერენდუმი.
5. დაამატეთ UX PIN კომბინაციისთვის და გასაგები შეტყობინებები შეცდომების/ლიმიტების შესახებ.
6. SLA დაშბორდები და ალერტები კონვერტში/შეჩერებული 'pending'.
7. გაიარეთ e2e ტესტები სამიზნე ქვეყნებში/ვალუტაში და უკიდურეს შემთხვევებში (რამდენიმე PIN, ნაწილობრივი დაბრუნება, ვადაგადაცილებული PIN).

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

სტატუსები: 'success/pending/failed/canceled/expired'.
Settlement: უფრო ხშირად T + 1/T + 2 რეესტრებში.
Chargeback: არა; refund არის ცალკეული საკრედიტო ოპერაცია.
PIN კომბინაცია: ნებადართულია ლიმიტების ფარგლებში.
რეკურენტი: myPaysafe ან ალტერნატიული მანდატის საშუალებით (პირველი გადახდის შემდეგ).

რეზიუმე

გამოიყენეთ Hosted PIN/myPaysafe სწრაფი ინტეგრაციისა და უსაფრთხოებისთვის.
ააშენეთ პროცესი webhooks + recon- ის გარშემო, მხარი დაუჭირეთ პარტიულ რეფუნდებს და ვაუჩერების ერთობლიობას.
ნუ „მკაცრად“ დაშიფვრავთ თანხებს: ჩაატარეთ შეზღუდვების კონფიგურაცია/ICC ქვეყნებში და რეგულარულად განაახლეთ.
ხელმოწერებისთვის - პირველი ვაუჩერი - მანდატი/MyPaysafe, გამჭვირვალე კონტროლითა და შეტყობინებებით.