दक्षिण कोरिया: वर्चुअल अकाउंट, बैंक ट्रांसफ़र और KakaoPay/Toss बटन

कोरियाई पेमेंट इंटरफ़ेस में एक ही बटन के पीछे बुनियादी रूप से अलग दायित्व छिपे हो सकते हैं। बैंक ट्रांसफ़र, ऑर्डर के भुगतान के लिए वर्चुअल अकाउंट और KakaoPay या Toss Pay के ज़रिए easy-pay को "लोकल P2P" जैसी एक कैटेगरी में नहीं डालना चाहिए। इन्हें शुरू करने, कन्फ़र्म करने और रिफ़ंड करने के तरीक़े अलग हैं। प्रोसेसिंग के लिए यह सबसे पहले पेमेंट लाइफ़साइकल का सवाल है।

एक और काम का फ़र्क़: कंज़्यूमर सर्विस Toss Pay और पेमेंट गेटवे Toss Payments एक ही पेमेंट मेथड के नाम नहीं हैं। गेटवे के API में TRANSFER, VIRTUAL_ACCOUNT और EASY_PAY अलग-अलग हैं। सिर्फ़ Toss शब्द से यह तय नहीं किया जा सकता कि ख़रीदार ने बैंक अकाउंट इस्तेमाल किया, सुविधाजनक इंटरफ़ेस के अंदर कार्ड, या कोई अन्य तय साधन।

Virtual account: पहले डिटेल्स, फिर पैसा

Toss Payments के वर्चुअल अकाउंट इंटीग्रेशन में कन्फ़र्मेशन कॉल अकाउंट जारी करती है, भुगतान पूरा नहीं करती। पैसा जमा होने तक WAITING_FOR_DEPOSIT रहता है; सही राशि आने के बाद DONE। यह इस प्रोडक्ट की दस्तावेज़ी ख़ासियत है। अगर डेवलपर सामान्य कार्ड भुगतान का लॉजिक कॉपी कर दे और सफल API रिस्पॉन्स के तुरंत बाद सामान दे दे, तो वह बिना भुगतान वाली डिटेल्स पर ही सामान दे सकता है।

paymentKey और orderId को अलग-अलग सहेजना होगा। virtualAccount में accountNumber, bankCode, customerName, dueDate उपलब्ध हैं; refundStatus और settlementStatus का अलग से वर्णन है। इसलिए एक paid फ़्लैग पूरा साइकिल नहीं दिखा सकता। पुष्ट ख़रीद, प्रोसेस में चल रहा रिफ़ंड और मर्चेंट के साथ अधूरा सेटलमेंट एक ही ऑर्डर से एक साथ जुड़े हो सकते हैं।

इंटरनल लेजर को जारी किए गए अकाउंट को सटीक राशि, समय-सीमा और भुगतान प्रयास से जोड़ना चाहिए। समय को मूल टाइम ज़ोन और एक साझा आंतरिक स्केल, दोनों में रखना बेहतर है, ताकि नाइट शिफ़्ट में डेडलाइन न खिसकें। अगर पैसा जमा होने से पहले ऑर्डर रद्द हुआ, तो यह अभी रिफ़ंड नहीं है: लौटाने को कुछ है ही नहीं। यूज़र को निर्देश का रद्द होना दिखना चाहिए, किसी ऐसे refund का वादा नहीं जो मौजूद नहीं।

डॉक्यूमेंटेशन की एक असामान्य बात: स्टेटस पीछे लौट सकता है

Toss Payments जमा में त्रुटियों के बारे में चेतावनी देता है, जिनमें DONE वापस WAITING_FOR_DEPOSIT में बदल जाता है। साथ ही PAYMENT_STATUS_CHANGED और DEPOSIT_CALLBACK दोनों को एक साथ सब्सक्राइब करने से एक भुगतान पर दो इवेंट आते हैं। इवेंट का विवरण। यह प्रोसेसिंग को "एक बार DONE देख लिया — अब कुछ नहीं पढ़ेंगे" के सिद्धांत पर न बनाने का पर्याप्त कारण है।

ऑपरेशनल निष्कर्ष: मौजूदा निर्देश के अनुसार webhook की प्रामाणिकता जाँचें, ट्रांज़िशन का इतिहास सहेजें और असाधारण उलटे ट्रांज़िशन को जाँच के लिए भेजें। सिर्फ़ एक बेमेल इवेंट के आधार पर ख़रीदार से अपने आप दोबारा पैसा जमा करने को नहीं कहना चाहिए। पहले प्रोवाइडर से मौजूदा स्थिति पता करें और ग्राहक को पुष्ट स्थिति बताएँ, वरना अपवाद दोहरी कटौती और टकराव में बदल जाता है।

यह भी अलग से दर्ज है कि राशि सही हो तो ख़रीदार और पैसा जमा करने वाले के नाम अलग होने पर भी वर्चुअल अकाउंट भुगतान तकनीकी रूप से अस्वीकार नहीं होता। इसका मतलब यह नहीं कि ऐसी ज़िम्मेदारियों वाले बिज़नेस में भुगतानकर्ता की पहचान को नज़रअंदाज़ किया जा सकता है। अकाउंट और राशि से इनकमिंग भुगतान का सफल मिलान यह साबित नहीं करता कि पैसे का स्रोत रजिस्टर्ड ग्राहक का है।

अकाउंट में रिफ़ंड: यहाँ सचमुच अतिरिक्त डेटा चाहिए

