กระบวนการที่ธุรกรรมการชำระเงิน UPI หนึ่งรายการถูกประมวลผล

• ตั้งแต่สแกน QR ไปจนถึงการแจ้งเตือนว่าเสร็จสิ้น ใช้เวลาเพียง 2–3 วินาทีเท่านั้น แต่เบื้องหลังมี หน่วยงานที่แยกจากกัน ได้แก่ แอป, ธนาคารผู้สนับสนุน, สวิตช์กลางของ NPCI, ธนาคารผู้โอน และธนาคารผู้รับ ที่ผลัดกันส่งต่อคำขอและคำตอบ
• แอปอย่าง PhonePe หรือ Google Pay ทำหน้าที่เพียงเก็บเจตนาการชำระเงิน และไม่ได้จัดการเงินหรือ PIN โดยตรง ขณะที่ ธนาคารผู้สนับสนุน PSP เป็นผู้รับผิดชอบการออกที่อยู่ UPI และการเชื่อมต่อกับ NPCI
• สวิตช์ของ NPCI จะขอให้ธนาคารผู้รับเงินทำรายการฝากเข้าเฉพาะหลังจากที่ธนาคารผู้โอนได้ตรวจสอบ PIN, ตรวจสอบยอดคงเหลือ และหักเงินเสร็จแล้วเท่านั้น และผลลัพธ์การประมวลผลก็จะย้อนกลับไปยังแอปผ่านธนาคารผู้สนับสนุนของทั้งสองฝ่าย
• ในเดือนมิถุนายน 2026 UPI ประมวลผลธุรกรรมมากกว่า 2,272 crore รายการ และแม้ช่วงหลังจะมีการปฏิเสธประมาณ 1 ใน 11 ธุรกรรม แต่ความล้มเหลวทางเทคนิคของระบบเองมีน้อยกว่า 1 ใน 400 โดยส่วนใหญ่เกิดจาก PIN ผิด, ยอดเงินไม่พอ, หรือเกินวงเงิน
• ธุรกรรมแบบ deemed ที่การยืนยันการฝากเข้าล่าช้าหลังจากหักเงินแล้ว จะสิ้นสุดลงด้วยการยืนยันการฝากเข้าหรือการยกเลิกการหักเงิน ผ่านการตรวจสอบสถานะและการกระทบยอดอัตโนมัติของ NPCI และหากการคืนเงินล่าช้าจะมีการบังคับใช้กำหนดเวลาและค่าปรับธนาคารวันละ ₹100

---

ห้าช่วงเวลาที่ผู้ใช้มองเห็น

• ประสบการณ์การชำระเงินด้วย UPI ประกอบด้วยห้าช่วงเวลา ได้แก่ การสแกน QR, การตรวจสอบชื่อผู้รับและจำนวนเงิน, การป้อน PIN, การแสดงว่าชำระเสร็จ, และการแจ้งเตือนว่าปลายทางได้รับเงินแล้ว
• กระบวนการทั้งหมดมักจบภายใน 2–3 วินาที แต่ระหว่างการป้อน PIN กับการแสดงผลลัพธ์ มีหลายองค์กรที่ดำเนินการตรวจสอบตามหน้าที่ของตนและส่งผลต่อไปยังหน่วยงานถัดไป
• แอปบนโทรศัพท์มือถือเป็นเพียงจุดเชื่อมแรกเข้าสู่เครือข่ายการชำระเงิน ไม่ได้จัดการเงินของผู้ใช้โดยตรง
• ในเดือนมิถุนายน 2026 UPI ประมวลผลการชำระเงินมากกว่า 2,272 crore รายการ มากกว่าระบบชำระเงินแบบเรียลไทม์ใด ๆ ในโลก
• การชำระเงินหนึ่งครั้งมีผู้เกี่ยวข้องคือ แอปของผู้ใช้, PSP ของผู้ใช้, ธนาคารผู้โอน, NPCI, ธนาคารผู้รับ, PSP ของผู้รับ, และแอปของผู้รับ โดยฝั่งผู้รับสะท้อนโครงสร้างของฝั่งผู้โอนอย่างสมมาตร

แอปเก็บเพียงเจตนาการชำระเงิน

• แอปอย่าง PhonePe, Google Pay, Paytm ทำหน้าที่เป็น ผู้ให้บริการแอปพลิเคชันบุคคลที่สาม (TPAP) โดยเก็บข้อมูลว่าจะจ่ายให้ใครและจำนวนเท่าไร แสดงผู้รับ และรับ PIN ผ่านแป้นพิมพ์สำหรับข้อมูลปลอดภัย
  • แอปไม่สามารถมองเห็น PIN ได้
  • แอปไม่ได้ถือครองเงินของผู้ใช้
  • แอปไม่มีใบอนุญาตประกอบธุรกิจธนาคาร
