LOSLES - राशि को ही भुगतान पहचानकर्ता के रूप में इस्तेमाल करने वाली ऑटोमैटिक पेमेंट सिस्टम

मैंने एक व्यक्तिगत प्रोजेक्ट के रूप में LOSLES नाम का एक open source payment processing system बनाकर सार्वजनिक किया है.

इस प्रोजेक्ट का मुख्य विचार है: "account transfer detection + राशि को ही order ID की तरह इस्तेमाल करना".
सामान्य account transfer payment आमतौर पर इस प्रक्रिया से गुजरता है.

• PG कंपनी में साइन-अप
• व्यवसाय पंजीकरण
• समीक्षा
• API integration
• payment fees लगना
• settlement का इंतज़ार

व्यक्तिगत डेवलपर या छोटे प्रोजेक्ट्स के लिए यह अक्सर काफ़ी बोझिल हो सकता है.
इसीलिए मैंने यह सोचकर इसे बनाया कि "क्या केवल राशि से order की पहचान नहीं की जा सकती?"

उदाहरण के लिए, अगर किसी प्रोडक्ट की कीमत 10,000 won है,

पहला order:
10,000 won

30 मिनट के भीतर उसी प्रोडक्ट का दूसरा order:
9,999 won

तीसरा order:
9,998 won

चौथा order:
9,997 won
...

इस तरह हर order को एक unique राशि दी जाती है.
(वास्तविक implementation में 99 won से शुरू करके 98 won, 97 won, 96 won... इस तरह discount amount घटाई जाती है.)
इसलिए server बिना अलग order number डाले भी सिर्फ़ राशि देखकर पहचान सकता है कि यह कौन-सा order है.

LOSLES Android App, KakaoPay charge notification को detect करके उसे external server पर अपने-आप भेजने का काम करता है.
Android की notification access permission (Notification Listener) का उपयोग करके यह KakaoTalk और KakaoPay app की notifications को real time में मॉनिटर करता है,
और जब charge amount वाली notification प्राप्त होती है, तो उस राशि को निकालकर सेट किए गए server URL पर POST request भेजता है.
LOSLES WEB Server के साथ इस्तेमाल करने पर, user के deposit से payment completion processing तक की पूरी प्रक्रिया को automate किया जा सकता है.

पूरी flow

1. user order बनाता है
2. server unique राशि assign करता है
3. user उसी राशि से account transfer करता है (फ़िलहाल केवल KakaoPay supported है)
4. Android app charge notification detect करता है
5. राशि server को भेजी जाती है
6. server राशि और order का matching करता है
7. payment अपने-आप completed के रूप में process हो जाता है

यानी,

"किसने भेजा" नहीं
बल्कि
"कितनी राशि भेजी" के आधार पर payment की पहचान की जाती है.

ध्यान देने योग्य बातें

महत्वपूर्ण बात यह है कि LOSLES, आधिकारिक PG को replace करने के लिए बनाया गया प्रोजेक्ट नहीं है.
बड़े पैमाने की services में PG कंपनियों द्वारा दिए जाने वाले refund, settlement, receipt, dispute handling और security features अब भी महत्वपूर्ण हैं.
लेकिन व्यक्तिगत प्रोजेक्ट या छोटे पैमाने पर digital content बेचने के मामलों में,
"payment प्राप्त करने के लिए business registration से शुरू करके PG review तक जाना पड़े"
यह मुझे ज़रूरत से ज़्यादा लगा,

और उसी प्रक्रिया के बिना automatic payment implement करने का तरीका प्रयोग करने के लिए यह प्रोजेक्ट बनाया गया है.
यह अभी beta version में है और feedback लिया जा रहा है.
खासकर नीचे दिए गए बिंदुओं पर राय सुनना चाहता हूँ.

• राशि-आधारित पहचान पद्धति की समस्याएँ
• duplicate orders को handle करने का तरीका
• security सुधार के ideas
• वास्तविक संचालन अनुभव रखने वाले लोगों की राय

धन्यवाद.

[cichol]

उदाहरण के लिए, अगर किसी रेस्तरां में किमची-जिगे भी 10,000 won है और डेनजांग-जिगे भी 10,000 won है, और 10,000 won का ऑर्डर आता है, तो क्या यह पहचानना संभव नहीं होगा कि कौन-सा मेन्यू ऑर्डर किया गया था?

[arcoding]

एक ही कीमत वाले अलग-अलग प्रोडक्ट्स के लिए भी डिस्काउंट 1 won के हिसाब से अलग-अलग देना होगा। वास्तविक उपयोग में LosLes सर्वर पर प्रोडक्ट्स रजिस्टर नहीं किए जाते, बल्कि वस्तु की मूल कीमत देखकर सिस्टम अपने-आप डिस्काउंट को अलग-अलग सेट कर देता है।

[regentag]

तो क्या इसका मतलब है कि आपको वही प्रोडक्ट अलग-अलग कीमतों पर लगातार बेचना पड़ेगा?

[arcoding]

आधा सही है और आधा गलत। तय कीमत 10,000 won ही है, लेकिन
30 मिनट के भीतर पहला पेमेंट अनुरोध 99 won की छूट के साथ होता है,
30 मिनट के भीतर दूसरा पेमेंट अनुरोध 98 won की छूट के साथ—ऐसे। लगता है कि मूल लेख में यह ठीक से समझाया नहीं गया।

[zihado]

अगर ग्राहक गलती से गलत रकम भेज दे, तो मैचिंग टूट जाएगी।

[arcoding]

वह इसकी सबसे बड़ी कमी है।
DM से मैन्युअल पूछताछ की जा सके, इतने छोटे
प्रोजेक्ट के लिए तो ठीक है, लेकिन बड़ी कंपनियों में PG कंपनी के साथ कॉन्ट्रैक्ट करने के बाद इस्तेमाल करना बेहतर लगता है।