베트남: VietQR, NAPAS 247, MoMo는 결제의 서로 다른 계층에 있다

"VietQR"과 "MoMo" 버튼 두 개가 있는 결제 화면을 떠올려 봅시다. VietQR MoMo 두 결제는 겉보기에 똑같이 빠르지만 흐름이 다릅니다. 첫 번째는 구매자가 은행 계좌 정보를 스캔해 돈을 송금하는 방식입니다. 두 번째는 합의된 MoMo 결제 시나리오를 여는 방식입니다. 남는 식별자도 다르고 필요한 승인도 다릅니다. 둘을 하나의 내부 원장으로 합칠 수는 있지만, 외부 상태값이 같다고 선언할 수는 없습니다.

특히 VietQR과 NAPAS 247을 순차적으로 일어나는 독립된 결제 두 건으로 보면 안 됩니다. NAPAS FastFund 247 via VietQR이라는 특정 상품에서 코드는 같은 은행 송금의 수취 정보를 편리하게 지정하는 수단입니다. 아래에서는 이 구조를 MoMo 가맹점 API와 분리해서 설명합니다. 여기서 다루는 것은 합법적인 매출 수납이며, 어떤 업종이든 현지 결제 레일을 써도 된다는 허가가 아닙니다.

VietQR 구매 한 건: 무엇을 확인해야 하나

NAPAS는 VietQR 스캔을 통한 참여 은행 계좌 간 송금을 24시간, 건당 5억 VND 미만으로 설명합니다. 이는 해당 송금 상품에 대한 설명이지, 베트남의 모든 QR 결제에 대한 설명이 아닙니다. 코드는 은행 정보 입력을 쉽게 해 줄 뿐, 수취인이 귀사 PSP와 계약된 가맹점이라는 것을 증명하지 않습니다. NAPAS 설명.

결제 화면 쪽에서는 은행, 입금 계좌, 표시되는 수취인, 예상 금액, 송금 메모, 안내 발급 시각, 주문 유효기간을 기록해 두면 유용합니다. 이는 내부 기록에 권장하는 필드이지, 모든 정적 VietQR에 이 정보가 다 들어 있다는 뜻이 아닙니다. 금액이나 reference를 결제자가 직접 입력한다면, 입력 오류, 메모 누락, 주문 종료 후 결제가 발생했을 때의 처리 방식을 미리 정해야 합니다.

위험한 착각은 이렇습니다. "QR에 주문번호가 들어 있으니 은행이 주문번호를 편한 필드로 돌려줄 것이다." 전체 경로를 확인해야 합니다. 안내 생성, 구매자 은행 앱 화면, 실제 입금, 수취 측 내보내기 데이터까지입니다. 메모가 잘리거나, 정규화되거나, 처리 채널에서 전달되지 않는다면 파일럿에서 발견해야 합니다. 계약과 테스트로 확인되지 않은 속성에 기대어 자동 입금 처리를 만들지 마십시오.

MoMo에는 가맹점 구조가 필요하다

MoMo 공식 온보딩은 merchant profile, 테스트 연동, 계정 심사, production credentials, production 점검, 런칭 승인을 순서대로 거칩니다. 이는 개인 지갑의 권한에 대한 설명이 아닙니다. 테스트 환경 접근은 연동을 개발할 수 있다는 것을 보여줄 뿐, 업종, 법인, 특정 정산 방식이 승인되었다는 뜻은 아닙니다.

두 가지 점검을 분리하십시오. 사업자 서류 심사와 구매자의 결제 승인 능력입니다. 예를 들어 현행 MoMo 코드 목록에는 C06으로 확인되지 않은 정보 때문에 NFC 생체 정보 갱신이 필요한 거절 코드 4002가 있습니다. 코드 1004는 일일 또는 월간 한도 초과, 1005는 만료된 URL 또는 QR을 뜻합니다. 원인이 서로 다르며, 무작정 요청을 반복하는 것은 해결책이 아닙니다.

모호한 "ID" 하나 대신 식별자 다섯 개

