인도네시아: QRIS, BI-FAST, 지갑은 결제의 서로 다른 계층에 있다

결제수단 목록에는 QRIS, BI-FAST, GoPay, 계좌이체가 나란히 놓이는 경우가 많습니다. 하지만 인도네시아 QRIS 결제를 이해하려면 이것들이 대등한 지갑 네 개가 아니라는 점부터 알아야 합니다. QRIS는 QR 결제를 표준화하고, BI-FAST는 결제 인프라이며, 지갑 앱은 인터페이스이자 자금 원천일 수 있습니다. 이렇게 구분하지 않으면 프로세싱은 하나의 사용자 경로를 여러 독립 결제수단으로 잘못 세고, 서로 다른 계약이 적용되는 곳에 같은 규칙을 약속하게 됩니다.

가맹점에게 올바른 구조는 질문에서 시작합니다. QR은 누가 발행했는가, 어떤 앱이 그것을 사용했는가, 누가 결제를 수납했는가, 그리고 수취 측에서 그 결제를 확인해 주는 메시지는 무엇인가? 다음 질문은 매출이 언제 필요한 은행 계좌에서 쓸 수 있게 되는가입니다. QR 스탠드 사진으로는 이 질문에 답할 수 없습니다.

QRIS가 표준화하는 것과 결제 사업자에게 남는 것

Bank Indonesia는 merchant-presented 모델과 customer-presented 모델을 설명합니다. 정적 merchant QR에서는 보통 구매자가 금액을 입력하고, 동적 QR에서는 가맹점이 금액을 미리 정합니다. 연동은 허가받은 PJP를 통해 심사와 merchant ID 발급을 거쳐 이루어집니다. 확인한 페이지에는 건당 한도 1,000만 IDR이 명시되어 있으며, 발급사가 누적 한도를 따로 정할 수 있습니다. 이는 특정 상품의 경계이지, 모든 구매가 승인된다는 보장이 아닙니다.

동적 QR의 장점은 안내의 모호함을 줄인다는 점입니다. 하지만 "동적"이라는 것만으로 주문별 고유 은행 기록, 자동 환불, 24시간 내보내기가 약속되지는 않습니다. 결제 사업자에게 생성된 거래의 어떤 식별자가 승인, 리포트, 고객 지원 문의에 돌아오는지 보여 달라고 하십시오. 이 세 곳 사이에서 연결이 끊긴다면 자체 예외 처리 큐가 필요합니다.

결제 화면에서는 선택된 결제수단과 실제로 사용된 자금 원천을 따로 저장하십시오. 지갑 앱으로 결제했다고 해서 가맹점이 같은 앱에 별도 지갑을 운영해야 한다는 뜻은 아닙니다. 반대로 소비자에게 익숙한 브랜드가 있다고 해서 그 계정에서 모든 QR, 잔액, 해외 결제 시나리오를 쓸 수 있다는 뜻도 아닙니다. 확인할 대상은 구체적인 경로와 그 참여자입니다.

문서화된 예: QR은 생성되었지만 돈은 아직 들어오지 않았다

Midtrans QRIS API에서 생성 응답에는 order_id, transaction_id, merchant_id, gross_amount, currency, transaction_status가 들어 있습니다. pending은 결제 대기를 뜻하며, 문서는 이후의 settlement와 expire를 보여줍니다. issuer와 acquirer 필드는 당사자를 구분하고, transaction_type은 on-us와 off-us를 구분합니다. 이는 Midtrans의 용어 체계이며 모든 PJP의 공통 API로 선언해서는 안 됩니다. QRIS 규격.

자체 회계의 권장 로직은 이렇습니다. 생성된 안내에는 한 상태, 확인된 결제에는 다른 상태, 사업자에 대한 정산에는 세 번째 상태를 부여합니다. 원래의 transaction_status는 내부 상태 옆에 함께 저장해, 고객 지원이 불일치를 설명할 수 있게 합니다. 중복 알림 처리기는 기존 이벤트를 찾아야 하며 매출을 하나 더 만들어서는 안 됩니다. 브라우저 redirect는 구매자 화면용으로 쓰고, 금융 기록의 유일한 근거로 삼지 않습니다.

Midtrans에는 현재 상태를 조회하는 별도 요청이 있습니다. POS 가이드에는 Gojek 안에서 실패한 시도가 최종 거절로 가맹점에 전송되지 않는 상황이 설명되어 있습니다. 거래는 pending으로 남아, 만료 전까지 다시 결제할 수 있습니다. 같은 가이드에서 POS용 온라인 환불은 기본으로 제공되지 않으며 별도 협의가 필요합니다. 고객에게 "완전 자동 결제 단말"을 팔기 전에 바로 이런 제약을 읽어야 합니다.