• แม้การแข่งขันของ UPI ฝั่งผู้ใช้จะกระจุกอยู่ที่ชั้นแอป แต่ตลาดมีความกระจุกตัวสูงมาก
  • PhonePe และ Google Pay ประมวลผลธุรกรรม UPI รวมกันประมาณ 4 ใน 5 ของทั้งหมด
  • ตำแหน่งผู้นำของสองแอปนี้คงอยู่มาหลายปี ขณะที่อันดับของแอปถัดลงมายังคงเปลี่ยนไปเรื่อย ๆ
• super.money ที่ Flipkart เปิดตัวในปี 2024 ดึงผู้ใช้ด้วยแคชแบ็กแบบรับประกัน และไต่จากนอก 50 อันดับแรกขึ้นมาอยู่ใน 5 อันดับแรกภายในเวลาประมาณ 1 ปี
• แอปไม่มีทั้งใบอนุญาตธนาคารและการเชื่อมต่อโดยตรงกับเครือข่ายการชำระเงิน จึงต้องพึ่งพาธนาคารผู้สนับสนุนเสมอ

ธนาคารผู้สนับสนุน PSP และที่อยู่ UPI

• บทบาทด้านใบอนุญาตและการเชื่อมต่อเครือข่ายการชำระเงินของแอป เป็นหน้าที่ของธนาคารผู้สนับสนุนที่เป็น ผู้ให้บริการชำระเงิน (PSP)
  • เชื่อมต่อเข้ากับระบบส่วนกลาง
  • ออกที่อยู่ UPI ที่ใช้แทนตัวผู้ใช้
  • เชื่อมโยงโทรศัพท์มือถือกับบัญชีธนาคารในการตั้งค่า UPI ครั้งแรก
• คำต่อท้ายหลัง @ ใน UPI ID ไม่ได้บอกว่าใช้แอปอะไร แต่บอกว่าเป็น ธนาคารผู้สนับสนุน ใด
  • @ybl เป็นของ Yes Bank
  • @okaxis เป็นของ Axis
  • แฮนเดิลของ PhonePe ดำเนินการโดย Yes Bank, Axis, ICICI
  • แฮนเดิลของ Google Pay ดำเนินการโดย Axis, HDFC, ICICI, State Bank
• แอปขนาดใหญ่ส่วนใหญ่ใช้ธนาคารผู้สนับสนุนหลายแห่ง ไม่ใช่เพียงแห่งเดียว
  • ช่วยเพิ่ม ความทนทาน เพื่อไม่ให้ปัญหาของธนาคารแห่งเดียวทำให้ทั้งแอปหยุดทำงาน
  • ช่วยหลีกเลี่ยงไม่ให้ผู้สนับสนุนรายเดียวต้องแบกรับปริมาณธุรกรรมทั้งหมดของแอป
• หากผู้โอนและผู้รับอยู่ภายใต้ผู้สนับสนุนรายเดียวกัน ธนาคารนั้นสามารถตรวจสอบที่อยู่ทั้งสองฝั่งจากบัญชีภายในของตนเองและข้ามไดเรกทอรีกลางได้
  • ทำให้ประมวลผลเร็วขึ้น
  • ประหยัดค่าธรรมเนียมตรวจสอบที่อยู่ได้ประมาณ 1 paisa
• สิ่งที่ออกจากโทรศัพท์มือถือไม่ใช่เงิน แต่เป็นคำขอที่แอปประกอบขึ้นและธนาคารผู้สนับสนุนลงลายเซ็นกำกับ
  • ก่อนชำระเงิน ระบบจะตรวจสอบชื่อเจ้าของจริงของที่อยู่ที่สแกนเพื่อเปิดโอกาสให้พบผู้รับผิดคน
  • PIN ถูกจับและเข้ารหัสโดยองค์ประกอบกลางที่ผ่านการรับรองบนโทรศัพท์มือถือ และแอปไม่สามารถรู้เนื้อหาได้แม้แต่ระหว่างส่งต่อ
  • ในไลบรารีส่วนกลางของ NPCI UPI API PIN จะถูกส่งในรูป Creds type="MPIN"

ลำดับการประมวลผลของสวิตช์กลาง NPCI

