წესი same-method და წყაროზე დაბრუნება

1) არსი და რატომ არის ეს აუცილებელი?

• AML/ATF: არ გადააქციოთ დაბრუნება „ანონიმურ payout გვირაბში“ სხვა დეტალებად.
• Frode/ODR შემცირება: ნაკლები დავა „ფული არასწორედ წავიდა“.
• ოპერაცია: გამარტივებული კრიკეტი, ნაკლები ხელის შემთხვევები.
• ბარათების წესები: ქსელის მოთხოვნების შესაბამისობა „საკრედიტო დაკრედიტების დასაშვებად“.

2) ბარათები (Visa/Mastercard/...): როგორ მუშაობს იგი

Void/Authorization Reversal (კლირინგის დაწყებამდე): ავტორიზაციის დაბრუნება - ფული „გაყინულია“ იმავე ბარათზე.
Refund (Credit/Presentment): კლირინგის შემდეგ - სესხი იგივე PAN/DPAN.
Apple/Google Pay: დაბრუნება DPAN/ქსელის ნიშნით - ემიტენტი ბრუნავს მიმდინარე ბარათზე (ხელახლა გამოსვლის ჩათვლით).
Push-to-Card OCT - არ არის ტოლი რეფანდის შესახებ: ეს არის ბარათის გადახდა; გამოიყენეთ მხოლოდ ჩაწერილი გამონაკლისი და დაფა. KYC.

• ბარათის დახურვა/ხელახლა გამოშვება - ემიტენტი, როგორც წესი, „გადამისამართებს“ სესხს მემკვიდრეობის ბარათზე/ანგარიშზე. დაბრუნება ისევ მუზარადს ჰგავს.
• თავდაპირველი გადახდის დაბრუნება აკრძალულია; გააკეთეთ ნაწილობრივი refund, დანარჩენი - ნებადართული payout სარკინიგზო საშუალებით KYC/SoF- ის შემდეგ.
• Split-tender (გადახდა 2 წყაროდან): გადახდა იგივე პროპორციით თითოეული წყაროსთვის.

3) საბანკო A2A (SEPA/ACH/FPS/RTP/PIX)

იდეალი: სესხის გადაცემა იმავე IBAN/ანგარიშზე, საიდანაც მოვიდა შევსება (ან UPI/PIX გამგზავნის იდენტიფიკატორზე).
ACH (აშშ): „refund to წყარო“ ჩვეულებრივ იყიდება, როგორც სესხი იმავე routing + account- ისთვის; დაბრუნება (R- კოდები) არ არის რეფენდი, არამედ სარკინიგზო უარი/დაბრუნება.
RTP/FPS/PIX: სწრაფი და საბოლოო; თუ ამ რელსებზე საწყისი გადახდა - დაბრუნება ხშირად ხდება როგორც ახალი სესხი იმავე მიმღებისთვის/ალიასისთვის (ეს არის ნორმალური same-method- ის განხორციელება).

• ანგარიში დახურულია/დეტალები არასწორია - ალტერნატიული სარკინიგზო გზა ნებადართულია ბენეფიციარის (მიკრო-დეპოზიტის/პასაჟის) და ეტაპის KYC დადასტურების შემდეგ.
• Cross-border SWIFT: თუ საწყისი გადახდა ადგილობრივი იყო, ხოლო დაბრუნება საჭიროა x-border - დააფიქსირეთ დამატებითი FX/fee disclosure და თანხმობა.

4) e-wallets და APM (Skrill/Neteller/Payz/PayPal და ადგილობრივი)

წესი: იგივე საფულის/ანგარიშის დაბრუნება, საიდანაც დეპოზიტი მოვიდა.
საფულის შიგნით ბარათიდან ყველაზე მაღალი: რეფენდი ბრუნდება საფულეში და არა პირდაპირ მომხმარებლის ბარათზე (პროვაიდერის პოლიტიკა).
ვაუჩერები/eCash (Paysafecard, Neosurf, Multibanco-ref): უფრო ხშირად ისინი არ არიან შეუქცევადი წყაროსთვის - სესხი მიიღება საფულეზე/ბალანსზე (ან ალტერნატიული payout KYC- ზე).

