UPI: 구매자가 쇼핑몰로 돌아왔다, 이제 주문을 내줘도 될까?

고객이 결제 앱을 닫고 다시 쇼핑몰 화면으로 돌아왔습니다. 화면 입장에서는 여정이 끝났습니다. 하지만 주문 입장에서는 핵심 질문이 아직 열려 있습니다. 가맹점이 해당 결제에 대해 검증 가능한 확인을 받았을까요? UPI 결제를 설계할 때는 서로 연결된 두 흐름을 나누는 것이 좋습니다. Intent나 QR을 거치는 구매자의 여정, 그리고 비즈니스 쪽에서 결과를 독립적으로 검증하는 흐름입니다.

판단 근거는 가맹점 쪽에서 검증된 결제 기록이어야 합니다. 구매자에게 결제 요청을 보여 주는 방식과 주문 이행을 확정하는 방식은 시스템의 서로 다른 부분입니다. 둘을 섞으면 보기 좋은 사용자 시나리오가 신뢰할 수 없는 운영 프로세스를 가릴 수 있습니다.

먼저 작동 방식을 이해하라

NPCI는 이 시스템을 즉시 결제 시스템으로 설명하며, QR과 Intent를 포함한 가맹점 연동 방식을 나열합니다. 용어를 이해하는 데는 도움이 되지만, 과거에 설명된 모든 방식을 특정 비즈니스가 지금 쓸 수 있다는 보장은 아닙니다. NPCI의 UPI FAQ.

• Intent: 결제 페이지가 거래 정보와 함께 호환되는 결제 앱을 호출하고, 구매자는 그 앱에서 결제를 이어 갑니다.
• QR: 구매자가 지원되는 앱으로 결제 정보가 담긴 코드를 스캔합니다.
• Collect: 요청 방식으로, 결제자의 가상 결제 주소(VPA)로 승인 요청을 보냅니다.

이 작동 방식은 NPCI의 상품 자료에 설명되어 있습니다. 오래된 설명은 시나리오의 구조를 이해하는 자료로 읽어야 하며, 현재 이용 가능하다는 확인으로 받아들여서는 안 됩니다. NPCI 상품 브로슈어.

적용되는 규칙은 따로 확인해야 합니다. 예를 들어 PayU는 신규 가맹점에 Intent와 QR을 안내하고, Collect는 지정된 예외에만 남겨 두고 있습니다. 요청 방식을 중심으로 연동을 만들기 전에 이용 중인 PG사에서 지원 방식을 확인하세요. 가맹점 결제 수납과 개인 간 P2P 송금은 서로 대체할 수 있는 것으로 보아서는 안 됩니다. PayU 문서.

프로세스를 주문 하나에 연결하라

2 400인도 루피짜리 가상의 구매를 생각해 봅시다. 가맹점은 자체 주문 번호를 만들고, 승인된 PG사를 통해 지원되는 시나리오를 시작합니다. 예상 금액, 통화, 수취인은 이 주문 번호와 계속 연결되어 있어야 합니다. 사용자가 사이트로 돌아온 것은 화면상의 이벤트일 뿐, 그 자체로 상품을 내줄 충분한 근거가 되지 않습니다.

예를 들어 Razorpay 가이드는 결제 서명 검증을 요구하며, 관리자 화면, 웹훅, API로 상태를 받는 방법을 설명합니다. 주문 이행 권고는 captured 상태와 연결되어 있습니다. 이것은 Razorpay의 용어이므로, 다른 PG사라면 그에 해당하는 문서상의 완료 상태를 찾아야 합니다. Razorpay 연동 단계.

자체 프로세스에서는 확인된 결제를 예상 주문과 대조하세요. 관련 식별자, 금액, 통화를 확인하고, 결과가 합의된 가맹점 구조에 속하는지도 확인하세요. 주문을 결제 완료 상태로 바꾼 근거를 저장해 두면 고객지원팀이 이벤트 순서를 재구성할 수 있습니다.

늦게 도착하는 응답에 대비하라

예시에서 구매자는 지연을 알아채고 결제 버튼을 한 번 더 누릅니다. 프로세스는 이후의 시도들을 원래 구매와 연결해 두어야 하며, 나중에 대사하기 어려운 독립 주문을 여러 개 만들어서는 안 됩니다.

