방글라데시: bKash, Nagad, 은행 계좌는 서로 대체할 수 없다

"bKash와 Nagad를 API 하나로 연동해 드립니다"라는 약속은 돈이 어느 계좌로 들어오는지에 대해 아무것도 말해 주지 않습니다. 방글라데시에서 프로세싱을 할 때 핵심 질문은 API보다 먼저 시작됩니다. 수취인이 가맹점인가, 에이전트인가, 개인 지갑 소유자인가, 결제 중개자인가? 이 역할들은 용도, 이용 조건, 제한이 서로 다릅니다. 사용자에게 익숙한 휴대폰 번호만으로는 법적·회계적 구조가 설명되지 않습니다.

bKash와 Nagad는 눈에 띄는 현지 모바일 금융 서비스입니다. 여기서는 인기 순위를 매기지 않습니다. 가입자 수, 활성 사용자 수, 가맹점 결제 건수는 서로 다른 지표이기 때문입니다. 연동 방식을 고를 때는 실제로 이용 가능한 상품, 그 계약, 그리고 중개자의 말 없이도 자금 경로를 재구성할 수 있는지를 확인하는 것이 더 중요합니다.

비슷한 화면 뒤의 네 가지 역할

개인 송금, 가맹점 결제, 에이전트의 현금 업무, 기업의 지급은 서로 다른 거래입니다. Bangladesh Bank는 국내 MFS 서비스 가운데 P2P, P2B, B2P를 따로 설명합니다. 따라서 "지갑으로 송금을 받을 수 있다"는 말은 해당 계정을 다른 회사들의 매출을 대량으로 수납하는 데 써도 된다는 증거가 되지 않습니다. 작동하는 버튼이 아니라 확인된 역할이 필요합니다.

bKash Merchant 가입 양식에서는 상점 정보, 담당자 정보, NID, 영업 허가, 은행 계좌 정보를 요구합니다. 이는 심사를 거치는 신청이지 자동 승인이 아닙니다. 소규모 소매 및 f-commerce 사업자를 위한 Personal Retail Account도 따로 있습니다. 여기서 Personal이라는 이름은 오해를 부르기 쉽지만, 사업자는 PRA를 명시적으로 비즈니스 계정으로 분류합니다.

공개된 PRA 페이지에는 신원과 SIM에 대한 별도 요건과 함께, 수납 한도가 거래당 및 일일 30 000 BDT, 월 500 000 BDT로 나와 있습니다. 이 숫자는 2026년 10월 12일에 확인한 바로 이 상품에 대한 것이며 bKash 전체를 설명하지 않습니다. 계약 전에 선택한 카테고리에 대한 현행 표를 받아야 합니다. 한 계정 유형의 한도를 다른 유형에 대한 약속으로 써서는 안 됩니다.

영업이 문서보다 앞서갈 때 Nagad에 물어볼 것

두 상품이 모두 모바일 지갑처럼 보인다는 이유만으로 bKash의 상태 값, refund API, 규칙을 Nagad에 그대로 옮겨서는 안 됩니다. 확인한 Nagad의 공개 한도 페이지에서는 숫자가 채워진 표를 얻지 못했습니다. 그래서 여기서는 일반적인 현행 한도를 일부러 제시하지 않습니다. 이는 확인 범위의 구체적인 한계이지, 한도가 없다는 주장이 아닙니다.

상업 제안을 받을 때는 공급자의 법인명, merchant 상품의 정확한 명칭, 수납 조건, 리포트 샘플, 방향별 한도, 최신 연동 문서를 요청하십시오. 애그리게이터를 쓴다면 누가 Nagad와의 계약 당사자인지, 잘못된 상태 값은 누가 책임지는지 확인하십시오. 데모 키나 비공식 라이브러리는 귀사 사업에 production 환경이 제공된다는 증거가 아닙니다.

