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, the member's virtual code, and the plan-comparison mentions.

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.
• The plan-comparison mentions of member cards.

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.

The two plan keys

For a business, the design and issuing surfaces are also plan-gated. Two config/plans.php keys control them per tier:

These ship as defaults on update. config/plans.php is pure defaults, refreshed by every update, so a fresh install and an updated install both receive the two keys on the shipped tiers. You do not hand-edit that file to keep your settings, and you should not think of it as protected: your own values live elsewhere and survive updates.

You customize the keys in one of three ways:

• The Plans editor (SaaS overview → Plans). Change a tier's feature flag 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:

  PLAN_TIER1_HAS_MEMBER_CARDS=true          # offer member cards on a tier that ships without them
  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 touching plans.php. 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 max_member_card_codes 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.

• 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. Get a new code retires the old one and mints a fresh one while the member's identity and links stay put; an id could never be rotated like that. 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