• การชำระเงิน UPI ทั้งหมดถูกรวมเข้าสู่ สวิตช์กลาง เพียงตัวเดียวที่ดูแลโดย NPCI ซึ่งเป็นหน่วยงานดำเนินงานแบบไม่แสวงหากำไร
• สวิตช์จะส่งคำขอไปยังธนาคารผู้สนับสนุนที่ดูแลที่อยู่ UPI ของผู้รับก่อน โดยธนาคารนั้นจะแปลงแฮนเดิลให้เป็นบัญชีจริง
• ลำดับการเคลื่อนย้ายเงินถูกกำหนดตายตัว
  1. NPCI ขอให้ธนาคารผู้โอนหักเงิน
  2. มีเพียงธนาคารผู้โอนเท่านั้นที่สามารถถอดรหัส PIN ที่ส่งมาจากโทรศัพท์ได้ จึงเป็นขั้นตอนที่มีการตรวจสอบ PIN
  3. ธนาคารผู้โอนตรวจสอบยอดเงินและหักเงิน แล้วจึงส่งผลกลับมา
  4. เมื่อยืนยันการหักเงินแล้วเท่านั้น NPCI จึงขอให้ธนาคารผู้รับฝากเงินเข้า
  5. รอการยืนยันการฝากเข้าจากธนาคารผู้รับ
• เงินจะ ถูกหักออกก่อนแล้วจึงฝากเข้าเสมอ ไม่ได้ทำในลำดับตรงข้าม
• ผลลัพธ์ไม่ได้ถูกส่งตรงจาก NPCI ไปยังแอป แต่ผ่าน PSP ของทั้งสองฝ่าย
  • เมื่อ PSP ฝั่งผู้โอนส่งผลสำเร็จไปยังแอป จึงจะแสดงหน้าจอเสร็จสิ้นสีเขียว
  • เมื่อ PSP ฝั่งผู้รับส่งผลลัพธ์ไปยังแอปของอีกฝ่าย จึงจะแสดงการแจ้งเตือนการรับเงิน
• เนื่องจากมีสวิตช์กลางเพียงตัวเดียว จึงแทบไม่มีข้อมูลเปรียบเทียบเกี่ยวกับการทำงานภายในเผยแพร่ออกมา และขนาดของมันสะท้อนผ่านปริมาณงานรวม
  • UPI เติบโตจากระดับหลายล้านรายการต่อเดือนตอนเปิดตัวในปี 2016 ไปเป็น 2,272 crore รายการ ในเดือนมิถุนายน 2026

เหตุใดอันดับของธนาคารฝั่งผู้โอนกับฝั่งผู้รับจึงต่างกัน

• อันดับของธนาคารที่มีงานมากที่สุดในฝั่งผู้โอนและฝั่งผู้รับไม่เหมือนกัน
• อันดับฝั่งผู้โอนมีแนวโน้มคล้ายกับจำนวนลูกค้า
  • State Bank of India นำมาเป็นอันดับหนึ่งแบบทิ้งห่าง
  • ตามมาด้วยธนาคารผู้บริโภครายใหญ่อื่น ๆ
• แต่ฝั่งผู้รับนั้น Yes Bank นำหน้าธนาคารอื่นอย่างชัดเจน
  • ส่วนแบ่งฝั่งรับของ Yes Bank เพิ่มขึ้นประมาณเท่าตัวในช่วง 2 ปี
  • แม้จะมีปริมาณการโอนไม่มาก แต่มีปริมาณการรับสูงที่สุด
• ความต่างนี้เชื่อมโยงกับการที่ UPI ถูกใช้สำหรับ การชำระเงินของบุคคลให้ร้านค้า มากกว่าการโอนระหว่างบุคคลแล้ว
  • สัดส่วนการจ่ายให้ร้านค้ากับการโอนระหว่างบุคคลพลิกแซงกันในปี 2022
  • จุดที่การจ่ายให้ร้านค้าแซงการโอนระหว่างบุคคลในแง่จำนวนธุรกรรมคือเดือนสิงหาคม 2022
• QR UPI ของร้านค้าก็ออกโดยธนาคารผู้สนับสนุนเช่นเดียวกับแฮนเดิลส่วนบุคคล และผู้สนับสนุนของแอปผู้ค้ารายใหญ่มักเป็น Yes Bank
• เมื่อสแกน QR ของ PhonePe ที่ร้านค้า เงินจะถูกฝากเข้า Yes Bank ซึ่งเป็นผู้สนับสนุนหลัง QR ก่อน จากนั้นจึงจ่ายต่อให้เจ้าของร้านจาก บัญชีรวม ของแอปผู้ค้า
• ในที่นี้ beneficiary bank ไม่ได้หมายถึงธนาคารที่เจ้าของร้านใช้ส่วนตัว แต่หมายถึงธนาคารที่สนับสนุน QR นั้น

