Limits, merchant/MCC lists, and billing addresses provide three kinds of control. Allowlists and blocklists cannot be switched in place.

Spending Controls

Limits

PATCH /v1/cards/{id}/limits
{ "single": "500.00", "daily": "2000.00", "monthly": "10000.00" }

All three fields are decimal strings in the card currency. Omitted means unchanged; "0" means unlimited.

Three Inputs That Are Rejected

⚠ Do not design your UI around automatic clamping. An excessive value returns 400; none of the user's value is applied.

Show the product maximum and validate before submitting. Otherwise, a user can enter a large value

and receive only an invalid-limit message, without knowing the maximum.

⚠ This endpoint's invalid_fields response does not include a fields array, unlike other endpoints.

All three cases share the same code, so you cannot identify the offending field from the response. Client-side validation is particularly important.

⚠ An invalid amount string ("abc", or too many decimal places for the card currency) currently returns 500.

Validate the format before sending.

Changes Take Effect Asynchronously

accepted: true means only that we recorded the change and are forwarding it upstream. It does not mean the change is effective.

Merchant / MCC Lists

GET|PUT|DELETE /v1/cards/{id}/merchant-rules

Choose an allowlist (permit only these entries) or a blocklist (deny these entries).

⚠ You cannot switch between allowlist and blocklist in place. The upstream full-update operation does not send the rule type.

Changing it can produce the worst outcome: our database records a blocklist and reports synchronization complete,

while the upstream system still enforces an allowlist. The merchant believes those entries are blocked, but only those entries are allowed.

To switch, DELETE first, then PUT. We do not perform that delete-and-add sequence for you:

between deletion and recreation, the card has no protection from this rule. You must decide whether to open that window.

Billing Address

PATCH /v1/cards/{id}/billing-address

Supported only by certain card products, where it is needed for 3DS verification. Unsupported products reject the request.

Related Endpoints

• PATCH /v1/cards/{id}/limits
• PUT /v1/cards/{id}/merchant-rules
• DELETE /v1/cards/{id}/merchant-rules