TWINT შვეიცარია: QR და app

1) TWINT- ის კონტექსტი და პოზიციონირება

TWINT არის შვეიცარიული მობილური A2A გადახდებისა და საფულეების სქემა, რომელიც ინტეგრირებულია ქვეყნის ბანკებთან. მომხმარებელი იხდის TWINT/ბანკის აპლიკაციიდან: ინტერნეტით - in-app/App2App ან Deep Link, ოფლაინში - QR- ის საშუალებით (სტანდარტული „TWINT QR“). დადასტურება ხორციელდება განაცხადში (SCA: PIN/ბიომეტრია), თანხები იწერება დაკავშირებული ანგარიშიდან/ბარათებიდან და გადაეცემა მერჩანტს საბანკო სესხით.

• ერთი ბრენდი/QR ონლაინ და POS, მაღალი მომხმარებლის გაშუქება.
• მყისიერი ონლაინ დადასტურება UX- სთვის და სწრაფი თვითმფრინავი (როგორც საბანკო ფანჯრების ნაწილი).
• P2P ტელეფონის ნომრით/ეკოსისტემის შიგნით კონტაქტით.
• დაბალი frodom SCA და binding მოწყობილობის გამო.

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

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

3) არხები და მომხმარებლის სცენარები

3. 1 E-commerce: in-app / Deep Link / App2App

ჩეკზე, ციმციმი ქმნის გადახდის intent და აძლევს Deep Link/ღილაკს „გადახდა TWINT“.
TWINT პროგრამა იხსნება (App2App), მომხმარებელი ადასტურებს სტატუსის მქონე სალაროში დაბრუნებას.
Desctop- ისთვის ნაჩვენებია დინამიური QR per-order; კლიენტი სკანირებს განაცხადში და ადასტურებს.

3. 2 POS/ოფლაინი: TWINT QR

დინამიური QR სალაროს/ტერმინალის ეკრანზე: თანხა, orderid, მეტამონაცემები.
მომხმარებელი სკანირებას უკეთებს, განაცხადში ადასტურებს, რომ stunger იღებს ონლაინ სტატუსს.
სტატიკური QR (თანხა ხელით შემოღებულია) გამოიყენება დონატებისთვის/მცირე საცალო ვაჭრობისთვის, მაგრამ უარესია შერიგებისთვის.

3. 3 P2P „ტელეფონით“

ინდივიდებს შორის გადარიცხვები ტელეფონის ნომრით/კონტაქტით push დადასტურებით და მიმღებისთვის მყისიერი სესხით.

3. 4 Request-to-Pay / Pay-by-Link

მერჩანტი იწყებს გადახდის მოთხოვნას (თანხა/დანიშვნა/ვადა), კლიენტი ადასტურებს განაცხადში, რომ გადახდა ხდება ჩვეულებრივი A2A flow- ით.

4) სტატუსები და ტაიმინგი

ტიპიური სტატუსები: 'initiated', 'pending' "success '/' failed '/' canceled '/' expired '.
QR/desctop- ისთვის გაითვალისწინეთ ტაიმაუტის დადასტურება (აჩვენეთ ტაიმერი).
Settlement: საბანკო სესხი T + 0/T + 1 დამოკიდებულია გაანგარიშების ფანჯარაზე/PSP; მოხსენებისთვის, იგი კვლავ სავალდებულოა დღის ჩანაწერისთვის.

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

• Per transaction, per-day/24h, ზოგჯერ weekly/monthly.
• ახალი მიმღები/ქურთუკი - შემცირებული ბარიერები ან/და გამძლეობა.
• არხის ლიმიტები: ელექტრონული კომერცია (Deep Link/QR), POS, P2P, Request-to-Pay.
• Velocity/devais/geo წესებს იყენებენ ბანკები და სქემა.

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

TWINT- ისთვის, ჩვეულებრივ, იაფია, ვიდრე ტიპიური MDR ბარათები; პირობები განსხვავდება PSP- ში (ფიქსი/დაბალი%).
განათავსეთ ინტეგრაციის ხარჯები/SDK, დამუშავება 'pending/expired', მხარდაჭერა/ODR და კრიკეტი.

7) ამაღლება და დებატები

Chargeback (როგორც რუქებში) არ არის. დაბრუნება - ახალი საკრედიტო ოპერაცია გადამხდელისგან გადამხდელამდე; მხარს უჭერს partial refunds.
დაბრუნების ვადები - საბანკო (ჩვეულებრივ T + 0/T + 1).
დებატები/საჩივრები - PSP/ბანკის პროცედურების მიხედვით; შეინახეთ შეკვეთის ლოგოები, მომსახურების/მიწოდების მიწოდების დადასტურება, refund - რიგის კავშირი.

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

SCA განაცხადში TWINT/Bank (PIN/ბიომეტრია), მოწყობილობის მიღება.
ანტიფროდი ბანკში/PSP: velocity, ახალი მიმღები, რისკის ესკიზი.
PII მინიმიზაცია და დაშიფვრა, HMAC/nonce ვებ-ჰუკებზე, დაცვა რეპლეისგან, აუდიტის ჟურნალი.
გადახდის სერვისების ადგილობრივი მოთხოვნების შესაბამისობა და მონაცემთა დაცვის GDPR შედარებითი სტანდარტები.

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

