NFC Business Card Programs

Enterprise NFC card programmes — what changed after the Linq sunset (January 2025)

There is a specific flavour of dread reserved for the IT manager who learns the company's business cards now point at a startup's tombstone. Procurement teams running 100+ employee NFC card programmes face a different risk profile than solo or small-team buyers. The dominant risk in 2026 is platform-extinction — the January 2025 Linq sunset (Linq exited the digital-card business and pivoted to AI messaging APIs) left enterprise customers with a deteriorating routing layer that they couldn't fix without re-issuing cards across their entire workforce.

**Why enterprise is more exposed than solo.** A solo NFC card user whose SaaS platform sunsets reorders one card from a different vendor in 10 minutes. An enterprise with 500 sales reps has to: (1) procure replacement cards from a new vendor (typically 3-4 week lead time including artwork + pre-encoding), (2) coordinate distribution to 500 employees across global offices, (3) update CRM lead-capture integration to the new vendor's API, (4) communicate the change to existing prospects who have the old card already saved. Total cost in time + lost lead capture during transition is typically 5-10× the original card programme cost.

**The fix is in the URL routing layer, not the chip.** An enterprise programme where each card encodes `https://yourcompany.com/contact/{employee-slug}` is platform-extinction-immune — the URL routes server-side via the company's own web server. If a SaaS engagement layer is in use, the company can swap providers without touching the cards. If no SaaS is needed, the cards work indefinitely.

**SCIM provisioning closes the loop.** HR system → SCIM → IdP (Okta, Azure AD) → URL routing rule. New hire on Day 1: card encoded with `{employee-slug}` works immediately because the routing rule was created when SCIM provisioned the user. Offboarding: SCIM de-provisioning removes the routing rule; URL returns 410 Gone or redirects to a generic company contact page. No physical card recovery needed.

**The procurement consequence:** OEM-direct cards pointing at the company's own domain + SCIM-automated URL provisioning is the 2026 enterprise standard. SaaS routing platforms remain valid for solo + small-team programmes (where the lock-in cost is small); for 100+ employee rollouts the OEM-direct + self-hosted-URL pattern is the safer architecture.

Four-cohort rollout architecture — executive, sales, customer-success, general workforce

Every enterprise card programme eventually rediscovers the same quiet law of organisational physics: card weight tends to track job title, and nobody has to be told why. Enterprise NFC card programmes typically segment the workforce into four cohorts with different card materials, chip families, and engagement workflows. The matrix below is the cost-effective default; specific industries adjust (e.g., legal firms might run only executive + general cohorts; sales-led tech companies might expand the sales cohort and skip customer-success).

• **Material tier signals seniority** — executive metal cards carry brand and personal positioning; sales premium PVC + wood cards carry brand-personal balance; customer-success and general workforce cards carry primarily functional value.
• **Chip tier follows engagement complexity** — NTAG 213 (144B) for URL-only redirect; NTAG 215/216 for embedded vCard payload; NTAG 424 DNA SUN for executive anti-clone authentication.
• **MOQ at enterprise scale** — typical 100-employee rollout buys 500–1,000 cards (2× quantity buffer for replacements, lost cards, marketing campaign rotation). At MOQ 1,000+ supplier negotiation tier cost drops 30-50% vs MOQ 100.
• **Brand standards** — each cohort gets a distinct artwork variation (metal + brand mark for executive; full-colour CMYK with employee name for sales; cleaner / lighter brand for customer-success; standard for general). Centralised brand-standards review approves each cohort's artwork once; per-employee customisation happens via the URL routing layer, not the printed card.
• **Re-issuance cadence** — typical re-order annually: 10–20% of cards (replacements, lost / damaged, new hires, role changes). Plan re-order into the recurring marketing budget.

URL routing — stable redirect URL on company domain, SCIM-provisioned

The architectural decision that determines enterprise programme success: where does the URL on the card point to. Three patterns exist; the recommended pattern for 100+ employee rollouts is the stable-redirect-on-company-domain pattern.

