> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluz.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Recipient Experience

> What a recipient sees when they open a hosted virtual card link — sign-in, two-factor verification, PIN, claim, and the program rules that govern how the card can be spent.

Every hosted link generated with [`generateVCShareLinks`](/features/open-loop-cards/send-open-loop-cards#generatevcsharelinks) resolves to a Fluz-hosted activation page at `https://fluz.app/virtual-prepaid-card/{share_request_id}`. The recipient claims their card there — no app download, no password.

The recipient becomes an authorized user of that virtual card object only. They do not gain access to your account, your balances, or any other cards.

See it in action: [desktop flow](https://test.fluz.app/wp-content/uploads/2026/04/Web-Share-V6.mp4) · [mobile flow](https://test.fluz.app/wp-content/uploads/2026/04/Mob-Share-F.mp4).

## Claim flow

<Steps>
  <Step title="Landing & sign-in">
    The recipient sees the activation page branded with the sender's business. They sign in through the Fluz auth portal (new recipients onboard here).
  </Step>

  <Step title="Two-factor authentication">
    On initial load, existing users are taken to the 2FA screen. 2FA is required before the card can be viewed or claimed.
  </Step>

  <Step title="Billing address (if needed)">
    If the recipient has no billing address on file, they're prompted to add one. *Billing address is required for online purchases.*
  </Step>

  <Step title="Card issued & claimed">
    A single-load virtual card is created and assigned to the recipient, funded from the sender's account, with a lock date equal to the link's expiration date. No PIN prompt occurs during activation.
  </Step>

  <Step title="Reveal & PIN">
    The card is not auto-revealed on claim. When the recipient chooses to reveal card details, they're prompted to enter their PIN — or create one, if they haven't set one yet.
  </Step>

  <Step title="Use the card">
    Once revealed, the recipient can see card details, transactions, spend online, and (where supported) add the card to Apple Pay or Google Pay in one tap.
  </Step>
</Steps>

<Note>
  **Already claimed?** If the same user opens a link they already claimed, they land on their card and are prompted for their PIN to reveal it. If a *different* user opens a link that someone else already claimed, they're shown an access-denied state after 2FA.
</Note>

<Info>
  **Funding timing.** The card limit is drawn against the sender's spend account **at claim time**, not when the link is generated.
</Info>

## What the recipient sees for expiration

The link's expiration date — set by the sender via `daysUntilExpiration`, defaulting to 30 days — is surfaced to the recipient, typically as a "Valid until" date.

* Before claim, that date is the **last day the link can be claimed**.
* After claim, that date is the card's **freeze / lock date** (end of day). After it, the card can no longer be spent.
* The printed **card expiry** is aligned to the end of that month (e.g., a freeze date of 6/15/2026 yields a card expiry of 6/30/2026).

Full sender-side mechanics are covered in [Expiration & freeze](/features/open-loop-cards/send-open-loop-cards#expiration--freeze).

## Recipient-facing link errors

| Condition                                      | What the recipient sees                                  |
| ---------------------------------------------- | -------------------------------------------------------- |
| Link expired before being claimed              | "Expired before issued" — link can no longer be claimed. |
| Sender deactivated the link early              | "Frozen by sender" — link was revoked before expiry.     |
| Card was claimed, then its lock date passed    | "Expired after issued" — card is frozen.                 |
| A different user opens an already-claimed link | "Access denied".                                         |

## Program rules to communicate to recipients

These are program-level rules for hosted (open-loop) virtual cards. Confirm the exact values for **your** program with your Fluz representative — several are partner-negotiated.

| Rule                              | Default                | Notes                                                                            |
| --------------------------------- | ---------------------- | -------------------------------------------------------------------------------- |
| Daily account spend limit         | **\$250,000/day**      | Some partners have a custom limit.                                               |
| Restaurant transaction buffer     | **25%**                | A 25% buffer applies to all programs (to accommodate tips/holds at restaurants). |
| Restricted merchants / categories | Program-specific       | Certain merchant categories are restricted.                                      |
| Funding                           | Sender's spend account | Cards are funded from the sender's account at claim time.                        |

**Customer support for recipients:** 1-888-360-6660 · [humans@fluz.app](mailto:humans@fluz.app)

<Note>
  The full partner-facing reference (terminology, recipient walkthrough with screenshots, funding instructions, restricted categories, and support) lives in the **Partner Guide — Hosted URL Virtual Cards**. Ask your Fluz contact for the latest copy for your program.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Send open-loop cards" icon="link" href="/features/open-loop-cards/send-open-loop-cards">
    Generate, list, and deactivate hosted virtual card links from the API.
  </Card>

  <Card title="Create a bulk order" icon="layers" href="/features/create-bulk-order">
    Issue many cards at once for programmatic distribution.
  </Card>
</CardGroup>