Multibanco პორტუგალია: ვაუჩერები და რეფები

1) მულტიბანკოს კონტექსტი და პოზიციონირება

• MB References (Pagamento de Serviéos/Compras): Entidade + Referóncia + Valor ტიპის გადახდის დეტალები ATM ან homebanking- ში ინვოისების გადახდისთვის.
• MB Voucher/MB Cash at ATM: „ვაუჩერი“ სცენარი - მყიდველი იღებს კოდს/ინსტრუქციას და იხდის ATM ან ინტერნეტ ბანკში; მერჩანტი იღებს ონლაინ დადასტურებას PSP- დან და შემდგომ საბანკო სესხიდან.

მახასიათებლები: ძალიან დაბალი ფროიდი, ფინალურობა, როგორც საბანკო თარგმნა (carjbek არ არის), მოხერხებულობა მომხმარებლებისთვის, რომლებიც იყენებენ ATM/homebanking- ის გადახდას.

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

Entidade (Entity/Service code) - მიმღების კოდი SIBS სისტემაში (ჩვეულებრივ 5 ციფრი).
Referència (ანგარიში) - ანგარიშის/შეკვეთის 9-მნიშვნელოვანი უნიკალური იდენტიფიკატორი.
ვალორი (Amount) - გადახდის თანხა (ფიქსირებული) ან „ღია“ (თუ PSP/stunt ასე არის მორგებული).

3) მონაწილეები

SIBS/Multibanco (სქემა/switch) - MB გადახდის მარშრუტიზაცია და გაწმენდა.
გადამხდელის ბანკი - უზრუნველყოფს ATM/homebanking- ს, იყენებს შეზღუდვებს/ანტიფროდს.
PSP/Acquirer - აძლევს References/ვაუჩერებს API/პანელის მეშვეობით, webhooks ჩაფხუტი და რეესტრები, ატარებს გამოთვლებს.
Merchant - წარმოქმნის ანგარიშს (Entity/Reference/Amount), იღებს სტატუსებს/ჩარიცხვებს, აკეთებს ზარალს.

4) ნაკადები და არხები

4. 1 MB References (ინვოისები ATM/homebanking საშუალებით)

1. Merchant/PSP ქმნის Entidade + Referóncia + Valor + Expiry და აჩვენებს მათ checaut- ზე (ან/ან აგზავნის email/SMS).
2. კლიენტი იხდის ATM- ს ან მის ინტერნეტ ბანკში და ადასტურებს ოპერაციას.
3. PSP merchant- ს გადასცემს ონლაინ სტატუსს (paid/pending/expired და ა.შ.), შემდეგ კი მოძრაობს fin reestres- ში (settlement).

• დინამიური Reference per-order (რეკომენდებულია).
• სტატიკური რეფერენცია (დონატებისთვის/საფულეებისთვის) - უფრო ხშირად იწვევს რთულ შეკუმშვას, ფრთხილად გამოიყენეთ.

4. 2 MB Voucher (cash at ATM / pay-code)

PSP- ის საშუალებით ციმციმი წარმოქმნის „კვაზი-ვაჩერს “/გადახდის კოდს (სინამდვილეში, მოკლევადიანი რეფერაცია).
კლიენტი მიდის ATM ან homebanking და იხდის PSP კოდით ონლაინ წარმატებას.
ხშირად გამოიყენება მაღალი რანგის/ფულადი სცენარებში და მომხმარებლებისთვის ბარათების გარეშე.

4. 3 გადახდა MB WAY MB ინვოისისთვის

Flow ხელმისაწვდომია ზოგიერთ PSP- ში: კლიენტი იხდის რეგისტრირებულ MB-Reference- ს MB WAY (საფულე) საშუალებით. ეს აჩქარებს დადასტურებას და ზრდის კონვერტაციას მობილური ტელეფონზე.

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

• `created` → `pending` → `paid` / `expired` / `canceled` / `failed`.

Settlement: საბანკო სესხი T + 0/T + 1 (დამოკიდებულია საბანკო ფანჯრებზე/PSP). ბუღალტრული აღრიცხვის მყისიერი ონლაინ დადასტურებით, დაეყრდნეთ ყოველდღიურ რეესტრებს.