• **Pattern 1 — Static URL on company domain (recommended).** Each card encoded with `https://yourcompany.com/contact/{employee-slug}` at the converter. URL never changes after card production. Server-side redirect rule maps `{employee-slug}` → current contact page / vCard / lead-capture form. Survives any vendor pivot, marketing-campaign rotation, brand refresh, employee role change.
• **Pattern 2 — SaaS routing platform.** Each card encoded with `https://linq.app/{employee-id}` (or Popl, V1CE, Mobilo, Wave, Blinq). Convenient turnkey but lock-in risk realised at Linq's January 2025 sunset. SaaS pricing $6.99–15.99 / user / month for full features = $17K–38K / year at 200-employee scale in perpetuity.
• **Pattern 3 — Hybrid.** Card encoded with company-domain URL; redirect routes through self-hosted analytics endpoint (Plausible, Matomo) before resolving to the SaaS engagement layer. Captures analytics on company side; keeps SaaS turnkey for non-mission-critical engagement features.
• **SCIM provisioning** — System for Cross-Domain Identity Management (SCIM 2.0; RFC 7643 + 7644) is the open standard for automated user provisioning. Pattern: HR system (Workday, BambooHR, ADP, Successfactors) writes user creation/update/deletion events to IdP (Okta, Azure AD) via SCIM API. IdP writes URL routing rule on company web server.
• **New-hire workflow** — Day 0: HR creates user in Workday. SCIM triggers Okta provisioning. URL routing rule created (`{slug}` → `{employee-id}` → contact page). NFC card already encoded with `{slug}` works on Day 1.
• **Offboarding workflow** — HR deactivates user in Workday. SCIM triggers Okta de-provisioning. URL routing rule removed; `https://yourcompany.com/contact/{slug}` returns 410 Gone or redirects to generic company contact page. No physical card recovery needed; the card simply stops resolving.

CRM lead-capture integration — Salesforce, HubSpot, Pipedrive, Marketo

Enterprise NFC card programmes typically tie into the CRM that owns lead-capture workflows. The tap → lead-form auto-populate → CRM API call is the standard integration pattern.

• **Salesforce** — REST API + Sales Cloud lead creation. Pattern: NFC tap → company landing page with employee-pre-populated lead form → form submit triggers Salesforce REST API call creating Lead record with `Owner = {employee_salesforce_id}`. Per-tap analytics via Salesforce reports.
• **HubSpot** — Smart Forms + Workflows. Pattern: NFC tap → HubSpot-hosted or company-hosted landing page → smart form submit → HubSpot CRM Lead created with `HubSpot Owner = {employee_hubspot_id}` and automatic workflow trigger.
• **Pipedrive** — REST API + activity automation. Pattern: NFC tap → company landing page → form submit → Pipedrive REST API creates Deal in pipeline assigned to `{employee_pipedrive_user_id}`.
• **Marketo** — landing page + program enrollment. Pattern: NFC tap → Marketo-hosted landing page → form submit → Marketo Lead + Program enrollment.
• **Microsoft Dynamics 365 Sales** — analogous REST API integration; common in Microsoft-shop enterprises.
• **Multi-region routing** — international sales teams need region-specific routing (US sales → North America Salesforce instance; EU sales → EMEA Salesforce instance with EU data residency). The company-domain URL routing layer handles the regional split server-side; cards don't need to be region-specific.
• **Lead-capture form fields** — minimal fields convert better. Typical: name, email, company, phone (optional). Per-tap source attribution (event ID, campaign ID, employee ID) automatically populated server-side without prompting the user.

Marketing-campaign URL rotation — same cards, different destinations

Enterprise programmes typically rotate NFC card destinations multiple times per year for event campaigns, product launches, partner programmes. The stable-redirect pattern lets cards rotate without physical re-issuance.

• **Conference / event mode** — during Dreamforce, HIMSS, NRF, RSAC the sales team's NFC card redirects to a conference-specific landing page (`/event/dreamforce-2026/{employee-slug}`). After the event, redirect rolls back to the standard contact page. Same physical card; different landing.
• **Product launch campaign** — during a new product launch, the entire sales team's cards redirect to a product-specific landing page with embedded demo request. Run for 4–8 weeks; revert to standard.
• **Partner / co-marketing campaign** — joint go-to-market with a partner (e.g., AWS, Microsoft) routes cards to a co-branded landing page during the partnership window.
• **A/B testing** — different cohorts route to different landing variants; conversion data informs the standard landing page redesign.
• **Server-side analytics** — every redirect captures campaign ID, employee ID, tap timestamp, device class, downstream click-through. Per-employee performance metrics for sales-operations dashboards.
• **Brand-refresh transition** — during brand-refresh windows (typically every 3–5 years), redirects can roll out new brand artwork on the landing page while old-brand cards continue to function. Eliminates urgency to re-issue cards during brand transitions.

