Dejan

Letting customers safely share their card with family – with separate cards, individual controls, and clear accountability for every transaction.

Product case study · Role: Product Manager · Domain: Consumer Fintech / Card Payments

TL;DR I led the Authorized Users feature: primary cardholders can add trusted people to their account, each with their own card, their own spending controls, and full transaction attribution. Behind the scenes this meant identity verification for non-applicants, per-user card issuance, and a permissions model that keeps the primary account holder in control. In the first year, about 12% of eligible accounts added at least one authorized user, and multi-user accounts consistently outspent and outlasted single-user accounts.

The problem

Households share money, but most card products are built for individuals. Partners hand each other a single physical card, parents want a card for a teenager with limits, and caregivers need to make purchases on someone else’s behalf. When issuers do support authorized users, the experience is often an afterthought: paper forms, weeks of waiting, no per-user controls, and statements where nobody can tell who bought what.

For the business, authorized users are one of the most reliable growth levers in cards: accounts with more cardholders spend more, engage more, and retain better. The opportunity was to make adding a trusted user as easy as sending an invite – without compromising on identity, credit, and fraud requirements.

What we built

• Invite-based onboarding – the primary cardholder invites someone from the app; the invitee verifies their identity and accepts on their own device.
• A real card for every user – each authorized user gets their own physical and digital card with a unique card number, available in mobile wallets immediately after approval.
• Per-user controls – the primary can set spending limits per authorized user, pause or remove a user instantly, and get notified of every transaction.
• Full attribution – every transaction is tagged with the cardholder who made it, in the feed, in statements, and in notifications.
• Clear roles – authorized users can spend and see their own activity; account ownership, payments, and credit terms stay with the primary.

How it works

The flow

The primary enters the invitee’s name and contact details and sets initial permissions. The invitee receives a link, downloads the app, and completes identity verification. Once verified, their card is issued instantly as a digital card and a physical card is shipped. From that point, both users see the shared account through their own lens: the authorized user sees their card and activity; the primary sees everything.

Key product decisions

• Unique card numbers per user. Issuing each user a distinct PAN (rather than cloning the primary card) is what makes attribution, per-user controls, and per-user card lifecycle (lost/stolen, reissue) possible – and it means pausing one user never disrupts another.
• Identity verification for invitees. Authorized users are not credit applicants, but they still need to be identified (KYC/CIP-style checks, sanctions screening). We designed a verification flow proportionate to the risk – light enough to convert, strong enough to satisfy compliance.
• The primary stays in control. Every design question came back to one principle: it is the primary’s account and the primary’s liability. Controls, visibility, and removal all follow from that.
• Minor support. Supporting teenagers required extra care around consent, marketing, and data visibility.

Under the hood (for the engineers)

• Account/user data model. The account object was decoupled from the person object: one account, many card-holding users, each with roles and permissions. Getting this model right early prevented painful migrations later.
• Card issuance pipeline. Digital-first issuance: create the card record, provision to Apple Pay / Google Pay via push provisioning, then trigger physical fulfillment – so the user can spend minutes after approval instead of waiting for the mail.
• Authorization enforcement. Per-user limits and pauses are enforced in the real-time authorization path: the decision engine resolves which user’s card initiated the transaction and applies that user’s controls plus account-level rules.
• Notifications fan-out. A single transaction can notify two people differently – the spender gets a receipt-style alert, the primary gets an oversight-style alert. Preference handling matters more than it looks.

My role

• Defined the product: roles and permissions model, invitation and verification flow, control set, and the attribution experience.
• Worked with compliance and legal on identity requirements for non-applicant users and on disclosures for shared liability.
• Coordinated across card issuance, mobile, and the authorization platform teams to sequence the launch.
• Ran the invite-funnel iterations that lifted invite-to-activation conversion, coordinating roughly ten engineers plus design and QA across three platform teams.

Challenges and trade-offs

• Conversion vs. compliance in onboarding. Every extra verification step costs invitees; every removed step is a risk conversation. We iterated on the flow to keep drop-off low without weakening checks.
• Two-sided UX. Every feature has two audiences (primary and authorized user), often with opposite needs – e.g. oversight vs. autonomy. Notification design and visibility rules took several rounds to feel respectful to both.
• Lifecycle edge cases. Removal, card reissue, account closure with active AUs, an invitee who fails verification – the long tail of states is where most of the engineering time went.

Results

• About 12% of eligible accounts added at least one authorized user within the first year.
• Multi-user accounts spent roughly 30% more per month than comparable single-user accounts, with measurably better retention.
• Invite-to-activation conversion reached about 65% after several iterations on the verification flow.

What I learned

Authorized Users looks like a simple sharing feature and is actually an identity, permissions, and card-lifecycle project wearing a simple UI. The biggest product insight was that trust runs in both directions: primaries need control and visibility, but authorized users are customers too – if the experience makes them feel surveilled or second-class, they simply do not use the card.