• წვდომა დაბლოკილია/დაკარგულია - ალტერნატიული სარკინიგზო მაგისტრალი EDD/SoF- ის შემდეგ და საკუთრების დადასტურება.
• პარტნიორობის შეზღუდვები (AUP) - დაბრუნება შესაძლებელია მხოლოდ მაღაზიის კრედიტის/შიდა ბალანსის სახით.

5) ვაუჩერები/ნაღდი ფული/კვაზი ქეში

1. საქონლის/სესხის გაცემამდე გაუქმება დაახლოებით, არაფერი გადარიცხულია.

2. ჩარიცხვის შემდეგ - შიდა ბალანსში/საფულეში დაბრუნება, რასაც მოჰყვა მხოლოდ რეგისტრირებული საბანკო ანგარიშის გამოტანა KYC/SoF- ის შემდეგ (არა „ნაღდი ფული“).

გამჭვირვალედ მიუთითეთ ToS: ვაუჩერის შევსება არ ბრუნდება ვაუჩერზე.

6) ნაწილობრივი ზარები, ულტრამემარჯვენე და მრავალ წყარო

Partial refund: საწყის წყაროში საწყისი გადახდის ოდენობამდე. რამდენიმე ნაწილობრივი დასაშვებია.
დაბრუნების თანხა> შემოღებული წყაროსთვის - ნარჩენები ნებადართული payout სარკინიგზო საშუალებით (KYC/SoF/limites).
რამდენიმე წყარო (მაგალითად, 70% რუქა + 30% საფულე): რეფანდები პროპორციულია იმავე წყაროების უკან დაბრუნებით.

7) დროებითი ფანჯრები და პრიორიტეტები

პრიორიტეტი 1: 'void/authorization reversal' (თუ ეს შესაძლებელია) არის ყველაზე „სუფთა“ დაბრუნება.
პრიორიტეტი 2: 'refund to წყარო' თავდაპირველ სარკინიგზო მაგისტრალზე.
პრიორიტეტი 3: ალტერნატიული payout (მხოლოდ ჩაწერილი გამონაკლისის მიხედვით + step-up და აუდიტი).

8) გადაწყვეტილებების ძრავა: როგორ უნდა დაპროექტდეს

Входные данные: `paymentId`, `sourceType` (card/A2A/wallet/voucher), `sourceRef` (PAN token, IBAN, walletId), `amount`, `fx`, `status`, `settlementState`, `kycLevel`, `riskScore`, `beneficiaryId`.

1. Если `canVoid(paymentId)` → Void.

2. წინააღმდეგ შემთხვევაში, თუ 'isRefundable ToSource (paysed Id)' Refund (sourceRef).

3. თუ 'SourceRef invalid/cllosed' Step-Up (KYC/SoF) გთავაზობთ payout სარკინიგზო ბილიკს allow სიიდან (საბანკო/Push-to-Card/e-wallet) მიზეზების ლოგიკას.

4. თუ voucher/eCash იღებს სესხს შიდა. ბალანსი; პირდაპირი შებრუნება შეუძლებელია.

5. Split-tender - რეფენდი თითოეული 'sourceRef- ისთვის "მათი წილით.

6. Hard-deny სანქციების/REP/ასაკობრივი/გეო აკრძალვების დროს.

არა უნებლიე: idempotention ('refundKey'), ვებ-ჰუკების დედაპლატი, გაფანტული ლოგიკა (რატომ არის შერჩეული მეთოდი), წესების ვერსია.

9) სტატუსები, კრიპტები და არტეფაქტები

დაბრუნების სტატუსები: 'requested' pending refunded | failed | canceled '.
Артефакты: `refundId`, `originalPaymentId`, `sourceType/ref`, `amount/currency`, `fxRate`, `UTR/ARN/Trace`, `reasonCode`, `actor`.
ჩანაწერები: daily auto-recon PSP/Bank + full-recon რეესტრებზე; ალერტები: „წარმატება რეესტრის გარეშე“, „ორმაგი რეფუნდი“, „დაბრუნება სხვა წყაროზე“.