ნაწილობრივი გადახდები: აკრძალულია ნაგულისხმევი (ფიქსირებული ვალორისთვის). „ღია თანხა“ საშუალებას იძლევა ნაწილობრივი, მაგრამ ეს ართულებს შერიგებას - ჩართეთ მხოლოდ შეგნებულად.

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

• Per-transaction / per-day/24h; ზოგჯერ შაბათ/monthly.
• უფრო მკაცრი ბარიერები ახალი მიმღების/მერჩანტებისთვის.
• არხის განსხვავებები: ATM vs homebanking; ზოგიერთ ბანკს აქვს სხვადასხვა ფანჯარა/ბარიერი.
• Velocity/devais/geo სიგნალები ბანკის მხარეს/PSP.

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

მიღების ღირებულება ტიპიური MDR ბარათის ქვემოთ; პირობები - თქვენი PSP.
გაითვალისწინეთ ინვოის განაწილების ხარჯები, დამუშავება 'expired/pending', საფოსტო და ჩანაწერები.

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

Chargeback (როგორც რუქებში) არ არის.
დაბრუნება ხდება როგორც ახალი საკრედიტო ოპერაცია (ჩვეულებრივ, SEPA Credit Transfer) IBAN კლიენტისთვის ან MB WAY საფულის საშუალებით (თუ ეს შეთანხმებულია).
მხარი დაუჭირეთ პარტიული რეფუნდებს ბეკის ოფისში; შეინახეთ 'refund' original reference '.

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

გადახდის დადასტურება ხდება გადამხდელის ბანკში (ATM/online-banking) - დაბალი ფროიდი.
GDPR/PII მინიმალიზაცია: შეინახეთ მხოლოდ საჭირო ატრიბუტები (Entity/Ref/Amount, კლიენტის ნიღბები).
ვებ-ჰუკები - HMAC/nonce, დაცვა replay- სგან, მოვლენების დედაპლატისგან, აუდიტის ჟურნალი.
გაითვალისწინეთ Banco de Portugal- ის მოთხოვნები და SIBS/PSP სახელშეკრულებო პირობები.

10) შერწყმა და მოხსენება (ჩანაწერები)

• 'entity' (Entidade), 'reference' (9-digit), 'amount' (ვალორი), 'orderId', 'status', 'paceAt', 'channel' (ATM/homebanking/MB ay WAAAy), ',', 'რეფერენდუმი/UTR რეესტრებიდან.
• ყოველდღიურად: auto-recon PSP/SIBS რეესტრებზე (ჩარიცხვა/ანაზღაურება/კორექტირება) + პერიოდული full-recon.
• Alerty on rassinhrons: „არსებობს ონლაინ წარმატება, არ არსებობს ჩანაწერი რეესტრში“, „ერთი Ref- ის ორმაგი გადახდა“, „არასწორი თანხა“.

11) UX ნიმუშები (რაც მომხმარებელს აჩვენებს)

დიდი ველები: Entidade/Referóncia/Valor + deadline (expiry) და ტაიმერი.
კოპირების ღილაკები თითოეული ველისთვის; QR დაფარული დეტალებით (თუ მხარს უჭერს თქვენს PSP).
ინსტრუქციები „როგორ გადაიხადოთ ATM/ონლაინ ბანკში“ 3-4 ნაბიჯით.
შეკვეთის სტატუსი „ელოდება გადახდას“ და ფონის განახლებას. „expired“ - „ახალი რეფერენდუმის შექმნა“ ერთ დაწკაპუნებაში.
დადასტურების შემდეგ: ჩეკი 'entity', 'reference', 'At', 'UTR' და sapport კონტაქტები.

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

პარამეტრები

1. Hosted/Embedded in PSP - სწრაფი დასაწყისი, ავტომობილების წარმოება References, webhooks და გადმოტვირთვა.
2. Server to-Server - საკუთარი შემოწმება/ინვოისი, დინამიური per-order რეფერენდუმები, კასტომიური მოქმედების ვადა.
3. Pay-by-Link - ბმულების გაგზავნა email/SMS/მესინჯერებისთვის.