공급자에게 유용한 테스트는 이렇습니다. 허용된 테스트 결제 한 건과 그 원래 reference, 수취인 기록, 정산 내역 한 줄을 보여 달라고 하십시오. 그다음 결제 전 취소와 결제 후 환불로 같은 절차를 반복합니다. 문서화된 답이 없으면 "보통은 됩니다"라는 약속으로 채우지 않습니다. 해당 경로는 출시 범위 밖에 둡니다.

계좌 정보와 증빙: 전화번호만으로는 부족하다

자체 원장에서는 주문 식별자, 결제 시도, 공급자, 거래 유형, 입금 계좌, BDT 금액, 시각, 금융 이벤트의 reference를 구분하는 것이 좋습니다. 증빙은 서비스를 제공하는 사업자나 은행 측의 확인입니다. 결제자의 스크린숏은 거래를 찾는 데 도움이 되지만, 그것만으로 상품 출고나 내부 잔액 증가를 일으켜서는 안 됩니다.

문서화된 게이트웨이 모델의 예로 SSLCOMMERZ가 있습니다. tran_id는 상점이 지정하고, val_id는 검증에 쓰이며, bank_tran_id는 은행 쪽 식별자입니다. VALIDATED는 성공한 거래를 다시 검증했다는 뜻이지 두 번째 결제가 아닙니다. Refund에는 자체 refund_trans_id와 refund_ref_id가 있으며, 요청이 성공적으로 생성되었다고 refunded 상태가 되는 것은 아닙니다. 이는 SSLCOMMERZ의 필드이지 bKash나 Nagad의 네이티브 사양이 아닙니다. 게이트웨이 문서.

구매자 두 명이 같은 1분 안에 같은 금액을 보냈다고 합시다. 시스템이 전화번호, 금액, 스크린숏만 저장한다면 매칭은 모호합니다. 올바른 설계는 사용 가능한 확인된 식별자, 부분 일치 규칙, 수동 검토 대기열을 미리 정해 둡니다. 운영자가 전환율을 높이려고 "가장 비슷한" 주문을 골라서는 안 됩니다.

은행은 큰 지갑이 아니라 또 하나의 층이다

Bangladesh Bank는 BEFTN, NPSB, RTGS를 구분합니다. BEFTN은 배치 교환, NPSB는 해당 거래의 은행 간 스위칭, RTGS는 정해진 운영 시간 안의 실시간 총액 결제와 관련됩니다. 모든 은행 결제에 같은 처리 기한을 약속할 수는 없습니다. 선택한 은행, 채널, 처리 일정, 해당 계좌 유형의 규칙이 필요합니다.

가맹점 정산과 관련해서는 MFS 결제가 어디서 끝나고 은행으로의 출금이 어디서 시작되는지 확인하십시오. 수납 수수료, 출금, 환불, 환전 가능성은 수익 구조에서 서로 다른 항목입니다. 구매자가 1 000 BDT를 냈는데 은행 입금액이 더 적다면, 이를 자동으로 미달 결제로 분류해서는 안 됩니다. 먼저 계약상 공제 항목을 확인하십시오. 반대 방향의 실수도 있습니다. 이미 반영한 결제들의 정산 배치가 들어왔을 때 전체 금액을 또 한 번 반영하는 것입니다.

금지된 사업은 이름을 바꿔도 가맹점 업무가 되지 않는다

bKash 공식 공지에는 도박과 온라인 베팅 참여 또는 운영이 금지 업종으로 명시되어 있습니다. 사업자는 서비스 중단과 법적 조치를 예고합니다. 따라서 그런 트래픽을 '일반 merchant'로 받겠다는 제안은 의뢰인의 해외 라이선스로 정당성을 얻지 못합니다.

이는 사고 관리에도 해당합니다. 거래 목적을 바꿔 적거나, 다른 사람의 계정으로 받거나, 개인 송금으로 전환하는 것은 계약 위반을 바로잡지 못합니다. 적법한 사업의 안정성은 합의된 상품, 검증된 수취인 체인, 리포트 접근, 멈춘 결제마다 분명한 책임자에서 나옵니다. 결제 화면의 로고 개수가 아니라 바로 이것들이 연동의 적합성을 결정합니다.