인도: UPI와 IMPS는 수취 정보도, 문제 대기열도 다르다

"고객이 UPI로 보냈으니 돈은 이미 우리 것"이라는 말은 조사를 시작하기에 좋지 않은 출발점입니다. UPI와 IMPS 어느 쪽이든, 구매자 화면에는 확인 메시지가 있고, 결제 시스템에는 미완료 주문이 있고, 사업자 쪽에는 더 늦은 이벤트가 있고, 은행 거래 내역에는 주문 번호가 분명하지 않은 입금이 있을 수 있습니다. 이것은 결제 네 건이 아닙니다. 하나의 거래를 보여 주는 네 가지 모습이며, 프로세싱은 가용 잔액을 늘리기 전에 이들을 연결해야 합니다.

UPI와 IMPS는 앱이 아니라 결제 메커니즘으로 비교해야 합니다. 앱 이름은 사용자가 어디서 버튼을 눌렀는지에 답할 뿐입니다. 수취인의 계약, 증빙의 구성, 허용된 사업 활동, 환불 절차를 정하지는 않습니다. 아래에서는 적법한 가맹점 거래를 다룹니다. 인도 결제 수단이 있다는 사실만으로 도박 시장이 열리지는 않습니다.

먼저 정확히 무엇을 연동했는지 정하라

NPCI는 UPI를 IMPS 인프라 위에 구축된 즉시 결제 시스템으로 설명합니다. 가맹점 결제를 받으려면 매입사가 필요하며, 매입사가 가맹점 업종을 정하고 연동을 제공합니다. UPI 주소, QR, 앱 전환이 일반 개인 계좌를 합의된 가맹점 상품으로 바꾸지는 않습니다. NPCI 설명은 참여자의 역할을 이해하는 데 유용하지만, 오래된 사용자 시나리오 예시를 현행 출시 사양으로 자동 간주해서는 안 됩니다.

IMPS에서 일반적인 라우팅은 계좌 번호와 IFSC를 씁니다. 문서에는 휴대폰 번호와 MMID 조합도 나와 있습니다. IFSC는 은행 경로에, MMID는 해당 식별 체계에 속합니다. 이것은 merchant order ID를 대신하지 않습니다. NPCI는 SMS와 IVR을 제외한 IMPS 한도를 거래당 500 000 INR로 명시하지만, 개별 은행은 고객이 쓰는 채널을 더 엄격하게 제한할 수 있습니다.

합치지 말아야 할 필드

권장하는 결제 카드에는 내부 주문 번호, 시도 번호, 레일 유형, 사업자의 결제 식별자, 원래 형태 그대로의 은행 reference, 금액, 통화, 생성 시각, 확인 시각이 있어야 합니다. 수취 정보는 별도의 스냅숏으로 저장합니다. UPI라면 해당 결제 주소와 가맹점 컨텍스트, 은행 송금이라면 계좌와 은행 코드입니다. 원장 자체에는 PIN, OTP, 은행 비밀번호가 있어서는 안 됩니다.

왜 하필 스냅숏이 필요할까요? 주문 생성 후 수취 정보가 바뀌었을 수 있고, 고객은 예전 안내대로 결제했을 수 있습니다. 시스템이 현재 수취인만 보여 준다면 조사는 기억에 의존한 논쟁이 됩니다. 특정 시도에 발급된 조건과 그 시점의 실제 입금이 필요합니다. 이때 금액과 시각의 일치는 검색 힌트일 뿐, 돈이 특정 주문에 속한다는 증거가 아닙니다.

중개자 리포트의 'UTR' 필드가 무슨 뜻인지 운영자가 추측하게 만들지 마십시오. 용어 사전을 요청하십시오. 누가 그 값을 만들었는지, 은행 내에서 고유한지 연동 전체에서 고유한지, 환불 후에도 유지되는지, 상태 조회에 쓸 수 있는지입니다. 어떤 인터페이스는 고객용 reference를, 다른 인터페이스는 게이트웨이 식별자를 보여 줄 수 있습니다. 문서화된 대응 관계가 없으면 지원 업무에 실제 비용이 생깁니다.

성공 페이지와 자금 상태는 따로 존재한다