• API: `createReference` (entity/ref/amount/expiry), `cancelReference`, `refund`, `webhook`, `reconcile`.
• Idempotence ('orderId' მიხედვით), ექსპონენციალური retrais სტატუსებისთვის, შემომავალი ვებ-ჰუკების dedupe.
• კატალოგები: ბანკები/ლიმიტები, შეცდომების კოდები, SLA მეტრიკა (ATM vs homebanking), გაწმენდის რუკა.

13) MB WAY და გამოწერა

ძირითადი MB References/ვაუჩერები - one-off, რომელიც დადასტურებულია ბანკში.
განმეორებითი ჩამოწერისთვის გამოიყენეთ კავშირი: პირველი გადახდა e-mandate/SEPA Direct Debit ან MB WAY მანდატები (თუ შეგიძლიათ PSP), ლიმიტებით და შეტყობინებებით.

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

Multibanco ხშირად გამოიყენება, მაგრამ პირობები/ლიმიტები დამოკიდებულია PSP/ბანკებზე და ადგილობრივ სამართალზე.
დაელოდეთ KYC- ის გაფართოებულ ბარიერებს და შესაძლო ჰოლდებს.
დაგეგმეთ ალტერნატიული რელსები (ბარათები, MB WAY, SEPA, სხვა PIS) და ჭკვიანი როუტინგი.

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

API ფენა (REST/GraphQL) ფულადი სახსრების/ინვოისის მომსახურებისთვის.
მოვლენების ხაზები: სტატუს-Ivents-billing/CRM/ანალიტიკა.
უსაფრთხოება: საიდუმლოების Vault, IP-allowlist PSP, მკაცრი callback-URL, ანტი-replay.
Observability: კონვერტაცია 'created-paid', წილი 'expired', გადახდის საშუალო დრო, ATM vs homebanking, SLA ვებ-ჰუკებში/რეესტრებში.

16) Check Life Prode

1. დააკავშირეთ PSP MB References/Voucher; კოორდინაცია გაუწიეთ settlement და რეესტრების ფორმატს.
2. გააცნობიერეთ 'createlEference' (დინამიური, გამოცდილებით) და ინსტრუქციის გვერდები (ATM/homebanking).
3. დააკავშირეთ webhooks, idempotence, retrai, dedup.
4. პარამეტრები daily auto-recon + full-recon, UTR და აუდიტის შენახვა.
5. ჩართეთ partial/full refunds (SEPA/MB WAY), ODR რეგულაციები.
6. ააშენეთ დაშბორდები SLA და ალერტები 'expired', რასინქრონები, თანხების შეცდომები.
7. გადაიტანეთ e2e ტესტები ATM/homebanking ტოპ ბანკებში, ვებ - ჰუკების ტაიმინგი და ექსტრემალური შემთხვევები (ვადაგასული ref, ორმაგი გადახდა).

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

Статусы: `created/pending/paid/expired/canceled/failed`.
Settlement: უფრო ხშირად T + 0/T + 1.
ნაწილობრივი გადახდა: ნაგულისხმევი არ არის (ფიქსირებული თანხისთვის).
დაბრუნება: SEPA SCT/MB WAY საფულე, როგორც ახალი საკრედიტო ოპერაცია.
რეკურენტი: ელექტრონული მანდატის/SEPA DD- ის საშუალებით (პირველი გადახდა - მანდატი).

რეზიუმე

ინვოისებისთვის/გადავადებული გადახდისთვის გამოიყენეთ MB References დინამიური ref და expiry; ფულადი სახსრების/ATM აუდიტორიისთვის - MB Voucher.
ააშენეთ პროცესი webhooks + SIBS რეესტრების გარშემო, მკაფიო შერიგებისა და კონტროლირებადი დაბრუნების (SCT/MB WAY) გარშემო.
შეინარჩუნეთ ლიმიტების კონფისკაცია ბანკების/არხების საშუალებით, დააკვირდით 'expired' და დადასტურების ტაიმინგს.
ხელმოწერებისთვის - პირველი MB მანდატი (SEPA/MB WAY) გამჭვირვალე კონტროლითა და შეტყობინებებით.