สองเหตุผลที่การชำระเงินถูกปฏิเสธ

• UPI บันทึกการชำระเงินที่ล้มเหลวแยกเป็น การปฏิเสธเชิงธุรกิจ และการปฏิเสธทางเทคนิค
• การปฏิเสธเชิงธุรกิจเกิดจากผู้ใช้หรือกฎของการชำระเงิน
  • PIN ผิด
  • ยอดเงินไม่พอ
  • เกินวงเงินรายวัน
  • แอปจะแสดงเหตุผลที่เฉพาะเจาะจงทันที ทำให้ผู้ใช้ตรวจสอบสาเหตุได้
• การปฏิเสธทางเทคนิคเกิดเมื่อขั้นตอนประมวลผลของระบบธนาคารหรือสวิตช์กลางดำเนินไม่ครบ
  • Bank server down
  • your bank’s server didn’t respond, please try again
  • บนหน้าจอผู้ใช้มักยากที่จะทราบสาเหตุเฉพาะมากกว่าการที่เซิร์ฟเวอร์ไม่ตอบสนอง
• ช่วงหลังมีการปฏิเสธประมาณ 1 ใน 11 ธุรกรรม แต่ความล้มเหลวทางเทคนิคของเครือข่ายการชำระเงินเองมีน้อยกว่า 1 ใน 400
• อัตราการปฏิเสธทางเทคนิคลดลงทุกปี จากมากกว่า 1 ใน 100 เหลือต่ำกว่า 1 ใน 400 เมื่อธนาคารและสวิตช์มีเสถียรภาพมากขึ้น
• อัตราการปฏิเสธเชิงธุรกิจไม่ได้ลดลง กลับเพิ่มขึ้นด้วยซ้ำ ทำให้ความล้มเหลวที่พบบ่อยโดยทั่วไปใกล้เคียงกับผลของการบังคับใช้กฎเรื่อง PIN, ยอดเงิน และวงเงิน มากกว่าความขัดข้องของระบบ
• แม้จะเคยมีกรณีที่ UPI ล่มทั่วประเทศนานหลายชั่วโมง แต่เกิดขึ้นไม่บ่อย และในภาวะปกติสาเหตุหลักของการชำระเงินล้มเหลวคือเกินวงเงิน, ยอดเงินไม่พอ หรือกรอกตัวเลขผิด

ธุรกรรมแบบ deemed ที่ยืนยันไม่ได้ทั้งสำเร็จและล้มเหลว

• หากเงินถูกหักออกจากบัญชีผู้โอนแล้ว แต่การยืนยันจากธนาคารผู้รับกลับมาไม่ทันเวลา เครือข่ายจะไม่สามารถตัดสินได้ทันทีว่าเงินเข้าหรือไม่
  • อาจมีการฝากเข้าแล้วจริง แต่ธนาคารผู้รับรายงานผลกลับมาไม่ทัน
  • หรืออาจยังไม่ได้มีการฝากเข้าเลยก็ได้
• ธุรกรรมที่ยังยืนยันการฝากเข้าไม่ได้เช่นนี้เรียกว่าอยู่ในสถานะ deemed และแอปจะแสดงว่ากำลังประมวลผล แทนการขึ้นหน้าจอสำเร็จสีเขียว
• แอปจะไม่คาดเดาผลลัพธ์ แต่สามารถสอบถามสถานะจริงจากเครือข่ายได้หลังจากผ่านไปราว 90 วินาที
  • จำนวนครั้งในการสอบถามถูกจำกัดไว้เพียงไม่กี่ครั้ง
  • เคยมีกรณีที่แอปส่งคำขอตรวจสอบสถานะมากเกินไปจนทำให้ UPI ขัดข้อง
  • แอปจะเป็นผู้สอบถามเอง แม้ผู้ใช้จะไม่ได้ดำเนินการใด ๆ
• NPCI เองก็จะสอบถามทั้งสองธนาคารอย่างต่อเนื่องและทำการกระทบยอดธุรกรรมโดยอัตโนมัติ
  • หากมีการฝากเข้าแล้ว ก็ยืนยันการชำระเงิน
  • หากยังไม่ได้ฝากเข้า ก็ยกเลิกการหักเงินและคืนเงิน
• เวลาคืนเงินไม่ได้ปล่อยให้เป็นดุลยพินิจของธนาคาร
  • การโอนทั่วไปต้องคืนเงินภายใน 1 วัน
  • การชำระเงินให้ร้านค้าต้องคืนเงินภายในไม่กี่วัน
  • หากเกินกำหนด ธนาคารจะถูกปรับวันละ ₹100
