첫 차감 전 선불 금액 예약

첫 과금 단위가 처리되기 전 최초 자금 이벤트를 명확히 설정해야 합니다. 선불 hold는 승인된 금액을 예약하는 과정이며, 요청이 완료되어 ledger에 정산될 때 비로소 실제 debit이 기록됩니다. IOSOR 환경의 JIT 경로를 통해 견적 확인 후 prepaid hold를 먼저 실행하면, 성공이나 실패 및 timeout 상황에서도 제품과 재무 흐름을 완벽히 일치시킬 수 있습니다. 이러한 구조는 10DLC 및 SMS 전송 시 발생하는 잔액 문제를 방지합니다.

선불 예약이 의미하는 것

예약은 완료되지 않은 intent를 위해 돈을 잠시 분리하는 것이며, 서비스가 끝난 것처럼 보이지 않습니다. 돈의 금액, 통화, intent ID, 생성 시간, 만료 시기, 예약·완료·해제 상태가 필수 정보입니다. 만료 시기는 단순한 장식용 필드가 아닙니다. 결과 불명 상태를 언제 조사하며, 언제 안전하게 돈을 되돌릴지 판단하는 기준을 정리해야 합니다.

상태 전환은 원자적이어야 합니다. 예약 생성 실패 시 고아 예약을 남기지 않도록 처리하고, 두 프로세스가 같은 금액을 동시에 해제하거나 정산해서는 안 됩니다. 각 변경 과정에 이유와 처리자가 명시되면, 지원팀이 내부 대화를 뒤지지 않고 상태를 이해할 수 있습니다.

예약액과 사용 가능 잔액 구분

"잔액"이라는 단어 하나로는 동시성 위험을 숨기지 말고, 전체, 예약, 사용 가능 금액을 명확히 표시해야 합니다. 예를 들어, 총 USD 50 중 USD 12가 예약 상태라면, 새 작업은 USD 38 만큼 사용 가능합니다. 병렬 요청이 같은 자금을 약속하면 안 되므로, 예약과 이후 debit은 하나의 correlation ID를 공유해야 합니다.

각 서비스의 예약 계산 방식이 다르게 설계됩니다. 메시지 배치 요청은 retrial을 포함한 제한 예산을 예약 가능하며, JIT 번호 요청은 구매 완료 및 번호 배정 완료 후에 최초 견적액을 잡을 수 있습니다. 일반 원칙은 활성화된 예약을 사용 가능 잔액에서 제외하는 것입니다. 잔액 확인과 예약 변경이 같은 트랜잭션 경계 내에 이루어지지 않으면, 병렬 요청이 오래된 잔액을 기반으로 승인되어 예산 낭비로 이어질 수 있습니다.

예약된 자금의 수량, 가장 오래된 예약 잔여 시간, 곧 만료 예정인 금액을 모니터링해야 합니다. 총액이 충분해 보여도 멈춘 intent가 자금을 묶고 있을 수 있으므로, 사용 가능 잔액이 부족할 때 신호를 발송 중지하도록 검증해야 합니다. 제품 상태 없이 오래된 intent가 발생하면 자동 retry를 중단하고, 증거를 조사하여 문서화된 기준에 따라 해제하거나 오류 처리합니다.

첫 차감은 실제 결과와 일치해야 함

정산 근거는 클릭이나 큐 진입이 아닌 관찰 가능한 결과입니다. 수락된 발송 intent, 배정된 번호, 또는 사전에 정의된 과금 가능한 이벤트만 기준으로 합니다. 최종 금액이 예약액보다 낮다면 실제 금액만 정산하고 차액은 즉시 해제되야 합니다. 승인 범위를 침해하지 않도록 주의해야 하며, 상한 금액이 바뀌면 다시 견적서와 승인을 받아야 합니다.

지갑 등록 데이터는 제품 이벤트와 연결된 intent ID, 서비스명, 금액, 통화, 시간, 최종 상태를 반드시 포함해야 합니다. 같은 알림이 두 번 도착하더라도 처리기는 기존 자금 결과만 반환해야 합니다. 멱등, 재시도 및 자금 관리 체계는 이후 보완이 아닌 지갑 설계 기준입니다.

이중화 장치는 두 방향으로 모두 가능해야 합니다. 제품 상태에 기반한 예약 확인과, 예약 상태에 기반한 완료 증거 검증이 가능해야 합니다. 메시지 배치가 부분적으로 완료되면 완료된 단위만 정산하고 나머지는 해제되며, 동일한 export에서 차이를 명확히 해야 합니다. 연결된 증거가 없는 장부 행은 재무 마감 과정에서 사용 불가능합니다.

차감 전에 실패한 경우