पहले से भुगतान किए गए वर्चुअल अकाउंट का रिफ़ंड करते समय Toss Payments refundReceiveAccount का डेटा माँगता है: बैंक, अकाउंट नंबर और खाताधारक का नाम। पैसा जमा होने से पहले रद्द करने के लिए ये डिटेल्स ज़रूरी नहीं हैं। डॉक्यूमेंटेशन में यह भी लिखा है कि संबंधित इंटरफ़ेस परिदृश्य से refundReceiveAccount पाने की विंडो सीमित है: पेमेंट विंडो खुलने के 30 मिनट बाद तक। मिली जानकारी को तय डेटा-सुरक्षा शर्तों के अनुसार संभालना चाहिए।

खाताधारक का नाम सजावटी स्ट्रिंग नहीं है। पेमेंट मेथड गाइड में कॉर्पोरेट अकाउंट के नाम और स्पेस वाले लैटिन नामों की जाँच की समस्याओं का अलग से ज़िक्र है। इसलिए रिफ़ंड फ़ॉर्म को बताना चाहिए कि बैंक में दर्ज वर्तनी चाहिए, और सपोर्ट को नाम की ग़लती, ग़लत नंबर और तकनीकी गड़बड़ी में फ़र्क़ करना चाहिए। जाँच में फ़ेल हुए अकाउंट को किसी दूसरे प्राप्तकर्ता से बदलकर "ठीक" नहीं किया जा सकता।

व्यावहारिक टेस्ट में दो स्वतंत्र परिदृश्य हैं: जारी किए गए लेकिन बिना भुगतान वाले अकाउंट को रद्द करना, और पुष्ट इनकमिंग के बाद अनुमत राशि लौटाना। फिर रिपोर्ट और असल नतीजे की जाँच करें। अगर टीम ने सिर्फ़ पहला परिदृश्य दिखाया, तो पैसा लौटाने की क्षमता अभी साबित नहीं हुई है।

KakaoPay: टोकन के साथ लौटने के बाद भी approve चाहिए

KakaoPay के एकल भुगतान में पहले ऑर्डर डेटा और CID के साथ ready कॉल होती है, फिर tid सहेजा जाता है। यूज़र ऑथेंटिकेशन के बाद pg_token आता है; सर्वर approve कॉल करता है और उसे tid, partner_order_id और partner_user_id से जोड़ता है। रिस्पॉन्स में भुगतान का tid और किसी ख़ास अनुरोध का aid अलग होते हैं। इससे रद्दीकरण और जाँच में संबंध नहीं खोता। Single-payment API।

डेवलपर के लिए सिर्फ़ happy path अहम नहीं है। यूज़र पेज बंद कर सकता है, दूसरा ऑर्डर खोल सकता है या देरी के बाद लौट सकता है। टोकन का सही सहेजे गए संदर्भ से मिलान सर्वर पर होना चाहिए। "इस फ़ोन का आख़िरी ऑर्डर" चुनना ग़लत है। डिवाइस और सेशन इंटरफ़ेस की मदद करते हैं, लेकिन वित्तीय प्रयास और ऑर्डर के स्पष्ट संबंध की जगह नहीं लेते।

उपलब्ध मेथड और सेटलमेंट अनुबंध तय करता है

KakaoPay मर्चेंट कोड जारी करने से पहले मर्चेंट की जाँच का वर्णन करता है। Toss Payments भी अनुबंध के तहत जुड़े मेथड की जाँच की ओर भेजता है। टेस्ट credentials और इंस्टॉल किया गया SDK यह नहीं दर्शाते कि बिज़नेस को कोई भी मेथड चालू करने का अधिकार मिल गया। लॉन्च कार्ड में लीगल एंटिटी, अनुमत कैटेगरी, MID/CID, मेथड और सेटलमेंट अकाउंट दर्ज किए जाते हैं।

सावधानी से बने webhook के बावजूद अलग settlement report चाहिए। Toss Payments के API में सेटलमेंट और पेआउट की जानकारी है; असल शेड्यूल और कटौतियाँ आपके अनुबंध के अनुसार जाँची जाती हैं। ऑर्डर, सफल इनकमिंग, रद्दीकरण और पेआउट के लिए net का मिलान करें। इससे तकनीकी रूप से पूरी हुई ख़रीद और PSP के उस दायित्व में फ़र्क़ किया जा सकता है जो अभी बैंक ट्रांसफ़र से चुकाया नहीं गया।

कोरियाई पेमेंट मार्केट जुए की आम अनुमति नहीं है

कोरिया गणराज्य का आपराधिक क़ानून जुए और उसके लिए जगह या स्पेस चलाने को अलग से नियंत्रित करता है। वर्चुअल अकाउंट पाने या KakaoPay भुगतान करा पाने से किसी ख़ास ऑनलाइन कैसीनो की वैधता नहीं निकाली जा सकती। विदेशी लाइसेंस लागू स्थानीय आधार और प्रोवाइडर की मंज़ूरी की जगह नहीं लेता; कैटेगरी छिपाना कोई स्वीकार्य हल नहीं है।

अच्छे कोरियाई checkout को ज़्यादा बटन नहीं, कम अंदाज़े चाहिए। ख़रीदार को अगला क़दम समझ आना चाहिए, ऑपरेटर को भरोसेमंद स्टेटस दिखना चाहिए, अकाउंटेंट को सेटलमेंट मिलना चाहिए, और रिफ़ंड जाँचे गए आधार पर तय डिटेल्स पर पूरा होना चाहिए। यही नियंत्रित मर्चेंट एक्सेप्टेंस को ट्रांसफ़र के बेतरतीब ढेर से अलग करता है।