10) UX და კომუნიკაციები

დაბრუნების ეკრანზე აჩვენეთ ადრესატი: „დაბრუნება ბარათზე • • 3456/საფულე @ user/ანგარიში DE“....
გამონაკლისის შემთხვევაში, ჩვენ ავუხსნით: "წყარო არ არის ხელმისაწვდომი. თქვენი უსაფრთხოებისთვის, ჩვენ შემოგთავაზებთ რეგისტრირებულ საბანკო ანგარიშზე დაბრუნებას მონაცემების დადასტურების შემდეგ („N წუთი/საათი)“.
ჩეკები/წერილები: თანხა, თარიღი, მეთოდი, 'refundId', UTR/ARN, ETA (ბარათები - X დღემდე, A2A - T + 0/1, საფულეები - მყისიერად/T + 1).
FAQ: ვაუჩერები საპირისპიროა; Apple/Google Pay ავტომატურად ბრუნდება დაკავშირებულ ბარათზე.

11) გამონაკლისების მატრიცა (სიგნალები და ნაბიჯები)

12) FX და ვალუტა

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

13) მახასიათებლები iGaming- ისთვის

ბონუსების/ფრისპინების დაბრუნება: თამაშის წესები> დაბრუნების პოლიტიკა; ფული მხოლოდ თანხების თვალსაზრისით.
Self-exclusion/RG: ანგარიშის დაბლოკვისას - დარჩენილი წყაროს დაბრუნება; ალტერნატიული გადახდები აკრძალულია შემოწმების დასრულებამდე.
კვაზი ქეში: მკაცრი აკრძალვა „გადასხმის“ ბარათიდან/ვაუჩერიდან ახალ დეტალებზე, რეფანდის ქვეშ.

14) KPI და კონტროლი

Refund success rate (ონლაინ რეგისტრაცია რეესტრში).
Median/P95 time-to-refund მეთოდების მიხედვით.
Alternate-payout (გამონაკლისების წილი) - შენარჩუნება <X%.
ODR დაბრუნების შემდეგ (განმეორებითი დავები).
შერიგების შეცდომები: „ორმაგი refund“, „არასწორი წყარო“.
მხარდაჭერა load/1k შეკვეთების დასაბრუნებლად.

15) განხორციელების სია

1. წყაროების კატალოგი (card/A2A/wallet/voucher) და მათი ვარგისიანობის სტატუსი RTS- სთვის.
2. policy ძრავა: წესები void - refund - alt-payout, explain-logs, ვერსია.
3. PSP/ბანკების ინტეგრაცია: 'void/refund', ვებ ჰუკები (ხელმოწერა/NMAS), იდემპოტენტობა.
4. ჩანაწერები: daily + full, rassinchrons ალერტები და „refund სხვა წყაროზე“.
5. UX: დაბრუნების ადრესატის აშკარა ჩვენება, ETA, გამონაკლისების მიზეზები; წერილების/ჩეკების შაბლონები.
6. AML/KYC: ნაბიჯი ალტერნატიული გადახდებისთვის, SoF/SoW, დენის შემთხვევები.
7. ტესტის ნაკრები: void ფანჯარა, ნაწილობრივი refund, split-tender, დახურული ბარათი/IBAN, ვაუჩერი, Apple/Google Pay, PSP დეგრადაცია.

რეზიუმე

Same-method/refund-to-source წესი არის უსაფრთხოების, შესაბამისობისა და პროგნოზირების გასაღები. გააკეთეთ void - refund (მკაცრად საჭიროების შემთხვევაში) ალტერნატიული payout, შეინარჩუნეთ წესები policy ძრავაში explain ლოგოებით, უზრუნველყეთ idempotence, webhooks და ჩანაწერები, დაუკავშირდით ადრესატს და ETA- ს გამჭვირვალედ. გამონაკლისები - მხოლოდ step-up KYC/SoF და აშკარა აუდიტის კვალი. ასე რომ, თქვენ ამცირებთ რისკებს, მხარდაჭერის ხარჯებს და დავის რაოდენობას, შეინარჩუნებთ მომხმარებელთა ნდობას.