Credențiale sandbox care nu ard Live debit

Credențialele sandbox există ca engineering să trimită trafic de test fără a atinge ledger-ul prepaid. Live debit trebuie să fie imposibil dintr-o cheie sandbox — nu un avertisment blând într-un README pe care nimeni nu-l citește în timpul unui incident.

IOSOR tratează sandbox ca o credit posture separată: OTP-urile de test și căile de alertă pot reuși pe banda sandbox în timp ce wallet-ul rămâne plat. Dacă apare un hold sau un debit de la o cheie etichetată sandbox, credential-ul este greșit scoped și trebuie revocat înainte de următoarea rulare CI.

Separați cheile sandbox de Live hold

Creați în Developers o cheie sandbox care nu poate deschide un prepaid hold. Dovediți că un OTP de test pe banda sandbox returnează success cu zero wallet debit și zero MRC în același minut. Exportați ledger-ul pentru fereastră și păstrați dovada lângă id-ul cheii.

Dacă apare un rând hold, revocați imediat cheia și tratați-o ca defect de credential — nu ca test flaky. Emiteți o cheie sandbox corect scoped și repetați dovada până când ledger-ul rămâne plat.

Legăți CI și staging doar de scope-uri sandbox

Variabilele CI și staging arată doar spre credențiale sandbox. Nu lipiți niciodată o cheie Live într-un secret GitHub, un fișier Docker compose, un .env de laptop pentru demo sau un folder comun de password manager etichetat «test».

Rotați orice cheie Live care a apărut într-un test harness. Înregistrați ora rotației ca finance să potrivească un debit rătăcit cu fereastra scurgerii. Host-urile staging care după rotație încă țin un secret Live eșuează următoarea poartă de deploy.

Dovediți izolarea debit înainte de primul pilot

Exportați ledger-ul pentru fereastra de trimitere sandbox înainte de a invita un host pilot. Confirmați: niciun hold, niciun debit, nicio cale Live din cheia sandbox. Documentați dovada lângă id-ul cheii ca finance să auditeze că traficul de test nu a cheltuit.

Repetați exportul după prima săptămână de CI ca drift-ul să nu reintroducă pe tăcute o cheie Live printr-o variabilă workflow uitată.

Obiceiurile de cutover rămân în Developers

Când promovați un build, urmați checklist-ul Live cutover din Developers — cheie Live nouă, revocare sandbox de pe host-urile de producție și smoke de prospețime vault înainte de runway verde. Nu reutilizați secretul sandbox ca cheie Live temporară «doar pentru pilot».

Cutover este o schimbare de credențiale plus o verificare de ledger — nu un flip de flag în config. Țineți țintele webhook și id-urile cheilor aliniate cu mediul pe care îl revendicați pe runway board.

Căi ops conexe

Țineți cutover și onestitatea coverage alături, ca echipele să nu inventeze o a treia poveste de chei:

• Cutover chei sandbox vs producție
• Verificări reach: coverage sandbox versus producție
• Săptămâna pilot wallet: adevărul hold și debit

Începeți cu IOSOR

În Developers emiteți o cheie sandbox, trimiteți un OTP pe un E.164 de test consimțit și exportați ledger-ul pentru acel minut. Confirmați zero hold și zero debit. Blocați CI pe acel id de cheie. Abia apoi cereți o cheie Live pentru host-ul pilot și revocați sandbox de pe orice host care va purta trafic Live.

Rezumat IOSOR

Credențialele sandbox care nu pot deschide Live debit sunt o regulă dură de scope — nu o etichetă de folder. Finance are încredere în exportul de ledger de lângă id-ul cheii — nu doar într-o bifă verde de CI. Dacă o cheie etichetată sandbox deschide vreodată un hold, revocați înainte de următoarea rulare de pipeline.