Manage Cards

Lock, unlock, and cancel cards, handle lost or stolen cards, change spending limits, and keep your card records in sync with Rain.

Managing a card well comes down to a few recurring decisions: when to lock versus cancel, and when to trust a webhook over your own API call. Every card in Rain has one of four statuses, and most management actions move a card between them with the Update a card endpoint. Here is what each status means:

Status	Meaning
notActivated	Issued but not yet usable (typically a physical card awaiting activation).
active	Usable for authorizations.
locked	Temporarily blocked. Reversible. Set back to active to unlock.
canceled	Permanently disabled. Cannot be reactivated.

Locking is reversible and canceling is not: a locked card can return to active, but you can never reactivate a canceled card.

Lock a card

Set a card’s status to locked to temporarily block all new authorizations. Locking is the right move for a misplaced card, a suspected but unconfirmed compromise, or a cardholder who wants to pause spend. Set the status back to active to unlock.

A lock is fully reversible and keeps the card, its number, and its digital-wallet tokens intact. Prefer locking over canceling whenever the card might return to use.

Rain automatically locks a card after too many incorrect PIN attempts, with statusChangeReason: pin_limit_exceeded on the card.updated webhook. Build a cardholder-facing unlock path so users are never stranded.

Handle lost or stolen cards

For a confirmed lost or stolen card, set its status to canceled. Cancellation is permanent. You can’t reactivate a canceled card.

To get the cardholder spending again, create a new card for the user.

Lock when in doubt, cancel when confirmed. Locking preserves recovery; canceling forces a reissue.

Change spending limits

Change a card’s spending limit anytime with the Update a card endpoint. For the available limit frequencies and an example, see Set spending limits.

Stay in sync with webhooks

Subscribe to the card.updated webhook and treat it as your source of truth for card status. It fires on every lock, unlock, and cancel, on PIN-limit auto-locks, on digital-wallet provisioning, and on changes Rain initiates internally (statusChangeReason: rain_initiated).

Reconcile your local card state against this webhook rather than assuming your API call is the only thing that can change a card. That way a Rain-side or processor-side action never leaves your records out of sync.

What’s next

Create a Card

Issue virtual and physical cards to your users.

Manage a Card's PIN

Set and retrieve PINs securely.

Issue a Scoped Card

Purpose-specific cards with hard spend caps.

Access Card Details

Retrieve full card details securely.