MoMo 모델에서는 partnerCode, orderId, requestId, transId, 그리고 자체 주문 ID를 구분해야 합니다. 파트너와 주문은 맥락을 정하고, requestId는 요청에 해당하며, transId는 MoMo가 발급합니다. 상태 조회에는 partnerCode, orderId, requestId, 서명이 사용됩니다. 이름과 역할은 특정 문서 버전을 기준으로 삼고, 값은 대소문자와 형식을 잃지 않게 저장합니다.

자체 회계를 위해 시도 번호를 추가하십시오. 한 주문에서 첫 시도는 미결제로 끝나고 두 번째 시도가 성공할 수 있습니다. 환불은 마지막으로 열린 페이지가 아니라 성공한 금융 거래에 연결됩니다. 시도마다 예상 VND 금액과 받은 결과를 저장하고, 상품명이나 전화번호를 고유 키로 쓰지 마십시오.

브라우저 복귀보다 IPN이 더 중요하다

MoMo는 결과를 서버 간 POST로 ipnUrl에 보냅니다. 문서는 서명 검증과 partnerCode, orderId, amount 대조를 요구하며, 수신 측은 15초 이내에 HTTP 204로 응답해야 합니다. resultCode 0은 해당 거래의 성공, 9000은 승인 성공을 뜻합니다. 별도 capture가 있는 시나리오에서 후자를 출금 완료로 자동 간주해서는 안 됩니다. IPN 규칙.

자체 처리는 멱등해야 합니다. 알림이 다시 오더라도 확인된 자금 이벤트 하나는 기록 하나만 만들어야 합니다. 권장 순서는 요청 검증, 이벤트의 안정적 기록, 빠른 수신 확인, 그리고 무거운 상품 지급 작업은 큐에서 실행하는 것입니다. 알림이 유실되었다면 새 영수증을 받으려고 구매자에게 다시 결제하게 하지 말고 공식 상태 조회를 사용하십시오.

경계가 하나 더 있습니다. HTTP 2xx는 API 요청이 성공적으로 처리되었음을 보여줄 뿐, 비즈니스 코드와 거래 유형 확인을 대신하지 않습니다. 결제 페이지 생성, 승인, 최종 결제 성공은 서로 다른 질문에 답합니다. 사용자 메시지는 확인된 상태를 말해야 하며, 서버가 기술적으로 성공 응답을 줬다고 무조건 "결제 완료"를 보여줘서는 안 됩니다.

환불은 자체 결과를 가진 별도 거래다

MoMo Refund API는 원주문과 다른 새 환불 orderId, requestId, 금액, 그리고 최초 성공 결제의 transId를 요구합니다. refund 결과를 조회하는 별도 요청도 있습니다. 부분 환불은 남은 환불 가능 잔액을 넘어서는 안 됩니다. 문서는 결제수단별로 수치 한도를 구분하므로, 한도 하나를 모든 MoMo 상품에 적용해서는 안 됩니다.

학습용 사례에서 구매자가 400 000 VND를 결제했고, 이후 부분 환불이 합의되었습니다. 시스템은 승인된 환불 금액을 예약하고, 원래 transId와 연결하며, 결과를 따로 추적합니다. 요청이 타임아웃으로 끝났다면 먼저 접수 여부를 확인합니다. 이 확인 없이 새 식별자로 새 refund를 만들면 이중 환불 위험이 있습니다.

결제 API 밖에 남는 것들

정산 일정, 수수료, 유보금, 허용 상품, 사업자의 수납 권한은 계약과 적용 규정이 정합니다. MoMo 심사 통과와 은행 계좌 보유가 업종 인허가를 대신하지 않습니다. 베트남 당국은 불법 도박 조직에 대한 책임을 별도로 설명하고 있으며, 온라인 게임 규정 역시 가상 아이템을 자유롭게 인출 가능한 돈과 동일시하지 않습니다.

따라서 QR이 스캔되거나 API가 응답한다는 이유로 특정 게임 사업에 현지 결제수단이 적합하다고 결론 내릴 수 없습니다. 좋은 연동의 실질적 결과는 다른 데 있습니다. 모든 합법적 결제가 입증된 상태, 연결된 주문, 명확한 정산 의무, 검증 가능한 환불을 갖는 것입니다. 이 그림 안에서 VietQR, NAPAS 247, MoMo는 각자 다른 역할을 하며, 독립된 자금 이동 세 건을 지어낼 필요는 없습니다.