파키스탄 Raast, JazzCash, easypaisa: 송금과 가맹점 결제를 혼동하지 않는 법

"JazzCash로 결제됨"이라는 말만으로는 대사를 할 수 없습니다. JazzCash와 easypaisa, Raast 어느 경우든 구매자는 송금을 했을 수도, 가맹점 결제 게이트웨이로 결제했을 수도, 나중에 결제할 토큰을 받았을 수도 있습니다. 마찬가지로 Raast는 다른 사업자의 앱 안에서 등장할 수 있습니다. 휴대폰에 보이는 브랜드가 거래 유형을 뜻하지는 않으며, 결제 안내가 표시되었다고 돈이 들어온 것도 아닙니다.

파키스탄에서 적법한 가맹점을 서비스하는 팀이라면 기능별로 지도를 그리는 것이 유용합니다. 결제가 어디로 가는지, 누가 결과를 확인하는지, 자금이 어디에 있는지, 어떤 방식으로 환불되는지입니다. 여기서 Raast, JazzCash, easypaisa는 검증되지 않은 인기 순위가 아니라 실제로 이용 가능한 주요 시스템과 서비스로 다룹니다.

Raast ID와 merchant alias는 서로 다른 문제를 해결한다

SBP는 P2P용 Raast ID를 계좌에 연결된 휴대폰 번호로 설명합니다. 송금은 등록된 ID나 IBAN 앞으로 보낼 수 있으며, 보내는 쪽에 자신의 Raast ID가 있을 필요는 없습니다. 개인용 FAQ에는 하나의 ID가 하나의 계좌에 연결되며 연결 계좌를 변경할 수 있다고 나와 있습니다. 이 설명에서 레일 자체는 국내 송금용이며, 구체적인 한도는 은행에 확인해야 합니다.

실무적 결론은 이렇습니다. 전화번호를 은행 수취인을 증명하는 영구적인 증거로 저장해서는 안 됩니다. 결제 시도마다 수취인 확인 결과와 발급된 계좌 정보의 스냅숏이 필요합니다. 조직이 상품이나 서비스 대금을 받는다면, 가맹 심사 파일에 왜 바로 그 계좌 유형과 계약을 쓰는지 분명히 드러나야 합니다. 직원 개인의 alias가 POS에 연동되었다고 해서 가맹점 인프라가 되지는 않습니다.

Raast P2M은 QR, merchant alias, IBAN, 그리고 즉시 또는 지정 기한 결제가 가능한 Request to Pay를 지원합니다. SBP는 가맹 시 사업자 확인과, 가맹점이 수락하거나 거절하는 환불 요청을 처리할 수 있는 기능을 요구합니다. 승인이나 거절에 대한 실시간 알림도 규정되어 있습니다. 이는 참여 기관에 대한 요건일 뿐, 어느 은행이든 이미 귀사에 모든 기능을 제공했다는 증거는 아닙니다. P2M 관련 회람.

Request to Pay는 결제 제안이지 출금이 아니다

결제 시스템 안에서 요청 생성, 결제자의 동의, 금융 결과를 분리하십시오. 자체 기록용으로는 order ID, attempt ID, 사업자 측 요청 식별자, 유효 기간, 예상 금액, 수취인, 최종 transaction reference가 유용합니다. 이는 권장 데이터 모델이며, 구체적인 API 필드명은 이 글이 아니라 귀사의 MSP가 정합니다.

연습 사례: 고객이 Later 요청을 열었다가 직접 IBAN으로 송금했습니다. 프로세싱이 두 경로를 계속 별개의 주문으로 간주하면 이중 결제와 이중 출고가 생길 수 있습니다. 한 주문에 대한 대체 결제 시도를 매칭하는 정책이 필요합니다. 확인된 초과 결제는 별도로 처리하며, 고객의 다음 주문에 슬쩍 녹이거나 채팅에 나온 아무 수취인에게 보내지 않습니다.

JazzCash: 필드의 정확한 의미를 지킬 것

공개된 게이트웨이 문서에서 pp_TxnRefNo는 가맹점이 지정하고, pp_Amount는 정해진 금액 단위로 소수점 구분자 없이 전달하며, pp_TxnCurrency에는 PKR이 들어갑니다. 거래 기한과 pp_SecureHash도 사용됩니다. 환불은 reference를 통해 원거래와 연결됩니다. 이는 공개된 특정 버전의 인터페이스이므로, 운영 환경에 올리기 전에 서명과 상태 순서를 포함해 귀사가 받은 사양과 대조해야 합니다.

