On this pageFreeze and revoke are different verbs
When someone reaches for the kill switch, something has already gone wrong. The button has one job: make sure nothing else goes wrong, immediately, and tell you exactly what state you are in afterwards.
Freeze and revoke are different verbs#
We deliberately ship two actions. Freeze declines new authorisations but keeps the card, its policy and its history intact; unfreezing is one click. Revoke destroys the credential. It cannot be undone, and the agent needs a new card to spend again.
In the dashboard, freeze is the default and revoke asks you to type the card’s last four digits. Over the API, both are single calls with no confirmation, because an incident script should not have to negotiate.
Enforced at the network#
A kill switch that only updates our database is a suggestion. The card state is pushed to the issuing processor’s authorisation path, so the next authorisation request — from any merchant, on any rail — is declined by the network itself.
Our p99 from API call to network-enforced decline is 740 milliseconds. The API does not return until the processor has acknowledged the change.
What happens to money already in flight#
Authorisations approved before the freeze can still be captured by the merchant. We do not pretend otherwise. Instead, the response lists every open authorisation on the card with its amount and merchant, so you know the worst case the moment you act.
curl -X POST https://api.nebulabank.xyz/v1/cards/card_3fQm/freeze \
-H "Authorization: Bearer $NEBULA_KEY"
# → { "status": "frozen", "enforced_at": "2026-09-04T03:12:08.412Z",
# "open_authorisations": [ { "merchant": "Together", "amount": "1920.00" } ] }Freezing by blast radius#
Incidents rarely involve one card. You can freeze every card bound to an agent, an environment or a policy in one call — environment: staging is a popular one — and the dashboard shows the count before you confirm.