• แม้ UPI จะไม่สามารถยืนยันทุกการชำระเงินได้ในทันที แต่ถูกออกแบบให้ใช้กฎการกระทบยอดภายหลังเพื่อยืนยันการฝากเข้าหรือคืนเงินให้ผู้ใช้
• ธุรกรรมที่ค้างลักษณะนี้เดิมก็ไม่ได้เกิดบ่อยอยู่แล้ว และระบบกระทบยอดที่ใช้จัดการก็ยังถูกเสริมความแข็งแกร่งอย่างต่อเนื่อง

รีเลย์การชำระเงินที่ซ่อนอยู่

• ระหว่างสิ่งที่ผู้ใช้เห็นอย่างการสแกน, ชื่อและจำนวนเงิน, PIN, หน้าจอเสร็จสิ้น, และการแจ้งเตือนการรับเงินนั้น มีรีเลย์แบบ แอป → ผู้สนับสนุน → ฮับ NPCI → ธนาคาร ซ่อนอยู่
• เบื้องหลังการชำระเงินหนึ่งครั้ง มีบริษัทและธนาคาร 7 แห่งส่งข้อความไปมา พร้อมทำการตรวจสอบที่จำเป็นในแต่ละขั้นตอน
• แม้จะเกิดความล้มเหลว ก็ยังมีการตรวจสอบสถานะ, การกระทบยอดอัตโนมัติ, กำหนดเวลาคืนเงิน และค่าปรับเมื่อคืนล่าช้า เพื่อให้เงินของผู้ใช้จบลงด้วยการยืนยันการฝากเข้าหรือการคืนเงิน

[GN⁺]

ความคิดเห็นจาก Hacker News

• สำหรับคนที่อยู่นอกอินเดียหรือไม่ได้ใช้ UPI บ่อย ๆ อาจนึกภาพขอบเขตของธุรกรรมได้ยาก ตั้งแต่การโอนเงินในครอบครัว การซื้อของมูลค่าเล็กน้อยอย่างขนมและชา บริการสารพัดประเภทอย่างซ่อมรถหรือประปา ช้อปปิ้งออนไลน์ ไปจนถึงรถบัส เครื่องบิน รถราง แท็กซี่ และรถไฟ แทบทุกการชำระเงินล้วนใช้ระบบนี้
  คุณสามารถสแกน UPI QR code ของเว็บแอปด้วยมือถือ หรือเปิดหน้าชำระเงิน UPI จากแอปมือถือได้โดยตรง ในเมืองอย่าง Kolkata ผมกับคู่สมรสจ่ายกันวันละ 20–30 รายการ ส่วนในหมู่บ้านเล็ก ๆ แถบหิมาลัยก็ยังมีราววันละ 6–8 รายการ

  • ระบบที่ใช้ โค้ดใช้ครั้งเดียว แทนข้อมูลยืนยันตัวตนถาวรถูกประเมินต่ำเกินไปมากในโลกภาษาอังกฤษ การให้ OTP สำหรับธุรกรรมเดียวที่ต้องอนุมัติผ่านแอป ปลอดภัยกว่าการฝากบัตรเครดิตไว้กับลูก เพื่อน คู่สมรส หรือลูกน้องมาก
    Blik ของโปแลนด์ใช้โค้ด 6 หลัก จึงสามารถใช้งานได้แม้กระทั่งโทรบอกรหัสให้คนที่ไว้ใจได้ตอนเขาอยู่หน้า ATM
  • พอเพิ่ม การชำระเงิน UPI ให้ micro SaaS เล็ก ๆ รายหนึ่ง รายได้จากอินเดียจึงเริ่มเกิดขึ้น ก่อนหน้านั้นแทบเป็นไปไม่ได้เลยที่จะทำให้ผู้ใช้อินเดียสมัครใช้งาน
  • มีแผนรับมือไหมในกรณีที่รัฐบาลตีความการชำระเงินมูลค่าเล็กน้อยว่าเป็นกิจกรรมก่อการร้ายแล้วอายัดบัญชีธนาคาร? แต่ละประเทศอาจเร็วช้าต่างกัน แต่ผมคิดว่าหลังผ่านกระบวนการแบบนี้ สุดท้ายก็จะ หวนกลับไปใช้เงินสด

