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

• 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개의 회사와 은행이 메시지를 보내고 다시 돌려받으며, 각 단계에 필요한 검사를 수행함
• 실패가 발생해도 상태 조회, 자동 조정, 반환 기한과 지연 벌금이 적용돼 사용자 자금은 입금 확정 또는 반환으로 마무리됨