IOSOR

IOSOR Знания

Изпращането от крайния потребител все така таксува един предплатен регистър

Вграденото изпращане продължава да дебитира предплатения портфейл на ISV. Не измисляйте втори регистър, който продуктът не финансира.

Вградените съобщения изглеждат безплатни за крайния потребител: той натиска Изпрати в интерфейса на SaaS и вижда зелена отметка. Под повърхността всяко успешно изпращане все така засяга един предплатен главен регистър, притежаван от ISV. Не се появява втори портфейл само защото продуктът е вградил API. Ако ISV не финансира задържанията, изпращането трябва да се провали с честна грешка в продукта — а не с фалшив статус за доставено съобщение.

Фиктивното счетоводство е режимът на грешка: вътрешен брояч на кредити в приложението, неподкрепен от портфейла на IOSOR, възстановяване на суми в SaaS, докато регистърът изгаря, или повторения без идемпотентност, които таксуват двойно един OTP. Вграждането крие конзолата; ISV остава финансиращата страна.

Архитектурна линия: изпращане от краен потребител ≡ ISV предплатен дебит. Всяка преглед на дизайна започва оттук.

Един главен счетоводен регистър, дори когато UI показва кредити за продукти

Пакетите със съобщения, продавани на клиенти, са търговски слой на ISV. Те трябва да се картографират към предплатени задържания и дебити в единствения портфейл на IOSOR, който ISV финансира. Баланс на клиент, който никога не се равнява с редовете в регистъра, е бомба със закъснител за поддръжката.

Задържанията и идемпотентността все още важат за вградените пътища

Изпращането от страна на сървъра трябва да използва ключове за идемпотентност за OTP и транзакции SMS. Двойно щракване в интерфейса на SaaS не трябва да създава два дебита за едно действие на потребителя. Повторенията след изтичане на времето следват същия ключ до краен DLR или картографирана грешка.

Картографирайте грешките на продукта към истината в регистъра

Сигнал в SaaS UI Истина в регистъра Допустима следваща стъпка
Изпратено / доставено Дебит + DLR път съществува Показване на ID на разписка
В опашка Задържането е отворено или прието Зап.

Предаванията на канали остават в същия портфейл

Ако продуктът по-късно добави имейл или глас до SMS, разходите все пак се записват в същия регистър, освен ако не извършите предаване на втори канал с одобрението на финансовия екип. Вграждането не създава безплатен страничен канал. Прочетете за близостта на портфейла, преди да включите друг Live панел в настройките на SaaS.

Свързани оперативни пътища

Започнете с IOSOR

Отворете конзолата на IOSOR и свържете кредитирането на вашия наемател директно към основната главна книга на предплатения портфейл. Уверете се, че всяка заявка за вграждане от страна на сървъра подава детерминиран ключ за идемпотентност преди задържане на сума по мастър портфейла. Конфигурирайте уебхук точката си за обработка на входящи DLR съобщения, така че отворените задържания да се финализират чисто като окончателни дебити или освобождавания.

Обобщение IOSOR

Вграденият софтуерен интерфейс може да показва персонализирани съобщения и кредити на крайните потребители, но всяко реално изпращане обвързва средствата единствено към общия предплатен портфейл, осигурен от независимия софтуерен доставчик. Опитите за повторно изпращане, разширенията на каналите и състоянието на потребителя трябва да се съгласуват пряко със задържаните суми в портфейла, вместо с невзаимозаменяеми абстракции в потребителския интерфейс.

Задължително прилагайте стриктни ключове за идемпотентност на сървъра и обвързвайте всяко състояние на наемателя с реални DLR отговори от главната книга. Не създавайте неосигурени вторични портфейли и не позволявайте повторни опити през интерфейса без реални задържания в главната книга.

Полезно ли беше ръководството?

Свързани ръководства