웹훅을 안전하게 재처리하도록 설계하세요. 이미 완료된 주문이 상품을 다시 내주게 만들어서는 안 됩니다. 메시지가 다른 순서로 도착하면 문서화된 상태 규칙과 PG사의 확인 절차를 사용하세요. 이것은 연동 설계에 대한 권고이지, 모든 UPI 시스템이 똑같이 동작한다는 주장은 아닙니다.

결과가 불확실하다면 이해하기 쉬운 대기 상태와 문의 번호를 보여 주세요. 브라우저 시간 초과만으로 실패를 선언하지 말고, 첫 번째 시도가 확인되기 전에는 다시 결제해 달라고 요청하지 마세요. 검토 담당자, 확인 출처, PG사로 문제를 넘기는 절차를 미리 정해 두세요.

탭을 닫았다가 나중에 주문으로 돌아오는 경우도 따로 테스트하세요. 구매자는 자기 주문의 최신 상태를 보아야 하고, 직원은 시도 이력을 알기 쉽게 보아야 합니다. 사용자 세션을 이어 가기 위해 화면 편의상 결제 데이터를 수동으로 바꿔야 하는 일이 있어서는 안 됩니다.

편리한 증거로 검증을 대신하지 마라

스크린숏은 문의 건을 찾는 데 도움이 되지만, 가맹점이 열람할 수 있는 결제 기록의 확인을 대신하지는 못합니다. 직원은 UPI PIN을 알려 달라고 요청해서는 안 됩니다. NPCI도 PIN을 입력하는 QR 스캔은 돈을 받는 것이 아니라 보내기 위한 것이라고 경고합니다. NPCI 사기 주의 안내.

환불에는 정해진 절차를 사용하고, 돈을 "받기" 위한 요청을 보내지 마세요. NPCI는 가맹점의 상태 문의와 민원을 매입 은행으로 보내도록 권고합니다. NPCI 가맹점 FAQ.

QR은 만료됐는데 돈은 나중에 들어왔다

제안하는 학습용 시나리오에서 상점은 상품을 10분간 확보해 두고, 그 뒤 미결제 주문을 닫습니다. 그런데 나중에 이 주문과 연결된 결제 확인이 도착합니다. 특정 QR이나 요청에 유효 기간이 있더라도, 상품 확보 시간과 허용되는 결제 결과는 PG사 규칙에 따라 따로 정의해야 합니다. 화면 타이머가 끝났다고 해서 그것이 재무 대사가 되지는 않습니다.

늦게 도착한 확인에 대한 프로세스를 미리 정하세요. 이행 가능 여부를 확인하거나, 고객에게 합의된 해결책을 제안하거나, 지원되는 방식으로 환불하는 것입니다. 이미 품절된 상품을 자동으로 내주지 말고, 주문 레코드가 "종료"되었다는 이유로 입금을 놓치지도 마세요. 예외 건에는 담당자가 있어야 하고, 원래 시도와 연결되어 있어야 합니다.

주문 하나에 확인된 결제가 두 건 생길 수 있다

상품 중복 출고를 막는다고 초과 입금을 처리할 필요가 사라지지는 않습니다. 구매자가 다시 결제했고 두 시도가 모두 실제로 확인되었다면, 금융 객체 두 개와 주문 하나로 기록하세요. 이후 정정은 PG사의 허용된 절차에 따라 진행하세요. 보기 좋은 상태를 위해 두 번째 기록을 숨기는 것이, 검토 대기열에 초과 결제를 드러내는 것보다 위험합니다.

고객지원팀에는 중립적인 응대 시나리오가 필요합니다. 주문을 찾고, 시도들을 확인하고, 확정된 결과와 다음 업데이트 시점을 알리는 것입니다. "스크린숏을 하나 더 보내 주세요"라는 요청이 검증된 데이터 접근을 대신해서는 안 됩니다. 이런 경우는 PG사가 지원하는 기기와 시나리오에서 따로 테스트하세요. 한 앱에서 돌아오기가 잘 된다고 해서 모든 앱과 운영체제에서 똑같이 동작한다는 증거는 아닙니다.

UPI라는 이름만으로 해외 이용 가능 여부, 지원되는 자금 출처, 비용을 추론할 수는 없습니다. 구체적인 상품과 계약 내용을 확인하세요. 좋은 연동은 이해하기 쉬운 구매자 여정과, 가맹점 쪽에서 독립적으로 검증 가능한 결과를 함께 갖추고 있습니다.