settlement라는 단어가 오해를 부르는 이유

PG 문서에서 settlement는 해당 모델에서 고객 결제가 성공으로 확인되었다는 뜻일 수 있습니다. 그래도 재무팀에는 별도의 답이 필요합니다. 그것이 출금 가능한 자금이고 사업자 은행 계좌로의 입금이 완료되었다는 뜻인가? 상태 이름이 정산 계약을 대신하지는 않습니다. 내부 필드는 비즈니스 의미대로 이름을 붙이고, provider status는 이름을 바꾸지 않고 저장하는 것이 좋습니다.

학습용 예시입니다. 하루 동안 총 500만 IDR의 구매 100건이 확인되었습니다. 다음 날 합의된 차감액을 뺀 은행 송금 한 건이 들어옵니다. 이 송금은 결제 사업자가 가맹점에 지고 있던 의무를 정리하는 것이지, 새 결제 100건을 만드는 것이 아닙니다. 대사는 배치, 구성 내역, gross, 수수료, 환불, net을 연결해야 하며, 차이를 "지갑 오차"로 자동 처리해서는 안 됩니다.

BI-FAST: 고유한 기능을 가진 별도 인프라

Bank Indonesia FAQ는 계좌 또는 전화번호나 이메일 같은 proxy로 수취인을 지정하는 방식을 설명합니다. proxy 하나는 계좌 하나에 연결됩니다. 건당 최대 금액은 2억 5,000만 IDR이며, 참여 기관이 더 낮은 한도를 둘 수 있습니다. individual credit transfer 외에 단계적으로 도입되는 bulk credit transfer, request for payment, direct debit도 나열되어 있습니다. 시스템에 기능이 있다고 해서 특정 거래 은행에서 그 기능을 쓸 수 있다는 것이 확인되지는 않습니다.

가맹점 입장에서는 수납, 지급, 일괄 거래, 결제 요청, 환불을 담은 별도의 기능 지도가 필요하다는 뜻입니다. 출금 송금만 연결해 놓고 수납 문제를 해결했다고 볼 수 없고, 모든 QRIS 거래가 반드시 BI-FAST를 거친다고 가정해서도 안 됩니다. 입금 정보, 리포트, 고객 지원 문의는 발표 자료 속 보기 좋은 일반 아키텍처가 아니라 실제로 합의된 구조에 맞아야 합니다.

한도와 환불은 전체 사이클로 점검한다

런칭 전에 허용 금액 범위, QR 유효기간, 만료 시 동작, 상태 조회 방식을 확인하십시오. 환불에는 확인된 원결제, 허용 금액, 합의된 채널이 필요합니다. API가 해당 상품의 환불을 지원하지 않는다고 해서 채팅에 적힌 아무 번호로 돈을 보내도 된다는 뜻은 아닙니다. 공식 절차, 기한, 책임자, 완료 증빙을 문서로 정합니다.

부하 테스트에서는 성공률만 재지 마십시오. 최종 응답이 없는 거래 수, 주문과의 연결을 복구하는 데 걸린 시간, 아직 가맹점에 지급되지 않은 매출 잔액을 세십시오. 이 지표가 깔끔한 성공 시나리오의 평균 처리 시간보다 실제 운영 비용을 더 잘 보여줍니다.

게임 트래픽: 국가 QR이 금지를 풀어 주지는 않는다

인도네시아 당국은 온라인 도박과 연결된 은행 계좌를 차단하고 그 자금 흐름을 막고 있다고 공식적으로 밝히고 있습니다. 따라서 QRIS나 BI-FAST에 접근할 수 있다는 것을 허용된 현지 gambling 매입처럼 내세워서는 안 됩니다. 서비스는 합법적이고 합의된 활동에만 허용되며, 가맹점을 다른 업종으로 위장해도 거래의 법적 지위는 바뀌지 않습니다.

운영사를 위한 결론입니다. 로고가 아니라 참여자의 검증 가능한 의무를 비교하십시오. merchant ID는 누구에게 있는가, 승인은 누가 보내는가, 결제 후 돈을 갚아야 하는 쪽은 누구인가, 환불은 누가 완료하는가? 이 질문에 계약상·기술상 답이 있다면 그 결제수단을 가격과 편의성으로 평가할 수 있습니다. 답이 없다면 낮은 수수료는 불완전한 제안으로 남습니다.