• ผมนับถือคนที่ดูแล UPI อย่างมาก การทำให้แม้แต่ผู้สูงอายุในอินเดียเปลี่ยนมาใช้ การชำระเงินดิจิทัล ได้อย่างสมบูรณ์ ถือเป็นความสำเร็จที่แทบไม่มีที่ใดในโลกเทียบได้

  • PIX ของบราซิลกับ Swish ของสวีเดนก็คล้ายกัน และน่าจะมีตัวอย่างก่อนหน้าอีกมาก
  • สิ่งนี้เป็นไปได้เพราะอินเดียไม่มี เครือข่ายชำระเงินบัตรเครดิต ขนาดใหญ่ พูดได้ว่าอินเดียกระโดดจากเงินสดไปสู่การชำระเงินดิจิทัลโดยตรง

• UPI ใช้งานได้จริงก็จริง แต่ในแง่ ความเป็นส่วนตัวและอำนาจตัดสินใจของผู้ใช้ ถือว่าเป็นระบบที่แย่มาก มีตัวกลางมากเกินไป ต้องใช้หมายเลขโทรศัพท์ และเชื่อมโยงกับตัวตนส่วนบุคคล จึงแทบเรียกไม่ได้ว่าเป็นระบบชำระเงินระหว่างบุคคลในความหมายใด ๆ
  ต่างกันแค่ว่ารัฐบาลเป็นผู้ควบคุมแทน Visa หรือ Mastercard

  • Visa และ Mastercard ก็ส่งข้อมูลธุรกรรมให้รัฐบาลสหรัฐฯ และหน่วยงานอื่น ๆ เช่นกัน ผ่าน Hot Watch รัฐบาลสหรัฐฯ สามารถเฝ้าติดตามเป้าหมายเฉพาะได้แบบเรียลไทม์ และ Bank Secrecy Act ก็บังคับตามกฎหมายให้เครือข่ายชำระเงินเอกชนกับธนาคารผู้ออกบัตรทำตัวเหมือนตัวแทนรัฐที่ไม่ได้รับค่าจ้าง
    อย่างน้อย UPI ก็อาจถือได้ว่าแชร์ข้อมูลกับรัฐบาลจำนวนน้อยกว่า
  • สุดท้ายแล้ว ตัวเงินเองก็อยู่ภายใต้การควบคุมของรัฐบาล

• PIX ของบราซิลคล้ายกับ UPI มาก มีเหตุผลอะไรที่เราจะสร้าง ระบบ UPI ระดับโลก แบบโอเพนซอร์สที่รัฐบาลแต่ละประเทศรันอินสแตนซ์ของตัวเองไม่ได้?

  • UPI ถูก นำไปใช้แล้วใน 8 ประเทศ และกำลังผลักดันในอีกหลายสิบประเทศ[1] นอกจากนี้ยังเริ่มเชื่อมต่อกับระบบคล้ายกันของประเทศอื่น เช่น PayNow ของ Singapore[2]
    [1] https://www.pib.gov.in/PressReleasePage.aspx?PRID=2224505&re...
    [2] https://www.nipl.com/how-it-works/frequently-asked-questions...

• จะสามารถ วิเคราะห์เป็นตัวเลข ได้ไหมว่า UPI ส่งผลต่อการเติบโตของอินเดียอย่างไร? น่าจะมีผลในการดึงเศรษฐกิจนอกระบบบางส่วนเข้าสู่ระบบทางการด้วย

