> ## Documentation Index
> Fetch the complete documentation index at: https://docs.synctera.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Manage a Card
> What you do with a card once it is live: view it, reset a PIN, lock and unlock it, reissue it, and terminate it.
## View Cards
[List Cards](/v2/reference/listcards) returns the cards you have issued. Filter by customer, account, embossed name, last four digits, expiration date, card type, brand, form, card product, and cardholder postal code, and sort by expiration date.
[Get Card](/v2/reference/getcard) returns a single card by ID.
### View Card History
Subscribe to `CARD.UPDATED` webhooks to receive every change as it happens, and use [Get Card](/v2/reference/getcard) to read the current state.
## Reset a PIN
Cardholders forget PINs. Have them set a new one with the [Set PIN widget](/v2/docs/card-widgets-set-pin), or use [Set Card PIN](/v2/reference/setcardpin) if you are PCI certified — the same mechanism that sets the initial PIN.
`timestamp_pin_set` records when the PIN last changed.
If the card was suspended after too many incorrect PIN attempts, resetting the PIN is only half the fix. The card also has to be returned to `ACTIVE`. See [Reset PIN Tries](#reset-pin-tries).
## Reset PIN Tries
If someone enters a card's PIN incorrectly too many times in a short period — typically at an ATM or point-of-sale device — the card vendor suspends the card. Its status becomes `SUSPENDED` and the cardholder will most likely contact you.
There are three courses of action:
* **If fraud occurred**, reissue the card. This resets the PIN tries on the new card.
* **If the customer has forgotten their PIN**, have them reset it with the Set PIN widget, then set the card back to `ACTIVE`.
* **If the customer remembers their PIN correctly**, set the card back to `ACTIVE`.
You can also handle status changes and reissuance through the Synctera dashboard when a support agent is working with the customer.
## Lock and Unlock a Card
Customers often want to temporarily disable a card — a misplaced wallet, a suspicious charge they want to investigate. Suspend the card with [Update Card](/v2/reference/updatecard) and reactivate it the same way:
```bash Lock theme={"system"}
curl --request PATCH \
--url "$baseurl/v2/cards/{CARD_ID}" \
--header "Authorization: Bearer $apikey" \
--header "Content-Type: application/json" \
--data '{
"card_status": "SUSPENDED",
"reason": "REQ",
"memo": "Customer misplaced card"
}'
```
```bash Unlock theme={"system"}
curl --request PATCH \
--url "$baseurl/v2/cards/{CARD_ID}" \
--header "Authorization: Bearer $apikey" \
--header "Content-Type: application/json" \
--data '{
"card_status": "ACTIVE",
"reason": "REQ"
}'
```
Unlike termination, suspension is reversible. Use `reason` to record why the status changed and `memo` for free-text detail.
## Reissue a Card
A card may be reissued because it is expiring, was lost or stolen or damaged, or needs to change appearance or program. You reissue by calling [Issue a Card](/v2/reference/issuecard) with `reissued_from_id` set to the card being replaced and `reissue_reason` set to why.
The reason determines whether the replacement keeps the same PAN, and when the old card is terminated:
| Reason | Same PAN | Old card terminated | Use when |
| ---------------- | -------- | ------------------- | -------------------------------------------------------- |
| `EXPIRATION` | Yes | On activation | The card is approaching its expiration date |
| `DAMAGED` | Yes | On activation | The customer requests a replacement for a damaged card |
| `APPEARANCE` | Yes | On activation | The name printed on the card or its custom image changes |
| `PRODUCT_CHANGE` | Yes | On activation | The card moves to a different product |
| `PROGRAM_CHANGE` | Yes | On activation | The card moves to a different program |
| `BANK_MIGRATION` | Yes | On activation | Cards are migrated to a different sponsor bank |
| `LOST` | No | Immediately | The customer reports the card lost |
| `STOLEN` | No | Immediately | The customer reports the card stolen |
In every case the replacement card gets a new CVV and expiration date, **keeps the same PIN** as the original, and inherits its digital wallet tokens — cardholders do not need to re-add the card to Apple Pay or Google Pay. Cards already on file with merchants are updated automatically too.
Synctera terminates the old card at the right moment for you. For reasons that terminate on activation, the old card stays usable until the replacement is activated or its expiration date arrives, so the customer is never without a working card.
**Automating expiration reissuance.** Use [List Cards](/v2/reference/listcards) with the `expires_before` filter, or sort by `expiration_date`, to find cards that are about to expire. From there you can run a background job that reissues them without customer interaction, or prompt the customer through a reissuance flow where they confirm the shipping address. An expiration reissuance must be requested **before** the actual expiration date.
## Terminate a Card
Set the card's status to `TERMINATED` with [Update Card](/v2/reference/updatecard):
```bash cURL theme={"system"}
curl --request PATCH \
--url "$baseurl/v2/cards/{CARD_ID}" \
--header "Authorization: Bearer $apikey" \
--header "Content-Type: application/json" \
--data '{
"card_status": "TERMINATED",
"reason": "REQ",
"memo": "Customer requested closure"
}'
```
Synctera notifies the card vendor, which terminates the card. **Termination is permanent** — a terminated card cannot be reactivated. If the customer needs a working card afterward, issue a new one.
## Next Steps
The states a card moves through, and what drives them.
Prerequisites, issuance, activation, and setting a PIN.
One card followed end to end, with the calls at each step.