UPI 결제 한 건이 처리되는 과정

 (timeseriesofindia.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • QR 스캔부터 완료 알림까지 불과 2~3초지만, 뒤에서는 앱·스폰서 은행·NPCI 중앙 스위치·송금 및 수취 은행이라는 서로 분리된 주체가 요청과 응답을 릴레이함
  • PhonePe나 Google Pay 같은 앱은 결제 의도만 수집하고 돈이나 PIN을 직접 다루지 않으며, PSP 스폰서 은행이 UPI 주소 발급과 NPCI 연결을 맡음
  • NPCI 스위치는 송금 은행의 PIN·잔액 확인과 출금이 끝난 뒤에만 수취 은행에 입금을 요청하며, 처리 결과도 양쪽 스폰서 은행을 거쳐 앱으로 돌아옴
  • 2026년 6월 UPI는 2,272 crore건 이상을 처리했으며, 최근 결제 약 11건 중 1건이 거절되지만 시스템 자체의 기술적 실패는 400건 중 1건 미만이고 대부분은 잘못된 PIN·잔액 부족·한도 초과에서 발생함
  • 출금 후 입금 확인이 늦어진 deemed 거래는 상태 조회와 NPCI 자동 조정을 거쳐 입금 확정 또는 출금 취소로 마무리되며, 반환 지연 시 기한 규정과 하루 ₹100의 은행 벌금이 적용됨

사용자가 보는 다섯 순간

  • UPI 결제 경험은 QR 스캔, 수취인 이름과 금액 확인, PIN 입력, 결제 완료 표시, 상대방의 수취 알림이라는 다섯 순간으로 구성됨
  • 전체 과정은 보통 2~3초 안에 끝나지만, PIN 입력과 결과 표시 사이에서는 여러 조직이 각자 필요한 검사를 수행하고 다음 주체로 결과를 넘김
  • 휴대전화 앱은 결제망으로 이어지는 첫 연결점일 뿐, 사용자의 돈을 직접 다루지 않음
  • 2026년 6월 UPI는 2,272 crore건 이상의 결제를 처리해 세계 어느 실시간 결제 시스템보다 많은 거래를 운반함
  • 한 차례 결제에는 사용자 앱, 사용자 PSP, 송금 은행, NPCI, 수취 은행, 수취인 PSP, 수취인 앱이 참여하며 수취 측은 송금 측을 대칭적으로 반영함

앱은 결제 의도만 수집함

  • PhonePe, Google Pay, Paytm 같은 앱은 제3자 애플리케이션 제공자(TPAP) 로서 결제 대상과 금액을 수집하고 수취인을 표시하며, 보안 입력 패드로 PIN을 입력받음
    • 앱은 PIN을 볼 수 없음
    • 사용자 자금을 보유하지 않음
    • 은행업 면허도 보유하지 않음
  • UPI의 사용자 경쟁은 앱 계층에 집중돼 있지만 시장은 크게 편중돼 있음
    • PhonePe와 Google Pay가 전체 UPI 결제의 약 5분의 4를 처리함
    • 두 앱의 선두 구도는 여러 해 유지된 반면, 그 아래 앱들의 순위는 계속 바뀜
  • Flipkart가 2024년 출시한 super.money는 보장형 캐시백으로 사용자를 끌어들여 약 1년 만에 50위권 밖에서 상위 5위로 올라옴
  • 앱은 은행업 면허도, 결제망과의 직접 연결도 없으므로 반드시 스폰서 은행의 지원을 받아야 함

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년 출시 당시 월 수백만 건에서 2026년 6월 2,272 crore건으로 늘어남

송금 은행과 수취 은행의 순위가 다른 이유

  • 송금 측과 수취 측에서 가장 바쁜 은행의 순위는 서로 다름
  • 송금 측 순위는 고객 수와 비슷한 양상을 보임
    • State Bank of India가 큰 차이로 선두임
    • 다른 대형 소비자 은행들이 뒤를 이음
  • 수취 측에서는 Yes Bank가 다른 은행보다 크게 앞섬
    • Yes Bank의 수취 점유율은 2년 동안 약 두 배로 증가함
    • 송금 발생량은 적지만 수취량은 가장 많음
  • 이 차이는 UPI가 개인 간 결제보다 개인의 상점 결제에 더 많이 쓰이게 된 구조와 연결됨
    • 상점 결제와 개인 간 결제 비중은 2022년에 역전됨
    • 거래 건수 기준으로 상점 결제가 개인 간 결제를 넘어선 시점은 2022년 8월임
  • 상점의 UPI QR도 개인 핸들과 마찬가지로 스폰서 은행이 발급하며, 대형 가맹점 앱의 스폰서는 대부분 Yes Bank임
  • 상점에서 PhonePe QR을 스캔하면 입금은 QR 뒤의 스폰서인 Yes Bank로 먼저 들어가고, 이후 가맹점 앱의 공동 계정에서 상점 주인에게 지급됨
  • 여기서 beneficiary bank는 상점 주인이 개인적으로 이용하는 은행이 아니라 QR을 후원한 은행을 뜻함

결제가 거절되는 두 가지 이유

  • UPI는 실패한 결제를 업무상 거절과 기술적 거절로 나눠 기록함
  • 업무상 거절은 사용자 또는 결제 규칙에서 발생함
    • 잘못된 PIN
    • 잔액 부족
    • 일일 한도 초과
    • 앱이 즉시 구체적인 이유를 표시하므로 사용자가 원인을 확인할 수 있음
  • 기술적 거절은 은행 시스템이나 중앙 스위치의 처리 단계가 완료되지 못한 경우임
    • Bank server down
    • your bank’s server didn’t respond, please try again
    • 사용자 화면에서는 서버 응답 실패 외의 구체적인 원인을 파악하기 어려움
  • 최근에는 결제 약 11건 중 1건이 거절되지만, 결제망 자체의 기술적 실패는 400건 중 1건 미만임
  • 기술적 거절률은 은행과 스위치가 안정화되면서 100건 중 1건 이상에서 400건 중 1건 미만으로 매년 낮아짐
  • 업무상 거절률은 하락하지 않고 오히려 상승해, 일반적인 실패는 시스템 고장보다 PIN·잔액·한도 규칙이 집행된 결과에 가까움
  • UPI가 전국적으로 몇 시간씩 중단된 사례도 있지만 드물며, 평상시 결제 실패의 주된 원인은 한도 초과, 잔액 부족, 잘못 입력한 숫자임

성공도 실패도 확정할 수 없는 deemed 거래

  • 송금 계좌에서 돈이 빠져나간 뒤 수취 은행의 확인이 제때 돌아오지 않으면 네트워크는 입금 여부를 즉시 판단할 수 없음
    • 실제로 입금했지만 수취 은행이 결과를 보고하지 못했을 수 있음
    • 입금 자체가 이뤄지지 않았을 수도 있음
  • 이처럼 입금 여부가 확인되지 않은 거래를 deemed 상태라고 부르며, 앱은 녹색 완료 표시 대신 결제가 처리 중이라고 표시함
  • 앱은 결과를 추측하지 않고 약 90초 후 네트워크에 실제 상태를 조회할 수 있음
    • 조회 횟수는 소수로 제한됨
    • 앱들이 상태 조회 요청을 과도하게 보내 UPI 장애를 일으킨 사례가 있음
    • 사용자가 직접 조작하지 않아도 앱이 조회를 수행함
  • NPCI도 양쪽 은행을 계속 조회해 거래를 자동 조정함
    • 입금이 이뤄졌다면 결제를 확정함
    • 입금되지 않았다면 출금을 취소하고 돈을 반환함
  • 반환 시점은 은행의 재량에 맡겨지지 않음
    • 일반 이체는 하루 이내 반환돼야 함
    • 가맹점 결제는 며칠 이내 반환돼야 함
    • 기한을 넘기면 은행에 하루 ₹100의 벌금이 부과됨
  • UPI는 모든 결제를 즉시 확정하지 못하더라도, 사후 조정 규칙을 통해 입금을 확정하거나 사용자에게 돈을 반환하도록 설계됨
  • 이러한 보류 거래는 원래도 흔하지 않았으며, 이를 처리하는 조정 체계는 계속 강화됨

숨겨진 결제 릴레이

  • 사용자가 보는 스캔, 이름과 금액, PIN, 완료 표시, 수취 알림 사이에는 앱 → 스폰서 → NPCI 허브 → 은행으로 이어지는 릴레이가 존재함
  • 한 번의 결제 뒤에서는 7개의 회사와 은행이 메시지를 보내고 다시 돌려받으며, 각 단계에 필요한 검사를 수행함
  • 실패가 발생해도 상태 조회, 자동 조정, 반환 기한과 지연 벌금이 적용돼 사용자 자금은 입금 확정 또는 반환으로 마무리됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 인도 밖에 있거나 UPI를 자주 쓰지 않는 사람은 거래 범위를 체감하기 어려움. 가족 간 송금부터 과자·차 같은 소액 구매, 자동차 정비·배관 등 각종 서비스, 온라인 쇼핑, 버스·항공·트램·택시·기차까지 거의 모든 결제에 사용함
    웹 앱의 UPI QR 코드를 휴대폰으로 스캔하거나 모바일 앱에서 UPI 결제 화면을 바로 열 수 있음. Kolkata 같은 도시에서는 나와 배우자가 하루 20~30건, 히말라야의 작은 마을에서도 하루 6~8건 정도 결제함

    • 영구 자격 증명 대신 일회용 코드를 사용하는 체계가 영어권에서는 지나치게 저평가됨. 자녀·친구·배우자·부하 직원에게 신용카드를 맡기는 것보다 앱에서 승인해야 하는 단일 거래용 OTP를 건네는 편이 훨씬 안전함
      폴란드의 Blik은 6자리 코드를 사용하므로, 신뢰하는 지인이 ATM에 있을 때 전화로 코드를 불러주는 식으로도 활용할 수 있음
    • 작은 마이크로 SaaS에 UPI 결제를 추가하고 나서야 인도에서 매출이 발생하기 시작함. 이전에는 인도 사용자의 가입을 끌어내기가 거의 불가능할 정도였음
    • 정부가 소액 결제를 테러 활동으로 해석해 은행 계좌를 압류할 때를 대비한 계획이 있는가? 나라마다 속도는 다르지만 이런 과정을 겪은 뒤 결국 현금으로 회귀하게 된다고 봄

  • UPI를 운영하는 이들을 깊이 존경함. 인도의 노년층까지 완전히 디지털 결제로 전환시킨 것은 세계적으로 유례없는 성과임

    • 브라질의 PIX와 스웨덴의 Swish도 비슷했으며, 그 밖에도 선례가 많을 것임
    • 인도에는 대규모 신용카드 결제망이 없었기 때문에 가능했음. 현금에서 디지털 결제로 곧바로 넘어간 셈임

  • UPI가 작동하는 것은 맞지만 개인정보 보호와 자율성 측면에서는 끔찍한 체계임. 중개자가 너무 많고 전화번호가 필요하며 개인 신원과 연결되므로 어떤 의미에서도 개인 간 결제 체계라고 부르기 어려움
    Visa나 Mastercard 대신 정부가 통제한다는 것만 다름

    • Visa와 Mastercard도 거래 정보를 미국 정부 등에 제공함. Hot Watch를 통해 미국 정부는 특정 대상을 실시간 감시하고, Bank Secrecy Act는 민간 결제망과 카드 발급 은행이 무급 국가 대리인처럼 행동하도록 법적으로 강제함
      그나마 UPI는 정보를 공유하는 정부의 수가 더 적다고 볼 수도 있음
    • 결국 화폐 자체가 정부의 통제를 받음

  • 브라질의 PIX는 UPI와 매우 비슷함. 각국 정부가 자체 인스턴스를 운영하는 오픈소스 방식의 전 세계 UPI 체계를 만들지 못할 이유가 있는가?

  • UPI가 인도의 성장에 어떤 영향을 주는지 수치로 분석할 수 있을까? 비공식 경제의 일부를 제도권으로 편입하는 효과도 있을 듯함

  • 연간 220억 건이면 NPCI 스위치의 평균 처리량은 약 초당 700건임. 트래픽이 균일하지 않아 최대치는 몇 배 높겠지만, 장 시작 시 초당 10만 건 이상인 Nasdaq TotalView ITCH 피드와 비교하면 그다지 심해 보이지 않음

    • Nasdaq의 주문·메시지 처리량과 비교하려면 인도의 National Stock Exchange(NSE) 가 적절함. NSE는 하루 체결 주문 수가 Nasdaq보다 많음
      몇 년 전 UPI 확장 작업을 해봤는데, 실시간 결제는 훨씬 분산돼 있어 매우 복잡함. 각 거래에 자금을 보유한 두 은행, 양쪽 사용자 앱과 해당 은행, NPCI 네트워크가 관여하며 양쪽 사용자가 기다리는 동안 여러 차례 메시지를 교환해야 함. 따라서 메시지 수 기준 처리량은 실제 거래 수보다 10~25배 높음
      어느 국내 은행에서든 다른 은행으로 예외 없이 무료 송금할 수 있고 연중무휴로 작동하는 실시간 결제망은 판도를 바꿔 놓음. 느리고 비싼 미국 결제망과 대조적임
      인도에는 UPI 외에도 ACH처럼 일괄 정산하는 NEFT, UPI와 비슷하게 즉시 처리되지만 사용자 경험이 다른 IMPS, 중앙은행 RBI가 중개하는 고액 실시간 결제망 RTGS가 있음. 모두 연중무휴이며 무료임. 카드망에는 Visa와 Mastercard 외에도 정산 수수료가 훨씬 낮은 RuPay가 있음
    • 220억 건은 2026년 6월 한 달의 수치이므로 연간으로 환산하면 2,640억 건임
    • 시스템 설계 면접에서 얻을 만한 교훈임. 인구 15억 명인 나라의 인기 결제 체계도 이 정도라면, 작은 회사가 Google식 면접을 흉내 내며 설계하는 가상 시스템에 평균 초당 수백만 건은커녕 수만 건을 요구할 가능성도 낮음

  • 중앙집중형·KYC 기반의 비공개 자금 거래망이 정말 좋은 것인가?

    • 적어도 실용적임. 모바일 지갑이 성장할 때 많은 이들이 금융 기술의 토대는 탈중앙화여야 한다며 블록체인을 내세웠고, 논의는 탈중앙화·개인 간 거래·중간 암호화폐 거래·스테이블코인 같은 기술 철학에 매몰됐음
      컨설팅 회사들은 큰돈을 벌었지만 정부 기관과 은행은 제품 개발 진척 없이 수백만 달러를 어떻게 써버렸는지 의아해하게 됐고, 결국 금융 기술 혁신을 정부가 주도해서는 안 된다는 결론으로 기울었음
      대규모 정보기술 기반 시설은 미국이나 서유럽 정부의 통제·영향을 받는 기업이 각국 정부에 개발·판매하는 경우가 많아 국가 주권에도 어느 정도 영향을 미침. 정부는 통제권 위험이 있는 기성 소프트웨어를 기다리거나, 위험과 한계를 감수하고 지금 작동하는 소프트웨어를 직접 구축할 수 있음
      인도는 검증되고 예측 가능한 기반 위에 체계를 구축하는 올바른 선택을 했다고 봄
    • 사용자 경험과 실용성만 보면 매우 훌륭함. 보급률이 높고 작은 차이 가게에서도 결제가 간편해져 더 많은 손님을 받을 수 있음
      다만 은행이 인증한 정부 신분증과 연결되므로 외국인이 이용하기에는 몹시 불편함
    • 민간 은행이 같은 일을 하면서 사용자에게서 이익을 뽑아가는 것보다 훨씬 낫고, 사용자 경험이 형편없어 전 재산을 잃기 쉬운 현재의 암호화폐보다도 나음. 현금보다 실용적이지만 현금 선택권도 유지해야 함
      편리하면서 탈중앙화되고 익명성까지 갖춘 체계보다는 못하지만 아직 그런 것은 없음. Ethereum이 네이티브 계정 추상화, 매끄러운 확장성, Monero 수준의 개인정보 보호를 해결하면 5년 뒤쯤 가능할지도 모름
    • 중앙집중형이고 KYC 기반인 것은 맞지만 비공개라고 하기는 어려움. https://www.bankbazaar.com/tax/tax-on-upi-transactions.html을 참고할 수 있음
    • 좋은 체계가 맞음. 새로운 화폐를 만들려는 게 아니라 이미 작동하는 자기 돈을 사용하는 방식임

  • Thailand의 PromptPay 같은 동남아시아 QR 기반 결제도 비슷한 원리로 작동하는가?
    웹사이트와 구성도 독자를 배려해 깔끔하고 방해 요소가 전혀 없음

    • PromptPay 구조는 잘 모르지만 간단히 찾아보니 QR 스캔용 사용자 앱을 은행이 직접 운영함. 반면 UPI의 Google Pay는 제3자 앱 제공자(TPAP) 이며, 하나의 TPAP에 동일하거나 서로 다른 은행의 계좌 여러 개를 연결할 수 있음
      은행 간 프로토콜 구현도 다를 수 있음. UPI의 거래 메시지는 비동기식으로, NPCI가 송금 은행에 출금 요청인 ReqPay를 보내면 은행은 같은 HTTP 요청에서 확인 메시지인 Ack만 반환함. 처리가 끝나면 은행 스위치가 NPCI의 콜백 엔드포인트로 RespPay를 보내고 NPCI가 다시 Ack를 반환함. NPCI가 수취 은행에 입금 요청을 보낼 때도 비슷하게 진행됨

  • 내용도 좋지만 crore/billion 전환 기능이 특히 훌륭함. 인도 관련 웹사이트에 널리 퍼지면 좋겠지만, CR/BN만으로는 용도를 바로 알기 어려우니 도구 설명이 있으면 좋겠음

    • 그 기능인 줄 몰랐음. 처음에는 HI/EN 같은 언어 전환 버튼처럼 보였지만 어떤 언어의 약자인지 알 수 없었고 실제로 언어도 바뀌지 않았음. 알고 보니 좋은 아이디어임
답변달기