პარამეტრები

1. Hosted/Embedded PSP არის სწრაფი დასაწყისი, in-app/QR ყუთიდან, სტატუსებიდან და შეცდომებიდან.
2. სერვერი to-Server + Deep Link/QR არის საკუთარი UX, დინამიური QR per-order, დახვეწილი შეცდომების დამუშავება.
3. Pay-by-Link/Request-to-Pay - ანგარიშის გაგზავნა (email/SMS/მესინჯერი).

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

10) შერჩევა და მოხსენება

განათავსეთ: 'payshead Id/transacotion Id' პროვაიდერი, 'orderId', არხი (App2App/QR/Link), გადამხდელი ბანკი, სტატუსი, თანხა/ვალუტა, Timestamp, UTR.
PSP/Bank- დან: ჩარიცხვის/დაბრუნების/კორექტირების რეესტრები, სტატუსის მოგვიანებით განახლება.
Alerta- ს პარამეტრები რასინქრონების მიხედვით და „შეჩერებული“ 'pending'.

11) UX პრაქტიკა

მობილური პირველი: მობილური - app/App2App; დესკტოპზე - დიდი დინამიური QR ტაიმერით.
ჩანაწერი: „timeout/expired“ - უსაფრთხო გამეორება და ალტერნატივა (ბარათი/SEPA/სხვა A2A).
ქვითარი: თანხა, დრო, 'transaction Id', არხი, UTR, საფორტეპიანო კონტაქტები.
რისკის/ლიმიტების განათება: აჩვენეთ მომხმარებელს, ვინც ბარიერი დააწესა - ბანკი ან არხი.

12) რეკურენტი და მანდატები

ძირითადი TWINT - off SCA- ით. ხელმოწერებისთვის გამოიყენება კავშირი: TWINT-e-mandate/SEPA DD/Open-Banking პირველი გადახდა მომავალი გაუქმებისთვის (ლიმიტი/სიხშირე/შეტყობინებები).
მიეცით მომხმარებელს მანდატების მართვის ეკრანი (pause/cancel/განახლება) და წინასწარი შენიშვნა ჩამოწერამდე.

13) მაღალი რისკის ვერტიკალური (მათ შორის iGaming)

არხებისა და ლიმიტების ხელმისაწვდომობა დამოკიდებულია ბანკის/PSP და ადგილობრივი სამართლის პოლიტიკაზე.
დაელოდეთ KYC- ს მიერ გაძლიერებულ დაბალ ბარიერებს, შესაძლო ჰოლდებს.
დაგეგმეთ ალტერნატიული რელსები (ბარათები, SEPA, სხვა PIS) და smart-routing რისკის/არხის/ბანკის საშუალებით.

14) არქიტექტურა „TWINT Gateway“

API ფენა (REST/GraphQL) სალაროსა და ბეკოფისისთვის.
მოვლენების ხაზები: სტატუს-Ivents-billing/CRM/ანალიტიკა.
უსაფრთხოება: საიდუმლოების vault, IP-allowlist PSP, redirect-URI მკაცრი შესაბამისობა, antireplay ნიშნები.
Observability: კონვერტაცია არხებით (App2App/QR/Link), წილი 'pending-expired', დრო settlement/დაბრუნებამდე.

15) Check Life Prode

1. დააკავშირეთ TWINT PSP/Bank- ში; არხების არჩევა (App2App/QR/Link).
2. გააცნობიერეთ 'CreatePayment '/' requestToPay', დინამიური QR, შეცდომების/ლიმიტების ეკრანები.
3. დააკავშირეთ webhooks, idempotence, retrai და მოვლენების დედობა.
4. ჩანაწერების პარამეტრები (daily + full), UTR/ფინის რეფერენდუმის შენახვა.
5. მხარი დაუჭირეთ partial/full refunds და ODR პროცედურებს.
6. SLA დაშბორდები და ალერტები კონვერტაციის/ლატენტობის/შეჩერებული სტატუსის მიხედვით.
7. ჩაატარეთ e2e ტესტები ძირითადი ბანკებით/მოწყობილობებით და POS (თუ ეს ეხება).

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

Per-txn/24h/7d: შენახვა კონფისკაციაში და შემოწმება დაწყებამდე.
ახალი მიმღები/მერჩანტები: შემცირებული ბარიერები/გამძლეობა.
არხები: ინდივიდუალური ლიმიტები ელექტრონული კომერციის (App2App/QR), POS, P2P, Request-to-Pay.
Velocity/რისკი: ბანკის ანტიფროგმა შეიძლება ნაზად უარყოს/შეანელოს ოპერაციები.

რეზიუმე

ინტერნეტით - App/App2App + დინამიური QR, საცალო ვაჭრობისთვის - TWINT QR, გადარიცხვებისთვის - P2P ტელეფონით.
გაიზიარეთ ონლაინ დადასტურება და საბოლოო სესხი; აშენეთ webhooks + recon და partial refunds გარშემო.
არ დააფიქსიროთ თანხები: აიღეთ ლიმიტების კონფისკაცია ბანკების/არხების საშუალებით და რეგულარულად განაახლეთ.
ხელმოწერებისთვის - პირველი TWINT თაიგული - მანდატი გამჭვირვალე მენეჯმენტით და შეტყობინებებით.