IOSOR

IOSOR База знань

Velocity caps перед production OTP

Гейт production OTP за velocity і cooldown до порожнього prepaid-гаманця — caps за identity, destination і вікном, із чесним limit status.

Production OTP без velocity caps — prepaid fire hose. Caps потрібні до мови Live volume, а не після питання finance, куди зник гаманець. Ця сторінка — velocity gate: хто, куди, як швидко — окремо від механіки TTL/resend і від історії двох debit verify.

Пов’язані: TTL OTP і пауза повторного надсилання, списання доставки OTP і сесія verify, OTP abuse: перші контроли на buyer path, фінансові межі гаманця перед production-трафіком, огорожі від зловживань OTP і витрат.

IOSOR — white-label prepaid. USD 20 фінансує пілот velocity; soft review близько USD 1 000/міс робить відсутність caps production-боргом. Клієнт бачить лише white-label limit outcomes.

Velocity — це не TTL

TTL відповідає, скільки живе код. Velocity — скільки intents identity або destination може mint у вікні. Cooldown розносить resend; velocity ріже burst, який не має початися. Плутанина лишає path, де TTL дотримано, а гаманець порожніє. Тримайте обидва гейти й називайте, який спрацював у status.

Caps за identity, destination і вікном

Cap Питання вікна Fail closed
Per identity / account Скільки OTP intents / год? Чесний rate-limited
Per destination class Burst дорогого коридору? Corridor blocked
Per IP / device family Bot-shaped minting? Challenge або reject
Wallet stop-line Spend за stop? Hold відмовляє send

Вивантажуйте спрацьований cap з intent id. Soft USD 1 000/міс вважає uncapped prod OTP ризиком recon; USD 20 доводить caps на вузькому коридорі. Стоп-лінії: фінансові межі гаманця перед production-трафіком.

Гейт prod OTP до мови Live

Не фарбуйте production OTP Live, доки velocity caps у draft. Зелений smoke на happy path — не proof velocity. Потрібно: caps налаштовано, fail-closed перевірено, export показує який cap, finance стикує limited intent з hold. Чесність launch: Коли launch заблоковано: статус без брехні. Сусід first-controls: OTP abuse: перші контроли на buyer path.

Чесний limit status для product і finance

Коли cap спрацьовує, status — limited/rejected, не delivered і не silent drop. Product і finance ділять це слово (Спільна мова статусів для product і finance). Retry під тим самим idempotency key не обходить cap. Два debit — окремо: списання доставки OTP і сесія verify.

Чекліст покупця щодо velocity caps

  1. Caps на identity і destination class до prod OTP?
  2. Fail-closed доведено — burst дає чесний limit?
  3. Export називає, який cap спрацював для intent?
  4. Мова Live/prod blocked, доки caps у draft?
  5. Wallet stop-lines поруч із velocity caps?
  6. Override названо, обмежено в часі, закрито capped smoke?

Будь-яке «ні» лишає velocity gates у draft.

Почніть з IOSOR

Налаштуйте ліміти швидкості генерації OTP для ідентифікаторів та класів призначень у консолі IOSOR перед переведенням сервісу у статус Live. Протестуйте поведінку fail-closed за допомогою штучного спалаху запитів, щоб переконатися у поверненні чесного статусу обмеження замість прихованого скидання. Перевірте, що експорт подій та вебхуки чітко вказують назву спрацьованого ліміту для аналітики продукту й фінансів.

Підсумок IOSOR

Ця стаття доводить, що тайм-аут коду (TTL) захищає лише один сеанс, тоді як velocity caps блокують масовий спалах спам-інтентів, здатний вичерпати бюджет.

Чи був матеріал корисним?

Пов’язані гіди