GDPR / CCPA / SOC 2 — data residency and DPA framework

Enterprise lead-capture flows cross GDPR Article 28 controller/processor lines, CCPA processor-disclosure obligations, and SOC 2 audit scope. The architectural choice (self-hosted URL vs SaaS routing) determines which obligations apply.

• **GDPR Article 28** — company is data controller for lead data captured via NFC card. Any SaaS routing platform is processor; needs a Data Processing Agreement, sub-processor list audit, data residency commitment. Self-hosted URL eliminates the processor relationship entirely.
• **CCPA controller/processor framework** — similar shape for California-resident lead data. Self-hosted URL eliminates CCPA processor-disclosure obligations.
• **SOC 2 audit scope** — if NFC card programme touches lead-capture systems in SOC 2 scope, the routing layer falls inside scope. Self-hosted URL on company domain keeps the routing layer inside existing SOC 2 boundary; SaaS routing adds a vendor in the audit-trail.
• **Data residency** — EU sales teams' lead data typically needs to land in EU-region Salesforce / HubSpot / first-party DB. Company-domain URL routing layer enforces region routing server-side (`/contact-eu/{slug}` for EU staff).
• **Cookie / consent** — landing page that captures lead data typically requires GDPR cookie consent. Standard integrations with OneTrust, TrustArc, Cookiebot apply.
• **Right-to-erasure** — GDPR Article 17 right to be forgotten applies to lead data captured via NFC card. CRM + landing-page database must support DSAR (Data Subject Access Request) and erasure workflows.
• **Offboarding evidence** — for compliance audit, document that departing employee's card URL was revoked within X business days of offboarding (typical 1-3 days). Server-log evidence ties offboarding event to URL routing rule removal.

Aliro 1.0 + mobile wallet integration

Aliro 1.0 (CSA released February 2026) introduces unified digital-key + business-card standards across Apple, Google and Samsung wallets. Enterprise NFC card programmes can pair physical cards with mobile-wallet digital business cards as an overlay.

• **Apple Wallet contact pass** — executive + sales cohorts often pair physical card with Apple Wallet contact pass. The wallet pass is provisioned via the company's MDM (Jamf, Intune, Kandji) or sent via email link.
• **Google Wallet contact pass** — analogous for Android. Provisioned similarly via MDM.
• **Samsung Wallet** — Samsung-specific pass integration; relevant in markets with high Samsung share (Korea, parts of Asia).
• **Aliro 1.0 unification** — Aliro published February 2026 by CSA unifies the implementation pattern across the three wallet platforms. Enterprise programmes planning 2026–2028 rollouts should specify Aliro-readiness in vendor selection.
• **Hybrid pattern** — physical card stays the brand-presentation moment (tactile, gift-able, memorable); wallet pass provides backup + always-on contact-share for tap-to-share between phones (without needing the physical card).
• **ProTip** — the wallet pass URL can be the same `https://yourcompany.com/contact/{slug}` URL as the physical card. Server-side routing detects the User-Agent and serves different responses (vCard for direct browser; wallet pass installer for wallet-specific access).

Pricing and MOQ at enterprise scale

The figures below are the unglamorous part of the programme — and also the part that decides whether your contact-sharing strategy outlives the vendor that sold it to you. Enterprise programmes typically aggregate cross-cohort volume to hit better per-card pricing. The table below assumes a 200-employee programme with four cohorts.

• **Programme TCO over 3 years** — typical $15K–$50K for the 200-employee programme above; vs $50K–$120K for SaaS routing alternative ($15K–$40K / year × 3). Self-hosted ROI within 1 year.
• **Sample lead time** — 5–10 working days for paper / PVC sample cards; 10–15 working days for metal / hardwood samples; 15–20 working days for NTAG 424 DNA SUN samples (requires AES key provisioning).
• **Production lead time** — 3–4 weeks for PVC at MOQ 500; 4–5 weeks for metal / hardwood; 5–6 weeks for NTAG 424 DNA SUN at MOQ 200.
• **Re-issue cadence** — plan annual 10–20% re-issue for new hires, lost cards, role changes. Reduce friction with always-stock-on-hand of standard cohort cards.

FAQ