• ถ้าปีละ 22 พันล้านรายการ ปริมาณประมวลผลเฉลี่ยของสวิตช์ NPCI จะอยู่ที่ประมาณ 700 รายการต่อวินาที แม้ทราฟฟิกจะไม่สม่ำเสมอและค่าสูงสุดอาจมากกว่านี้หลายเท่า แต่เมื่อเทียบกับฟีด Nasdaq TotalView ITCH ที่เกิน 100,000 รายการต่อวินาทีตอนเปิดตลาด ก็ดูไม่หนักหนานัก

  • ถ้าจะเทียบกับปริมาณคำสั่งซื้อขายและข้อความของ Nasdaq ควรเทียบกับ National Stock Exchange (NSE) ของอินเดียมากกว่า NSE มีจำนวนคำสั่งที่จับคู่สำเร็จต่อวันมากกว่า Nasdaq
    เมื่อหลายปีก่อนผมเคยทำงานขยายระบบ UPI การชำระเงินแบบเรียลไทม์มีความซับซ้อนมากกว่าเพราะกระจายตัวกว่ามาก แต่ละธุรกรรมเกี่ยวข้องกับธนาคารสองฝั่งที่ถือเงิน แอปของผู้ใช้ทั้งสองฝั่งและธนาคารของแต่ละฝ่าย รวมถึงเครือข่าย NPCI และต้องแลกเปลี่ยนข้อความหลายรอบระหว่างที่ผู้ใช้ทั้งสองฝั่งรออยู่ ดังนั้นหากนับตามจำนวนข้อความ ปริมาณประมวลผลจะสูงกว่าจำนวนธุรกรรมจริง 10–25 เท่า
    เครือข่ายชำระเงินเรียลไทม์ที่โอนจากธนาคารในประเทศใดก็ได้ไปยังอีกธนาคารหนึ่งได้ฟรีโดยไม่มีข้อยกเว้น และทำงานตลอด 24/7 ตลอดปี เป็นสิ่งที่เปลี่ยนเกมโดยสิ้นเชิง ตรงกันข้ามกับเครือข่ายชำระเงินของสหรัฐฯ ที่ช้าและแพง
    นอกจาก UPI แล้ว อินเดียยังมี NEFT ที่ชำระบัญชีแบบเป็นรอบเหมือน ACH, IMPS ที่ประมวลผลทันทีคล้าย UPI แต่ประสบการณ์ผู้ใช้ต่างกัน และ RTGS ซึ่งเป็นเครือข่ายชำระเงินเรียลไทม์มูลค่าสูงที่มีธนาคารกลาง RBI เป็นตัวกลาง ทั้งหมดทำงานตลอด 24/7 ตลอดปีและฟรี ส่วนเครือข่ายบัตร นอกจาก Visa กับ Mastercard แล้ว ยังมี RuPay ที่ค่าธรรมเนียมการชำระบัญชีต่ำกว่ามาก
  • 22 พันล้านรายการเป็นตัวเลขของเดือนมิถุนายน 2026 เพียงเดือนเดียว ดังนั้นถ้าคิดเป็นรายปีจะเท่ากับ 264 พันล้านรายการ
  • นี่เป็นบทเรียนที่นำไปใช้ได้ในการสัมภาษณ์ออกแบบระบบ ถ้าระบบชำระเงินยอดนิยมของประเทศที่มีประชากร 1.5 พันล้านคนยังอยู่ประมาณนี้ บริษัทเล็ก ๆ ก็คงมีโอกาสน้อยที่จะต้องออกแบบระบบสมมติที่เลียนแบบการสัมภาษณ์สไตล์ Google แล้วต้องรองรับเฉลี่ยหลายหมื่นรายการต่อวินาที ไม่ต้องพูดถึงหลายล้านรายการต่อวินาที

• เครือข่ายธุรกรรมเงินแบบปิดที่เป็นแบบ รวมศูนย์และอิง KYC นั้นดีจริงหรือ?

  • อย่างน้อยก็ใช้งานได้จริง ตอนที่กระเป๋าเงินมือถือกำลังเติบโต หลายคนชูบล็อกเชนขึ้นมาโดยบอกว่ารากฐานของเทคโนโลยีการเงินควรเป็นแบบกระจายศูนย์ และการถกเถียงก็จมอยู่กับปรัชญาเชิงเทคโนโลยีอย่างการกระจายศูนย์ การทำธุรกรรมระหว่างบุคคล การทำธุรกรรมผ่านคริปโตเคอร์เรนซีตัวกลาง และสเตเบิลคอยน์
    บริษัทที่ปรึกษาทำเงินก้อนโตได้ แต่หน่วยงานรัฐและธนาคารกลับเริ่มสงสัยว่าเงินหลายล้านดอลลาร์ถูกใช้หมดไปได้อย่างไรโดยที่การพัฒนาผลิตภัณฑ์ไม่คืบหน้า และท้ายที่สุดก็เอนเอียงไปสู่ข้อสรุปว่านวัตกรรมเทคโนโลยีการเงินไม่ควรให้รัฐบาลเป็นผู้นำ
    โครงสร้างพื้นฐานด้านเทคโนโลยีสารสนเทศขนาดใหญ่มักถูกพัฒนาและขายให้รัฐบาลแต่ละประเทศโดยบริษัทที่อยู่ภายใต้การควบคุมหรืออิทธิพลของรัฐบาลสหรัฐฯ หรือยุโรปตะวันตก จึงส่งผลต่ออธิปไตยของชาติในระดับหนึ่ง รัฐบาลอาจรอซอฟต์แวร์สำเร็จรูปที่มีความเสี่ยงด้านการควบคุม หรือจะยอมรับความเสี่ยงและข้อจำกัดแล้วสร้างซอฟต์แวร์ที่ใช้งานได้จริงในตอนนี้ด้วยตนเองก็ได้
    ผมคิดว่าอินเดียตัดสินใจถูกต้องที่สร้างระบบบน รากฐานที่ผ่านการพิสูจน์แล้วและคาดการณ์ได้
  • ถ้าดูแค่ประสบการณ์ผู้ใช้และความใช้งานได้จริง ถือว่ายอดเยี่ยมมาก อัตราการใช้งานแพร่หลาย และแม้แต่ร้านเล็ก ๆ ที่ขายของจิปาถะก็รับชำระเงินได้ง่ายขึ้น จึงรับลูกค้าได้มากขึ้น
    อย่างไรก็ตาม เนื่องจากเชื่อมกับ บัตรประจำตัวของรัฐที่ธนาคารยืนยันแล้ว จึงไม่สะดวกอย่างมากสำหรับชาวต่างชาติที่จะใช้งาน
  • ดีกว่าการให้ธนาคารเอกชนทำสิ่งเดียวกันแล้วรีดผลประโยชน์จากผู้ใช้มาก และยังดีกว่าคริปโตเคอร์เรนซีในปัจจุบันที่ประสบการณ์ผู้ใช้แย่จนทำให้สูญเสียทรัพย์สินทั้งหมดได้ง่ายด้วย ใช้งานได้จริงกว่าเงินสด แต่ก็ควรรักษา ทางเลือกในการใช้เงินสด ไว้ด้วย
    ยังไม่ดีเท่าระบบที่ทั้งสะดวก กระจายศูนย์ และมีความไม่ระบุตัวตน แต่ตอนนี้ยังไม่มีสิ่งนั้น บางทีในอีกสัก 5 ปี ถ้า Ethereum แก้ปัญหา native account abstraction, scalability ที่ลื่นไหล และความเป็นส่วนตัวระดับ Monero ได้ ก็อาจเป็นไปได้
  • จริงอยู่ว่าเป็นแบบรวมศูนย์และอิง KYC แต่จะเรียกว่า ปิดเป็นส่วนตัว ก็คงยาก ดูอ้างอิงได้ที่ https://www.bankbazaar.com/tax/tax-on-upi-transactions.html
  • เป็นระบบที่ดีจริง ๆ ไม่ได้พยายามสร้างสกุลเงินใหม่ แต่เป็นวิธีใช้ เงินของตัวเอง ที่ใช้งานได้อยู่แล้ว