특히 금액 단위 오류는 비용이 큽니다. 100 PKR 테스트는 구매자 화면만이 아니라 요청, 응답, 리포트, 은행 거래 내역까지 확인해야 합니다. 한 형식의 숫자를 검증 없이 다른 형식으로 복사하면 100배 차이가 날 수 있습니다. 금액은 내부적으로 모호하지 않은 형식으로 저장하고, 연동 경계에서 변환하며, API 버전마다 별도의 테스트를 두십시오.

JazzCash는 가맹 안내에서 서류 확인, 생체 인증, 계약 체결, 사업자 명의 등록을 명시하고, 자격 요건으로 CNIC와 NTN을 듭니다. 소비자용 지갑이 있다고 이 단계들이 생략되지는 않습니다. 게이트웨이에서 쓸 수 있는 결제 수단에는 모바일 계정, 카드, 바우처가 포함되므로, JazzCash라는 이름만으로는 구매 대금의 자금 원천이 정해지지 않습니다.

easypaisa: 토큰은 확인된 결제가 아니다

easypaisa 가맹점 FAQ에는 게이트웨이 결제 수단으로 Mobile Account와 OTC가 나와 있습니다. OTC는 지정된 매장과 은행 채널에서 결제하는 토큰입니다. 운영팀에게는 '토큰 결제 대기'라는 별도 상태를 유지하는 것이 핵심입니다. 토큰이 생성되었을 때 입금 처리해서는 안 됩니다. 대기 기한, 재결제 가능 여부, 최종 상태는 현재 유효한 사양에서 확인해야 합니다.

easypaisa의 retailer에서 merchant로 전환하는 조건에는 은행과의 계약, 적법한 상품과 서비스에만 사용, 부여되는 한도, 정정 출금 가능성이 따로 명시되어 있습니다. "지갑에 받았으니 아무도 못 건드린다"는 약속에 대한 좋은 반례입니다. 이 문서를 근거로 모든 거래를 무조건 취소 불가로 선언하거나 에이전트 권한을 가맹점 수납으로 옮길 수는 없습니다.

진짜 운영 부담이 생기는 곳

파일럿에는 성공 결제만 넣어서는 안 됩니다. 요청을 미결제 상태로 두고, 인증 후 브라우저를 닫고, 중복 알림을 확인하고, 타임아웃 후 상태를 조회하고, 합의된 환불을 실행해 보십시오. 테스트마다 최종 확인 권한이 누구에게 있는지, 운영자가 야간에 어떻게 그 확인을 받는지 기록하십시오. 지원팀이 고객의 SMS만 볼 수 있다면 프로세스의 신뢰성은 아직 입증되지 않은 것입니다.

가맹점 정산은 고객 결제와 따로 대사하십시오. 계약서에는 수수료, 보류금, 가용 잔액, 입금 받을 은행 계좌, 주말 이후의 지급 일정이 설명되어 있어야 합니다. 수납 설명에 있는 'Real-time'이 모든 출금의 가용성이 같다는 약속은 아닙니다. 원거래에 대한 환불과 새로운 지급 송금 역시 서로 다른 근거와 식별자가 필요합니다.

결제 서비스 라이선스는 도박 라이선스가 아니다

Pakistan Code에는 도박 방지에 관한 특별법이 있습니다. 따라서 해외 gambling 라이선스나 규제 대상 지갑과의 연동이 파키스탄에서 그러한 사업이 허용된다는 근거가 되지 않습니다. 이 기술적 수단에 대한 분석은 규제를 우회하는 경로가 아닙니다. 상업적 출시 전에 적용 가능한 현지 사업 근거와, 서비스 기관의 해당 업종에 대한 명시적 승인이 필요합니다.

좋은 연동은 검증 가능한 세부 사항을 담은 한 문장으로 설명할 수 있습니다. 누가, 누구에게, 어떤 상품에서, 어떤 근거로 결제하며, 어떤 메시지로 결과가 확인되는지입니다. 그 대신 "현지 파트너가 다 해결해 준다"는 말만 남는다면 리스크는 사라진 것이 아니라 가맹점에게 숨겨진 것입니다.