Member cards admin setup.

As the operator you decide whether the member-cards family runs at all, which businesses can design and issue cards, and how many codes each may issue. You also have your own uncapped Card studio that can issue cards on a client business's behalf. This page covers the full admin side; the partner Card studio guide covers why businesses print cards, which occasions fit, and how a print run works, and it applies to your studio too.

The installation switch

One setting governs the whole family: member_cards_enabled, under Admin → Settings, on by default. It is the master switch for both studios, both generated-cards lists, and the member's virtual code.

Off hides every design and issuing surface:

• The partner Card studio and the operator Card studio.
• Both generated-cards lists (partner and operator).
• The member's Show my code wallet QR.

Plan comparisons are the one mention the switch leaves alone: those surfaces gate on the tier's Member cards feature, so a tier that includes member cards keeps naming them while the switch is off.

Off never breaks cards already handed out:

• Codes already in customers' pockets keep resolving at the counter.
• An already-printed blank card can still be claimed.
• Presentation is never gated by the switch. A member presenting a card is always recognized.

Turning the switch off retires the design and issuing surfaces without bricking any plastic you already gave out. Turn it back on and the surfaces return.

What the plan controls

For a business, the design and issuing surfaces are also plan-gated. Each tier carries two values:

The shipped defaults arrive with every update and fresh install; your own values live elsewhere and survive updates.

You change them in one of three ways:

• The Plans editor, under Settings → Set up plans (also reachable from the SaaS overview). Change a tier's feature and code cap in the dashboard. Only the fields you change are stored, and they layer over the shipped defaults. See Editing plans from the admin.

• Per-tier environment values. Set PLAN_<TIER>_HAS_MEMBER_CARDS or PLAN_<TIER>_MAX_MEMBER_CARD_CODES in your environment to change a tier without touching any file:

  Every shipped tier includes member cards, so the flag override takes the feature away from a tier rather than adding it:

  PLAN_TIER1_HAS_MEMBER_CARDS=false         # turn member cards off for a tier
  PLAN_TIER2_MAX_MEMBER_CARD_CODES=500      # change a tier's code cap
  

  📖 Configuring plan values from the environment covers the naming and the accepted values.

• Per partner, under Partners → Permissions. Grant the feature and set the cap for a single business without changing any plan. This override wins over the plan for that one partner, which suits a trial or a one-off arrangement.

The operator Card studio

The operator has the installation owner's edition of the Card studio, in the admin console. It is the same workbench partners use (see the partner Card studio for the design controls and every output), with two differences:

• It is uncapped. No code limit applies to the operator.
• It can issue on a client's behalf, and issue operator cards. This is the agency model.

Issue on a client's behalf

The operator can design and issue a partner-branded card for a chosen client business. Pick the client, and the codes belong to that client: they count toward that client's inventory and appear in that client's own Card batches, as if the client had issued them. Generating lands the operator on that batch's page, rendered with the client's own card design, so the print job continues right where the cards are. This lets an operator run the print job for a business that does not want to touch the studio itself.

The operator can also issue installation-wide operator cards, which belong to the installation rather than to any one client.

For support, the operator can disable any code, whichever business issued it.

The generated-cards lists

Both sides manage their cards through Card batches: the durable home of every generated batch, with per-batch stats (blank, linked, disabled, linked percentage) and the full export bench for reprinting or re-exporting any batch later. The studios land there right after generating. The operator's edition shows every issuer's batches, each naming its issuer, and opening a client's batch renders it with that client's own card design. Both editions can clean a batch up with Delete blank cards: only never-linked cards are removed, so members, linked cards, and statistics are never lost.

Behind the scenes, both sides also keep a code-by-code Generated cards list. It stays out of the navigation, because Card batches carries the everyday work, and keeps its address as a link-testing surface. Each row shows the code with its status (blank, active, or disabled), a QR of the card's claim link, and a Disable action. Disable is one-way: a disabled code is terminal and cannot be re-enabled. Disabled codes do not count toward the partner's code cap.

• The partner list shows only that business's own issued cards. A partner learns a linked member's identity only when that member is already visible to the business.
• The operator list shows every code, with an issuer column and full identity.

Both lists share the same working tools:

• A QR column on each row, holding a QR of that card's /c/{code} claim link. Scan it from the list to check the link-to-member flow.
• A batch filter that narrows the list to one batch, by the label the issuer gave when issuing. A partner sees only its own batches; the operator sees every batch.
• Delete blank cards, a safe bulk cleanup that removes only unclaimed (blank, never-linked) codes. Claimed, active, and disabled cards are kept in every case, since they hold history, and a member's virtual "Show my code" code can never be deleted this way. A partner can delete only its own blank cards; the operator can delete any blank card, but never a virtual or a claimed one. The list offers no ordinary bulk delete on purpose, because it would be unsafe for these records.

For link-testing anywhere in the platform, note that every QR on screen also logs the URL it encodes to the browser's developer console, prefixed [QR]. This is a convention, not a leak: the QR is visible anyway, and the log turns a scan into a copy-paste. Batch pages log the whole batch's claim links as one list.

All of these surfaces, and both studios, follow the installation switch. The partner side also follows the plan entitlement.

Updating an existing installation

Member cards need no migration job and no backfill. A member's personal Show my code QR is minted the first time that member opens the sheet: one revocable code row, created on demand. Members who never open the sheet never get a row, and nothing pre-generates codes for your existing member base.

The code row is deliberate, and a member id would not do instead: the code is the revocable instrument. The model supports rotation, retiring the old code and minting a fresh one while the member's identity and links stay put; an id could never be rotated like that. The current UI exposes no rotation button: after a leaked screenshot, the member disables the linked card through Report lost on their Your cards page, and the rotation seam waits in the code for the day it earns a surface. So there is no member-id fallback, and no moment where an updated installation has to fill anything in. Turn the switch on and the feature is live; each member's code appears when they first need it.

Privacy and the activity log

The member-cards family respects account lifecycle and data-removal rules. Deleting or anonymizing a member, the ghost-member purge, and per-partner data removal all delete that member's card codes. A member's data export includes their card list. The activity log records claim, disable, and batch generation with identifiers only: never the card number, and with no per-scan tracking.

Related topics

• Overview: The instrument and the carriers
• Partner Card studio: The design controls, outputs, and the print-run manual
• Billing: The Plans editor and environment overrides
• Partner Permissions & Limits: The per-partner permission model