IOSOR 가이드

DLR 상태 웹훅과 선불 보류 금액의 상관관계

IOSOR CPaaS 인프라에서 수신된 전달 확인 콜백과 선불 보류 자금을 조정하여 예약된 원장 금액을 해제하는 방법을 알아보세요.

IOSOR를 통해 OTP SMS를 발송할 때 선불 보류 금액인 USD 차감이 실시간으로 발생합니다. 발송 시스템에서 수신되는 DLR webhook 데이터를 해당 보류 건과 정확히 매칭하지 못하면 원장이 맞지 않거나 자금이 불필요하게 묶이는 문제가 생깁니다. 10DLC 환경에서도 자금 고립을 방지하려면 API 기반의 JIT 정산 흐름을 구현하여 최종 배달 상태에 따라 보류금을 정식 차감하거나 즉시 환불해야 합니다. 이를 통해 정확한 ledger 잔액을 유지할 수 있습니다.

선불 보류 메커니즘 이해

IOSOR 생태계에서 모든 발신 SMS 요청은 즉시(Just-In-Time) 원장 확인을 트리거합니다. 요청이 시작되면 시스템은 메시지 전달에 충분한 자금이 있는지 확인하기 위해 계정 잔액을 일시적으로 보류합니다. 이 보류는 최종 차감이 아니라 자본의 예약입니다. 최종 정산은 네트워크로부터 DLR(전달 확인) 상태를 수신한 후에만 이루어지며, 이를 통해 재무 원장이 메시징 크레딧의 실제 소비량을 정확하게 반영하도록 합니다.

DLR 콜백의 수명 주기

메시지가 발송되면 네트워크는 DLR 상태를 반환합니다. 웹훅 엔드포인트는 고유 메시지 ID와 최종 상태 코드가 포함된 이 페이로드를 수신합니다. IOSOR 엔진은 이 ID를 원래 트랜잭션 기록과 연결합니다. 상태가 성공적인 전달을 나타내면 시스템은 보류 금액을 영구적인 차감으로 변환합니다. 상태가 실패를 나타내면 보류가 해제되어 사용 가능한 잔액으로 돌아가며, 성공한 시도에 대해서만 비용을 지불하게 됩니다.

원장 조정 관리

조정은 자동화되어 있지만, 개발자는 발송과 DLR 도착 사이의 지연 시간을 모니터링해야 합니다. DLR이 지연되면 보류 상태가 유지되어 사용 가능한 크레딧이 일시적으로 줄어들 수 있습니다. USD 20의 선불 최저 잔액을 유지하는 계정의 경우 서비스 중단을 방지하는 것이 중요합니다. 월간 볼륨이 USD 1,000/월을 초과하면 시스템은 크레딧 한도를 조정하고 고주파 트래픽에 대한 원활한 처리량을 보장하기 위해 소프트 검토를 트리거합니다.

에지 케이스 및 타임아웃 처리

모든 메시지가 예상 시간 내에 DLR을 수신하는 것은 아닙니다. 네트워크가 상태 업데이트를 제공하지 못하는 경우, IOSOR 시스템은 정의된 TTL(Time-To-Live) 이후에 오래된 보류를 해제하는 정리 작업을 수행합니다. 이는 '유령' 보류가 유동성에 영향을 주는 것을 방지합니다. 원장과 내부 회계 기록 간의 동기화를 유지하기 위해 웹훅 핸들러가 500ms 이내에 DLR 수신을 확인하도록 하십시오.

필수 통합 리소스

구현이 강력하고 재무적 무결성에 대한 모범 사례를 따르도록 하려면 다음 가이드를 참조하십시오:

IOSOR로 시작하기

연동을 완료하려면 IOSOR 콘솔로 이동하여 웹훅 설정에서 원장 정산 엔드포인트를 구성하십시오. 수신기가 dlr.status 페이로드를 처리하고 이를 해당하는 거래 보류 ID에 직접 매핑할 준비가 되었는지 확인합니다. 샌드박스 환경에서 이 상관관계를 테스트하면 원장 불일치 없이 예약된 자금이 즉시 해제되거나 차감됩니다.

IOSOR 핵심 요약

이 가이드에서는 실시간 메시지 전송 상태와 재무 원장의 정확성 간의 격차를 안전하게 해소하는 구체적인 방법을 살펴보았습니다. 수신되는 DLR(전송 보고서) 콜백을 활성 선불 보류(Prepaid Hold) 데이터와 정확하게 상호 연관시킴으로써 플랫폼 내의 불필요한 자금 잠김 현상을 방지하고, 가용 잔액이 최악의 가정이 아닌 실제 전송 상태를 실시간으로 반영하도록 보장할 수 있습니다.

운영자는 중복 수신되는 DLR 웹훅이 다중 원장 조정을 트리거하여 잔액이 이중으로 차감되거나 환불되지 않도록 웹훅 핸들러를 엄격하게 멱등성(Idempotency)이 보장되도록 설계해야 합니다. 또한, 즉각적인 콜백 수신에만 의존해서는 안 되며, 통신사 네트워크 장애나 지연으로 인해 전송 영수증이 반환되지 않는 예외적인 상황을 대비하여, 일정 시간이 지나면 오래된 보류 상태를 자동으로 해제하고 원장을 정리하는 대체 TTL(Time-To-Live) 만료 메커니즘을 반드시 구현해야 합니다.

이 가이드가 도움이 되었나요?