• การชำระเงินแบบ อิง QR ในเอเชียตะวันออกเฉียงใต้อย่าง PromptPay ของ Thailand ก็ทำงานด้วยหลักการคล้ายกันหรือไม่?
  เว็บไซต์และแผนภาพประกอบทำได้สะอาดตาและคำนึงถึงผู้อ่าน ไม่มีสิ่งรบกวนเลย

  • ผมไม่ค่อยรู้โครงสร้างของ PromptPay แต่ลองค้นคร่าว ๆ แล้วพบว่าแอปผู้ใช้สำหรับสแกน QR นั้นธนาคารเป็นผู้ดำเนินการเองโดยตรง ในทางกลับกัน Google Pay ของ UPI เป็น ผู้ให้บริการแอปบุคคลที่สาม (TPAP) และสามารถเชื่อมบัญชีหลายบัญชีจากธนาคารเดียวกันหรือต่างธนาคารเข้ากับ TPAP เดียวได้
    การใช้งานโปรโตคอลระหว่างธนาคารก็อาจแตกต่างกัน ข้อความธุรกรรมของ UPI เป็นแบบอะซิงโครนัส โดยเมื่อ NPCI ส่ง ReqPay ซึ่งเป็นคำขอหักเงินไปยังธนาคารผู้โอน ธนาคารจะส่งกลับเพียง Ack ซึ่งเป็นข้อความยืนยันใน HTTP request เดียวกัน เมื่อประมวลผลเสร็จแล้ว bank switch จะส่ง RespPay ไปยัง callback endpoint ของ NPCI และ NPCI ก็ส่ง Ack กลับอีกครั้ง ขั้นตอนเมื่อ NPCI ส่งคำขอฝากเงินไปยังธนาคารผู้รับก็เป็นลักษณะคล้ายกัน

• เนื้อหาก็ดี แต่ฟังก์ชัน แปลง crore/billion นั้นยอดเยี่ยมเป็นพิเศษ อยากให้แพร่หลายบนเว็บไซต์ที่เกี่ยวกับอินเดีย แต่ถ้ามีแค่ CR/BN ก็เข้าใจการใช้งานได้ยากในทันที น่าจะมี tooltip ด้วย

  • ไม่รู้เลยว่าเป็นฟังก์ชันนั้น ตอนแรกดูเหมือนปุ่มสลับภาษาอย่าง HI/EN แต่ไม่รู้ว่าเป็นตัวย่อของภาษาอะไร และจริง ๆ แล้วภาษาก็ไม่ได้เปลี่ยนไปด้วย พอรู้แล้วก็เป็นไอเดียที่ดี