결과 결정 전 실패는 명확한 해제 또는 환불 프로세스로 끝나야 합니다. 완료 증거가 없는 JIT intent의 경우, 만료 타이밍에 따라 예약 상태를 해제해야 합니다. 작업이 완료되었지만 결과 배정이 불가능한 경우, 시각적인 운영 상태와 제한된 해결 과정이 필요합니다. 번호 관리에 관련된 실패 시 환불 및 교체 시스템은 DID 주문 실패 환불과 교체를 참조하세요.

• 작업 전 검증 거절: 자금 차감 없음
• 중복 요청: 기존 intent 조건 반환
• 예약 중 작업 실패: 예약 금액 전체 해제
• 부분 완료 배치: 완료분만 정산, 미사용분 되돌리기
• 결과 불명: 작업 재시도 중단, 두 번째 차감 차단 후 조사

해제와 환불은 구분된 개념입니다. 해제는 현재 정산되지 않은 예약 금액을 반환하는 것이고, 환불은 이미 기록된 자금 변경을 반전하는 처리입니다. 두 프로세스 모두 시간, 원인, 작업 참조가 있으며, 수동 수정으로 잔액을 덮어쓰는 대신 관리 가능한 장부 항목을 별도로 추가해야 합니다.

구매 팀 확인 목록

1. 장부 데이터에서 예약, 사용 가능, 정산 상태를 분리하여 저장하고 있는가?
2. 모든 예약에 만료 타이밍과 하나의 intent ID가 포함되어 있는가?
3. 채널별 결과 증거사항이 명확한 이름으로 레이블이 붙어 있는가?
4. 비밀번호, 비밀번호로 보호된 상태에서는 예약 정보를 검사할 수 있는가?
5. 중복 요청 발생 시 기존 자금 결과를 재사용하고 있는가?
6. 예약 만료 전 잔액 부족 시 발송 중지 처리가 가능한가? 잔액 부족 시 자금 제어 절차를 따르고 있는가?

예약 결정이 책임 있는 사람에 의해 이루어지고 있는지, 자동 정산 시스템에 예외가 허용 가능한지 확인해야 합니다. 만료 알림이 예약 관리 담당자에게 먼저 도착하는지 검증합니다. 관련 사항이 챗봇 영역에만 놓여 있다면, 이 경로는 실제 운영이 아닌 시범단계입니다.

IOSOR로 시작하기

대규모 과금 요청 전에 IOSOR 콘솔에서 선불 예약의 만료 기준과 동의 처리 여부를 반드시 확인하세요. 모든 작업 단계에서 자금 분할 시스템을 테스트하고, 예약 승인 여부를 운영팀과 협의하며 재정적 위험을 줄이는 것이 중요합니다.

IOSOR 핵심 요약

선불 금액 예약 시스템은 실제 차감 이벤트가 발생하기 전까지 자금을 안전하게 격리하여 경쟁 상태나 중복 결제 오류를 방지하는 핵심적인 장치입니다. 이 과정에서 예약된 금액은 가용 잔액에서 즉시 분리되지만, 아직 확정된 매출로 인식되지 않으므로 미청구 활동이 완료된 수익으로 오인되는 재무적 왜곡을 차단합니다. 운영자는 모든 승인 예약 건을 고유한 비즈니스 의도 ID와 반드시 결합해야 하며, 만약 서비스 배송이나 자원 할당이 실패할 경우 예약된 자금을 자동으로 해제하여 고객의 가용 잔액으로 복구하는 로직을 콘솔 내에서 구현해야 합니다. 결제 원장 관리 시 최종 정산 금액이 예약된 범위를 임의로 초과하지 않도록 엄격한 검증 절차를 유지하십시오. 또한 관측 가능한 완료 증거 없이 차감을 확정하지 않는 것이 데이터 무결성 유지의 핵심입니다. 시스템 게이트와 재무 팀은 이러한 격리된 예약 구조를 통해 실시간으로 계정의 지급 능력을 정확하게 파악하고 감사에 대비할 수 있는 투명한 뷰를 확보하게 됩니다. 예약 자금은 등록 단계에서 실제 차감 전까지 가장 안전한 방식입니다. 예약 상태는 강제 반환 시스템을 통해 프로세스 상의 불확실성을 제거하는 반면, 성공 시 선불 금액이 이동합니다. 여기서 가장 핵심은 모든 이벤트에서 자금 계산이 사건 전후로 일관되며, 동일한 알림이 반복되더라도 실행자는 기존 자금 상태를 반영해야 합니다. 예약 기준이 명확하지 않거나, 환불 전 과정이 무해하게 운용된다면 이 경로는 재무 품질 질문에 해당합니다. 이 절차는 장기적 지갑 운영에 발전 조건을 제공합니다.