최종 사용자 전송은 여전히 단일 선불 원장에서 차감됩니다

임베디드 메시징은 최종 사용자에게 무료처럼 느껴집니다. SaaS UI 내부에서 전송을 누르면 녹색 체크 표시가 나타납니다. 그러나 내부적으로는 모든 성공적인 제출이 여전히 ISV가 소유한 단일 선불 원장을 차감합니다. 제품에 API가 포함되었다고해서 두 번째 지갑이 생성되지 않습니다. ISV가 보류 자금을 충당하지 않으면 전송은 가짜 전달 완료 상태가 아닌 정직한 제품 오류로 실패해야 합니다.

가상의 회계 처리 방식은 대표적인 장애 유형입니다. IOSOR 지갑으로 뒷받침되지 않는 앱 내 크레딧 미터, 선불 원장이 소진되는 동안 수행되는 SaaS 환불, 단일 OTP에 대해 이중 차감을 발생시키는 멱등성 없는 재시도 등이 이에 해당합니다. 임베디드 방식은 콘솔을 숨기지만 자금을 부담하는 주체는 여전히 ISV입니다.

아키텍처 기본 원칙: 최종 사용자 전송 ≡ ISV 선불 차감. 모든 설계 검토는 이 지점에서 시작해야 합니다.

UI에 제품 크레딧이 표시되더라도 원장은 하나뿐입니다

테넌트에 판매되는 메시지 팩은 ISV의 상업적 레이어입니다. 이는 ISV가 자금을 지원하는 단일 IOSOR 지갑의 선불 보류 및 차감 항목에 정확히 매핑되어야 합니다. 원장 기록과 일치하지 않는 테넌트 잔액은 지원 팀에 기술 부채로 남아 부담을 줍니다. 재무팀이 제품과 동일한 소진 현황을 확인할 수 있도록 매주 테넌트 사용량을 지갑 내역과 비교하여 내보내세요.

파트너 격리가 명시적 계약 조건이 아닌 이상 테넌트별로 두 번째 IOSOR 계정을 개설하지 마세요. 임베디드 파일럿 프로젝트는 대부분 내부 공정 공유 한도가 설정된 단일 ISV 계정에서 운영됩니다.

임베디드 경로에서도 보류와 멱등성은 여전히 적용됩니다

서버 측 전송은 OTP 및 트랜잭션 SMS에 대해 멱등성 키를 사용해야 합니다. SaaS UI에서의 더블 클릭으로 인해 단일 사용자 작업에 대해 두 번의 차감이 발생해서는 안 됩니다. 타임아웃 이후의 재시도는 최종 DLR(전달 보고서)이나 매핑된 실패가 반환될 때까지 동일한 키를 추적해야 합니다.

지갑에서 보류 처리를 진행할 수 없는 경우 제품 자체의 잔액 부족 또는 전송 일시 중단 상태를 반환하세요. 보류 처리가 실패했을 때 성공을 의미하는 HTTP 200을 절대로 반환해서는 안 됩니다.

제품 오류를 원장 진실에 매핑

지원 팀에 중앙 열에 대한 운영 교육을 진행하세요. 원장 기록이 없는데 UI에 녹색 성공 표시가 나타나는 티켓은 파일럿 기간의 귀중한 시간을 waste합니다.

채널 인수인계는 동일한 지갑에 유지됩니다

향후 제품에 SMS 외에 이메일이나 음성이 추가되더라도 재무팀의 승인을 받아 두 번째 채널 인수인계를 진행하지 않는 한 비용은 동일한 선불 원장에서 차감됩니다. 임베디드 방식이 무료 사이드 채널을 생성하지 않습니다. SaaS 설정에서 다른 라이브 타일을 활성화하기 전에 지갑 인접성 문서를 읽어보세요.

관련 운영 경로

• 지갑의 두 번째 채널: 지출 인수인계
• 멱등, 재시도와 자금
• 멀티테넌트 계정 전반에 걸친 속도 제한의 안전한 적용

IOSOR로 시작하기

IOSOR 콘솔을 열고 테넌트 크레딧 시스템을 기본 선불 지갑 원장에 직접 매핑하십시오. 마스터 지갑에 보류를 설정하기 전에 모든 서버 측 임베드 요청이 결정론적 멱등성 키를 통과하도록 하십시오. 인바운드 DLR을 처리하도록 웹훅 엔드포인트를 구성하여 열린 보류가 최종 원장 차감 또는 해제로 깔끔하게 해결되도록 하십시오.

IOSOR 핵심 요약

임베디드 SaaS 인터페이스는 최종 사용자에게 사용자 지정 메시지 크레딧을 표시할 수 있지만, 모든 실제 발송은 ISV가 자금을 지원하는 단일 선불 원장에 바인딩됩니다. 재시도, 채널 확장 및 사용자 상태 신호는 백엔드가 없는 UI 추상화가 아니라 지갑 보류에 대해 직접 대조되어야 합니다.

엄격한 서버 측 멱등성 키를 적용하고 모든 테넌트 UI 상태를 실제 원장 DLR 응답에 매핑하십시오. 백엔드가 없는 보조 지갑을 임의로 만들거나 테넌트 UI 재시도가 구체적인 원장 보류 없이 실행되도록 허용하지 마십시오.