예를 들어 Razorpay에는 payment.authorized와 payment.captured 이벤트가 있으며, 문서는 객체가 이미 바뀌었더라도 webhook이 이벤트 시점의 상태를 전달한다고 경고합니다. 이는 특정 게이트웨이의 모델이지 UPI의 보편적 상태가 아닙니다. 자체 결제 시스템에도 같은 원칙이 유용합니다. 이벤트의 진위를 확인하고, 금액과 주문을 대조하고, 원래 상태를 저장하고, 금융 기록은 한 번만 반영합니다.

연습 사례를 봅시다. 주문은 12:05에 만료되었고 확인은 12:06에 들어왔습니다. 이 시도를 최종 미결제로 선언하면서 새 결제를 발급하고, 동시에 예전 결제를 자동으로 다시 반영할 수는 없습니다. 지연 확인 대기열을 도입하십시오. 이 대기열에서 주문을 복구할지, 승인된 절차에 따라 환불할지를 결정해야 합니다. 어느 쪽이든 사용자는 명확한 결과를 받고, 회계팀은 원래 시도와의 연결을 유지합니다.

장애 후 환불과 구매 취소 환불은 다른 프로세스다

실패 거래에 관한 RBI 규정은 수취인에게 입금되지 않은 출금과, 가맹점이 확인을 받지 못한 UPI 결제를 구분합니다. 공개된 표에는 해당 사례별로 각각 T+1과 T+5가 명시되어 있으며, 기한을 넘기면 보상이 따릅니다. 이는 특정 기술 장애를 바로잡는 기한이지, 모든 구매를 같은 기간 안에 환불해 준다는 약속이 아닙니다. T는 거래의 달력상 날짜를 뜻합니다. RBI 표.

그래서 티켓은 먼저 분류되어야 합니다. 출금이 있었는가? 확인된 입금이 있는가? 상업적 사유로 주문이 취소되었는가, 아니면 거래가 성립하지 않았는가? 별도의 refund가 실행되었는가? 고객에게 같은 금액을 새 송금으로 그냥 보내면 원거래는 미결로 남고, 나중에 자동 reversal이 일어나 이중 보상이 될 수 있습니다.

즉시 결제가 정산 계약을 설명하지는 않는다

"돈이 언제 가맹점에 있는가"라는 질문에는 계좌를 특정해야 합니다. 매입 계약에 따른 합의된 가맹점 계좌나 중간 계좌일 수 있습니다. PSP의 내부 잔액, 가용 잔액, 기업 결제 계좌로의 입금을 같은 뜻으로 보아서는 안 됩니다. settlement report 샘플을 요청하십시오. gross, 수수료, 세금 원천징수, 환불, 보류금, net입니다. 그다음 net이 실제로 은행 거래 내역에 있는지 확인하십시오.

한도도 따로 확인하십시오. 거래당, 일일, 결제자 유형, 가맹점 업종, 채널별 한도입니다. 오래된 FAQ의 숫자를 모든 UPI 결제의 보편적 한도로 바꿔서는 안 됩니다. 파일럿에서는 허용된 경계 금액과 정상적인 거절을 테스트합니다. 통제를 피하려고 결제를 쪼개는 것은 허용되지 않습니다.

게임 프로젝트의 경계선

인도의 Promotion and Regulation of Online Gaming Act, 2025는 섹션 7에서 online money gaming service에 대한 결제 지원을 금지하며, 머니 게임의 정의는 확률 게임에만 국한되지 않습니다. MeitY는 2026년 규칙과 고시도 공개하고 있습니다. 해외 게임 라이선스는 인도에서 그런 결제를 받아도 된다는 허가가 아닙니다. 연동을 논의하기 전에 해당 상품, 적용 법규, 판례에 대한 최신 법률 의견이 필요합니다.

준비 상태를 판단하는 실무 기준은 간단합니다. 팀이 결제 한 건을 표시된 수취 정보에서 입금까지, 그다음 가맹점 정산과 가능한 환불까지 재구성할 수 있어야 합니다. 스크린숏과 채팅 메시지로만 가능하다면, 처음 열 건의 송금이 즉시 처리되었더라도 그 연동은 아직 성장할 준비가 되지 않은 것입니다.