# Partner Integration Plan: Panini and Sticker/Card Providers

**Project:** Fan Passport: The World Cup Journey  
**Milestone:** #7 Partner Integration  
**Artifact:** 1 of 3 — Partner integration plan  
**Version:** 1.0  
**Date:** 2026-06-17  
**Status:** Complete standalone planning artifact

---

## 1. Executive Summary

Fan Passport can become more valuable if it connects the app’s digital football passport, achievements, predictions, and virtual collections with official or semi-official sticker and card ecosystems. The most desirable partner category is the official sticker/card publisher for the FIFA World Cup cycle, commonly associated historically with **Panini**, alongside other physical and digital collectible providers.

This plan defines how Fan Passport should approach integrations with Panini and other sticker/card providers while making a strict distinction between:

1. **Proposed integrations** that require partner approval, licensing rights, credentials, commercial terms, and security review.
2. **Unpartnered fallback experiences** that Fan Passport can operate independently using original, non-infringing virtual collectibles, fan memories, challenge badges, and user-generated collection metadata.

No actual Panini, FIFA, team, player, stadium, sticker/card, or official tournament asset integration should be represented as live unless FablePool has signed agreements and received production credentials. Until then, all partner references are strategic proposals and implementation targets.

---

## 2. Goals

### 2.1 Product Goals

- Let users connect a football sticker/card collection to their Fan Passport profile.
- Allow users to show collection progress, favorite cards, duplicate counts, and album completion milestones.
- Encourage daily return behavior through collection goals, pack openings, challenges, trivia rewards, and trade discovery.
- Create a bridge between physical collecting and digital engagement.
- Support future expansion into Premier League Passport, Champions League Passport, club passports, and a broader football fan rewards ecosystem.

### 2.2 Partner Goals

A sticker/card partner should gain:

- Incremental engagement and daily active fan behavior.
- Opt-in traffic from Fan Passport into partner-owned retail, digital album, or collector experiences.
- Privacy-safe collection analytics.
- Co-branded challenges and achievements that increase album completion.
- A controlled API layer for collection/profile sharing without exposing unnecessary personal data.
- Anti-fraud controls for redemption codes, digital packs, and trade events.

### 2.3 User Goals

Collectors should be able to:

- Display collection identity and progress.
- Track official or partner-supplied album completion where permitted.
- Collect original Fan Passport digital items even without a partner account.
- Discover safe, moderated opportunities to exchange duplicates.
- Control exactly what parts of their profile are public, private, friends-only, or partner-shared.
- Revoke partner sharing at any time.

---

## 3. Scope and Assumptions

### 3.1 In Scope

This plan covers:

- Proposed integration models for Panini and similar sticker/card providers.
- Partner architecture and data-sharing boundaries.
- Commercial and legal considerations.
- Partner onboarding stages.
- Data ownership and consent principles.
- High-level technical integration patterns.
- Inventory sync options.
- Virtual album and duplicate/trade readiness.
- Recommended rollout phases.
- Risk, safety, moderation, and fraud considerations.

### 3.2 Out of Scope for This Artifact

The following are delivered as separate milestone artifacts:

- Full collector profile sharing API specification.
- Detailed virtual album and item-exchange platform design.

This artifact references those systems at a high level so the integration strategy is coherent.

### 3.3 Core Assumptions

- FablePool does not currently have confirmed Panini credentials, an official sticker/card license, or a signed FIFA-related collectibles agreement unless supplied separately by project owners.
- Fan Passport must not scrape partner accounts, ask users for partner passwords, copy official sticker/card artwork without permission, or imply official endorsement without a signed agreement.
- Partner integrations must be opt-in, revocable, privacy-preserving, and auditable.
- Some users may be minors, so the product must support age-appropriate privacy, messaging, trading, and data-sharing controls.
- Official World Cup marks, team crests, player images, stadium imagery, match footage, sticker/card artwork, album layouts, and tournament branding are licensed intellectual property.

---

## 4. Integration Principles

### 4.1 Proposed Unless Contracted

Every Panini or third-party sticker/card integration must be labeled internally and externally as **proposed** until the relevant rights, credentials, and operational approvals are confirmed.

Recommended language for public materials before a deal exists:

> “Fan Passport is designed to support integrations with official sticker and card partners, subject to partner approval and licensing. Current virtual collectibles are Fan Passport originals unless marked as official partner content.”

### 4.2 User Consent First

No partner should receive identifiable collection or profile data unless the user has explicitly opted in. Consent must be:

- Granular.
- Human-readable.
- Time-stamped.
- Revocable.
- Logged for audit.
- Reconfirmed when scopes materially change.

### 4.3 Data Minimization

Share the smallest useful dataset with partners. For most use cases, partners do not need a user’s email address, exact date of birth, precise location, prediction history, friend graph, or raw behavioral event stream.

### 4.4 Licensed Content Boundaries

Fan Passport should support three content tiers:

| Tier | Description | Requires Partner License |
|---|---|---:|
| Fan Passport Original | Original badges, fantasy-style collectibles, generic country/stadium journey items, memories, trivia rewards | No, if designed without protected assets |
| Partner Metadata Linked | Partner album progress, card IDs, duplicate counts, redemption events, deep links without artwork reuse | Usually yes for commercial use; confirm terms |
| Official Partner Content | Official sticker/card art, album images, logos, player likenesses, pack artwork, co-branded challenges | Yes |

### 4.5 Interoperability Without Lock-In

The platform should support Panini but not hard-code its business logic into the core product. A partner connector model allows future integrations with:

- Other sticker/card publishers.
- Digital collectible platforms.
- Retail reward partners.
- Club or league membership programs.
- Sponsor campaigns.
- Stadium or event collectible programs.

### 4.6 Safety by Design

Collection sharing and exchanges must be designed without enabling harassment, predatory trading, scams, or unsafe contact between minors and adults. The exchange platform should avoid free-form private messaging by default and should use structured trade offers, moderation, reporting, and risk scoring.

---

## 5. Partner Categories

### 5.1 Primary Sticker/Card Publisher: Panini-Style Integration

Panini is the highest-priority target because of its historical association with football sticker albums and fan collecting behavior. This plan treats Panini as a proposed partner, not an active integration.

Potential Panini-aligned use cases:

- Link a Panini account or collector ID to Fan Passport.
- Show official album completion percentage inside Fan Passport.
- Award Fan Passport achievements for official collection milestones.
- Redeem physical pack codes for digital Fan Passport items or partner rewards.
- Deep-link users from Fan Passport to partner-owned purchase or album pages.
- Let users share a privacy-safe public collector profile.
- Support duplicate discovery and trade matching, if contractually allowed.
- Run co-branded “complete a group,” “collect all stadiums,” or “matchday pack” campaigns.

### 5.2 Other Physical Sticker/Card Providers

Other providers may include regional sticker publishers, trading card companies, licensed retail card producers, or tournament-specific collectible vendors.

Potential use cases:

- Import collection checklists.
- Sync ownership status or duplicate counts.
- Redeem codes from physical products.
- Promote retailer or publisher campaigns.
- Provide exclusive Fan Passport achievements.
- Offer rewards for album completion.

### 5.3 Digital Collectible and Virtual Card Platforms

Digital collectible platforms may offer API-driven inventory, ownership proofs, or collectible pack mechanics. These integrations should be evaluated carefully, especially where collectibles have resale markets or blockchain components.

Potential use cases:

- Read-only inventory display.
- Achievement awards for verified ownership.
- Collection showcases.
- Optional wallet or platform account linking.
- Cross-platform missions.

Policy guardrails:

- Fan Passport should not become a speculative financial trading product.
- Avoid language implying investment value.
- Age-gate and jurisdiction-gate any resale or blockchain-linked functionality.
- Keep World Cup predictions and exchange mechanics clearly separate from gambling.

### 5.4 Retail and Sponsor Reward Partners

Retailers, sponsors, and merchandise partners can integrate without controlling the sticker/card catalog.

Potential use cases:

- QR or code redemption from purchases.
- Digital pack rewards.
- Badge unlocks.
- Coupon issuance.
- Matchday missions.
- Stadium or fan-zone collection drops.

### 5.5 Club, League, and Future Passport Partners

The same partner connector architecture should support future passports:

- Premier League Passport.
- Champions League Passport.
- Club-specific season passports.
- Women’s football tournament passports.
- Youth academy or grassroots football passports.
- Fan rewards ecosystem partners.

---

## 6. Recommended Integration Models

Fan Passport should support multiple integration depths so partners can start small and expand later.

### 6.1 Model A — Deep Link and Attribution

**Description:** Fan Passport links users to partner-owned album, shop, or campaign pages. Attribution is measured through campaign parameters or partner-provided tracking links.

**Best for:**

- Early commercial discussions.
- No sensitive data transfer.
- Low implementation overhead.
- Testing demand before deeper integration.

**Data shared:**

- Campaign source.
- Anonymous click ID.
- Optional regional targeting if user consent and privacy rules allow.

**User experience:**

- “Buy official album packs.”
- “Open partner digital album.”
- “Continue your collection with our partner.”

**Risks:**

- Limited collection functionality.
- Revenue attribution disputes if tracking is weak.
- User may leave Fan Passport.

**Controls:**

- Signed campaign URLs.
- Clear partner disclosure.
- No implied official integration unless contracted.

---

### 6.2 Model B — Partner Campaign Codes

**Description:** Users redeem printed, QR, or digital codes from partner packs, retail receipts, or campaigns to unlock Fan Passport rewards.

**Best for:**

- Physical-to-digital bridge.
- Retail and sponsor activations.
- Viral collecting behavior.
- Controlled reward issuance.

**Data shared:**

- Redemption code hash or token.
- Redemption timestamp.
- Campaign ID.
- Region, if required and consented.
- Pseudonymous Fan Passport user ID.

**User experience:**

- “Enter code from your pack.”
- “Scan matchday collectible QR.”
- “Unlock a Fan Passport sticker pack.”

**Risks:**

- Code guessing.
- Code resale.
- Bulk abuse.
- Counterfeit codes.

**Controls:**

- Signed code batches.
- One-time-use tokens.
- Rate limits.
- Device and account velocity checks.
- Idempotent redemption API.
- Fraud review queue.
- Partner reconciliation reports.

---

### 6.3 Model C — Collection Checklist Sync

**Description:** Partner supplies an official checklist/catalog. Fan Passport stores the user’s collection status against partner item IDs, either manually entered by the user or synced through partner APIs.

**Best for:**

- Album progress display.
- Completion achievements.
- Duplicate tracking.
- Trade matching.

**Data shared:**

- Partner catalog IDs.
- User-owned status.
- Duplicate counts.
- Completion percentages.
- Consent scope.

**User experience:**

- “Mark sticker as collected.”
- “Connect account to sync album progress.”
- “You completed Group B.”
- “You have 14 duplicates available.”

**Risks:**

- Licensed catalog restrictions.
- Artwork usage constraints.
- Sync conflicts.
- Users misrepresenting ownership if manual entry is allowed.

**Controls:**

- Separate “self-reported” and “partner-verified” statuses.
- Clear provenance labels.
- Partner-provided catalog licensing terms.
- Sync audit trail.

---

### 6.4 Model D — Account Linking and Read-Only Inventory

**Description:** User links their Fan Passport account to a partner account using OAuth 2.0 or another approved delegated authorization flow. Fan Passport reads inventory/progress from the partner.

**Best for:**

- Accurate album progress.
- Official completion badges.
- Personalized partner campaigns.
- Reduced manual collection entry.

**Data shared from partner to Fan Passport:**

- Partner collector ID.
- Catalog progress.
- Owned item IDs.
- Duplicate counts if allowed.
- Updated timestamps.
- Verification status.

**Data shared from Fan Passport to partner:**

- Pseudonymous Fan Passport ID.
- Consent record.
- Achievement unlocks if approved.
- Optional public collector profile URL.

**User experience:**

- “Connect your official collection.”
- “Sync complete.”
- “Officially verified: 82% album complete.”

**Risks:**

- OAuth implementation complexity.
- Partner API reliability.
- User confusion about data ownership.
- Revocation and deletion obligations.

**Controls:**

- OAuth 2.0 Authorization Code with PKCE for public clients.
- Server-to-server token exchange.
- Refresh-token encryption.
- Consent dashboard.
- Revocation webhooks.
- Data deletion workflow.
- Least-privilege scopes.

---

### 6.5 Model E — Bidirectional Inventory and Trade Integration

**Description:** Partner and Fan Passport coordinate duplicate listings, trade proposals, exchange confirmations, and inventory updates.

**Best for:**

- Official exchange ecosystem.
- Strongest collection engagement.
- Partner-led verified trading.
- Co-branded virtual album economy.

**Data shared:**

- Duplicate listings.
- Trade availability.
- Proposed exchange items.
- Trade status.
- Inventory deltas.
- Moderation outcomes.
- Fraud signals.

**User experience:**

- “Find collectors with duplicates you need.”
- “Propose an exchange.”
- “Partner-verified exchange complete.”
- “Inventory updated.”

**Risks:**

- Fraud.
- Item disputes.
- Harassment.
- Real-money side deals.
- Minors’ safety.
- Jurisdiction-specific consumer protection rules.
- Scalping or market manipulation if items have monetary value.

**Controls:**

- Structured trade proposals only.
- No default free-form chat.
- Escrow-like pending state for digital items.
- Confirmation from both parties.
- Cooldowns and trade limits.
- Age-based restrictions.
- Abuse reporting.
- Moderation queue.
- Fraud scoring.
- Dispute resolution.
- Partner reconciliation.

---

### 6.6 Model F — Co-Branded Official Virtual Album

**Description:** Fan Passport hosts or embeds an official virtual album experience powered by partner content, rights, and inventory APIs.

**Best for:**

- Flagship partnership.
- High engagement.
- Official sponsor activations.
- Daily pack mechanics.
- Completion leaderboards.

**Data shared:**

- User profile consent.
- Album inventory.
- Pack opening events.
- Achievement events.
- Reward eligibility.
- Partner analytics events.

**User experience:**

- Official co-branded album inside Fan Passport.
- Partner-licensed sticker/card art.
- Group, team, stadium, match, and player collection pages.
- Limited-time challenges.
- Completion rewards.

**Risks:**

- Highest licensing cost.
- Highest operational complexity.
- Strict brand approvals.
- Content embargoes.
- Live tournament updates.
- SLA requirements.

**Controls:**

- Formal content approval process.
- Asset CDN with partner usage controls.
- Rights metadata per asset.
- Content expiration rules.
- Partner staging environment.
- Launch readiness review.
- Incident response plan.

---

## 7. Proposed Panini Integration Roadmap

This roadmap is intentionally staged so Fan Passport can unlock value before attempting a fully official virtual album.

### 7.1 Phase 0 — Partner-Ready Internal Foundation

**Objective:** Prepare Fan Passport for a future Panini partnership without using restricted Panini assets.

Capabilities:

- Partner connector abstraction.
- Consent model.
- Collector profile sharing model.
- Virtual album data model with original Fan Passport items.
- Redemption code framework.
- Public/private profile settings.
- Audit logging.
- Fraud and moderation foundations.
- Partner analytics export design.

Deliverables:

- Partner-facing integration overview.
- API specification.
- Security and privacy questionnaire responses.
- Demo using original Fan Passport collectibles.
- Rights-safe fallback album.

Success criteria:

- FablePool can demonstrate the product without infringing partner IP.
- The architecture is ready for official catalog sync if credentials are supplied.
- Legal/commercial teams can discuss a concrete integration path with Panini.

---

### 7.2 Phase 1 — Deep Links and Campaign Attribution

**Objective:** Drive opt-in Fan Passport traffic to Panini-owned experiences.

Capabilities:

- Campaign link generation.
- Attribution IDs.
- Region-specific partner links.
- Partner disclosure UX.
- Aggregate campaign reporting.

Data exchange:

- Anonymous click ID.
- Campaign ID.
- Timestamp.
- Country/region only where lawful and necessary.

Success criteria:

- Partner can measure referral traffic.
- Fan Passport can measure conversion proxies without collecting purchase details.
- No user account linking required.

---

### 7.3 Phase 2 — Pack or Retail Code Redemption

**Objective:** Connect physical Panini product purchase or campaign participation to Fan Passport rewards.

Capabilities:

- QR/code scanning.
- Code validation through partner API or uploaded signed code batches.
- One-time redemption.
- Reward issuance.
- Fraud review.

Data exchange:

- Hashed redemption code or signed token.
- Campaign ID.
- Pseudonymous user ID.
- Redemption status.
- Fraud status.

Success criteria:

- Users can unlock Fan Passport rewards from partner products.
- Abuse remains below agreed threshold.
- Partner receives reconciliation reports.

---

### 7.4 Phase 3 — Album Progress and Completion Achievements

**Objective:** Allow users to show and celebrate official album progress.

Capabilities:

- Partner catalog import.
- User collection progress sync.
- Completion achievements.
- Public collector profile modules.
- Privacy settings.

Data exchange:

- Partner collector ID.
- Item IDs.
- Owned status.
- Duplicate counts if allowed.
- Completion percentages.
- Consent scopes.

Success criteria:

- Users can display verified album progress.
- Fan Passport can award official completion achievements.
- Users can revoke sharing without breaking core Fan Passport use.

---

### 7.5 Phase 4 — Duplicate Discovery and Trade Matching

**Objective:** Help collectors find fair, safe exchanges for duplicates.

Capabilities:

- Duplicate inventory sync.
- Need-list and have-list matching.
- Structured trade proposals.
- Trade confirmation.
- Moderation and safety controls.
- Partner inventory reconciliation.

Data exchange:

- Available duplicate IDs.
- Wanted item IDs.
- Trade proposal IDs.
- Confirmation events.
- Moderation/fraud flags.

Success criteria:

- Collectors can safely discover exchange opportunities.
- Confirmed trades update inventory correctly.
- Platform prevents obvious abuse patterns and unsafe interactions.

---

### 7.6 Phase 5 — Co-Branded Official Virtual Album

**Objective:** Launch a flagship official digital collecting experience.

Capabilities:

- Partner-licensed assets.
- Official virtual album pages.
- Daily packs and sponsored drops.
- Co-branded achievements.
- Rewards and fulfillment.
- Tournament live operations.
- Leaderboards and collection events.

Data exchange:

- Full agreed event and inventory model.
- Partner analytics.
- Reward eligibility.
- Fulfillment events.
- Rights-managed content delivery.

Success criteria:

- Officially approved co-branded experience.
- Scalable live operations during the tournament.
- Clear value to fans, partner, and FablePool.

---

## 8. Technical Reference Architecture

### 8.1 System Components

```text
+---------------------+          +---------------------------+
| Fan Passport Apps   |          | Partner Experiences       |
| Web / Mobile        |          | Album / Shop / Rewards    |
+----------+----------+          +-------------+-------------+
           |                                   |
           | Fan Passport API                  | Partner API / Webhooks
           v                                   v
+-----------------------------------------------------------+
| Fan Passport Backend                                      |
|                                                           |
|  +-------------------+      +---------------------------+ |
|  | Partner Connector |<---->| Partner API Gateway       | |
|  +---------+---------+      +---------------------------+ |
|            |                                              |
|  +---------v---------+      +---------------------------+ |
|  | Consent Service   |      | Collector Profile Service | |
|  +---------+---------+      +-------------+-------------+ |
|            |                              |               |
|  +---------v---------+      +-------------v-------------+ |
|  | Inventory Service |<---->| Virtual Album Service     | |
|  +---------+---------+      +-------------+-------------+ |
|            |                              |               |
|  +---------v---------+      +-------------v-------------+ |
|  | Trade Service     |      | Achievement Engine        | |
|  +---------+---------+      +-------------+-------------+ |
|            |                              |               |
|  +---------v--------------------------------v-----------+ |
|  | Audit Log / Event Ledger / Fraud Signals / Analytics | |
|  +------------------------------------------------------+ |
+-----------------------------------------------------------+
```

### 8.2 Partner Connector Layer

The Partner Connector layer should isolate partner-specific behavior from core Fan Passport logic.

Responsibilities:

- Partner authentication.
- Token storage and rotation.
- Catalog import.
- Inventory sync.
- Webhook validation.
- Rate-limit handling.
- Retry and backoff.
- Partner-specific error normalization.
- Consent scope enforcement.
- Audit event creation.

Recommended connector interface concepts:

| Capability | Description |
|---|---|
| `partner_identity_link` | Maps Fan Passport user to partner collector account |
| `catalog_import` | Imports partner catalog/checklist metadata |
| `inventory_pull` | Reads user inventory from partner |
| `inventory_webhook` | Receives partner inventory updates |
| `redemption_validate` | Validates pack/retail/campaign codes |
| `reward_fulfillment` | Sends eligibility or fulfillment events |
| `trade_reconcile` | Confirms trade-related inventory deltas |
| `consent_revoke` | Handles revocation and partner unlinking |

### 8.3 Event Ledger

All partner-relevant actions should write immutable audit events.

Examples:

- `partner.account_linked`
- `partner.consent_granted`
- `partner.consent_revoked`
- `partner.catalog_imported`
- `partner.inventory_synced`
- `partner.redemption_attempted`
- `partner.redemption_accepted`
- `partner.redemption_rejected`
- `collector.profile_shared`
- `album.item_collected`
- `album.duplicate_added`
- `trade.proposed`
- `trade.accepted`
- `trade.confirmed`
- `trade.cancelled`
- `trade.flagged`
- `moderation.action_applied`

Audit events should include:

- Event ID.
- Timestamp.
- Actor type.
- Actor ID.
- User ID or pseudonymous subject ID.
- Partner ID where applicable.
- Consent scope where applicable.
- Request correlation ID.
- Result.
- Minimal metadata.

---

## 9. Data Model Alignment

### 9.1 Partner Entity

| Field | Description |
|---|---|
| `partner_id` | Internal stable identifier |
| `partner_name` | Display name |
| `partner_type` | Sticker publisher, card publisher, digital collectible platform, retailer, sponsor, league, club |
| `status` | Proposed, sandbox, active, suspended, retired |
| `supported_capabilities` | Deep links, code redemption, catalog sync, inventory sync, trade reconciliation, rewards |
| `regions` | Regions where partner integration is available |
| `legal_basis` | Contractual and consent basis for data processing |
| `content_rights_profile` | Asset usage rules and restrictions |
| `security_profile` | Auth, webhook, encryption, and audit requirements |

### 9.2 Partner Catalog Item

| Field | Description |
|---|---|
| `partner_item_id` | Partner-provided item identifier |
| `fan_passport_item_id` | Internal mapped ID |
| `album_id` | Album/checklist identifier |
| `collection_id` | Team, group, stadium, match, player, insert set, special set |
| `rarity` | Optional partner-provided rarity/category |
| `display_metadata` | Licensed display fields permitted by contract |
| `asset_rights` | Allowed art/image usage |
| `availability_window` | Start/end availability where applicable |
| `verification_source` | Partner, user self-report, Fan Passport original |

### 9.3 Collector Inventory Item

| Field | Description |
|---|---|
| `user_id` | Fan Passport user |
| `partner_id` | Optional partner source |
| `item_id` | Internal item ID |
| `partner_item_id` | Optional partner item ID |
| `ownership_status` | Needed, collected, duplicate, reserved, traded, removed |
| `quantity` | Count owned |
| `duplicate_quantity` | Count available above one owned copy |
| `verification_status` | Self-reported, partner-verified, Fan Passport-issued |
| `last_synced_at` | Last partner sync timestamp |
| `source_event_id` | Audit event that last updated state |

### 9.4 Public Collector Profile

| Field | Description |
|---|---|
| `profile_id` | Public-safe profile identifier |
| `display_name` | User-controlled display name |
| `avatar` | Approved avatar or generated image |
| `country_support` | Optional supported country/team display |
| `collection_summary` | Completion percentages and counts |
| `featured_items` | User-selected items |
| `badges` | User-selected achievements |
| `trade_preferences` | Optional safe exchange preferences |
| `visibility` | Private, link-only, friends-only, public |
| `partner_badges` | Verified partner achievements where licensed |

---

## 10. Authentication and Authorization Strategy

Detailed endpoint-level API authentication will be defined in the collector profile sharing API specification. The integration plan recommends the following standards.

### 10.1 User Account Linking

Preferred approach:

- OAuth 2.0 Authorization Code with PKCE.
- Partner-hosted authorization page.
- Fan Passport never sees the partner password.
- Refresh tokens encrypted at rest.
- Scope-based consent.
- Token revocation support.

Fallback approaches only if partner cannot support OAuth:

- Signed one-time linking codes.
- Magic-link verification from partner account.
- Partner-issued collector token with short expiration.

Avoid:

- Password sharing.
- Screen scraping.
- Browser automation.
- Manual upload of partner account exports containing excessive personal data.

### 10.2 Server-to-Server Partner APIs

Recommended approaches:

- OAuth 2.0 Client Credentials for server-to-server access.
- Mutual TLS for high-risk write operations.
- HMAC-signed webhooks.
- IP allowlisting where partner infrastructure supports it.
- Rotating API keys only for lower-risk integrations, and only with expiration.

### 10.3 Authorization Scopes

Suggested partner scopes:

| Scope | Meaning |
|---|---|
| `collector.profile.read` | Read user-approved partner profile basics |
| `collector.profile.write` | Update partner-visible profile link or metadata |
| `collection.catalog.read` | Read partner catalog/checklist |
| `collection.inventory.read` | Read user collection inventory |
| `collection.inventory.write` | Write inventory changes, only where contractually approved |
| `collection.duplicates.read` | Read duplicate counts |
| `collection.trade.write` | Submit trade confirmation or reconciliation |
| `campaign.redemption.write` | Validate or submit redemption codes |
| `rewards.fulfillment.write` | Send reward eligibility or fulfillment event |
| `analytics.aggregate.read` | Read aggregate performance reports |

---

## 11. Consent and Privacy Design

### 11.1 Consent Moments

Users should be prompted for consent at the moment of action, not buried in general terms.

Consent moments:

- Connecting a partner account.
- Sharing a collector profile publicly.
- Sharing profile with a specific partner.
- Displaying partner-verified album progress.
- Making duplicate inventory discoverable.
- Sending or accepting a trade proposal.
- Redeeming partner campaign codes.
- Receiving partner marketing, if offered.

### 11.2 Consent Copy Requirements

Consent screens should explain:

- Who receives the data.
- What data is shared.
- Why it is shared.
- Whether sharing is required or optional.
- How long sharing lasts.
- How to revoke it.
- Whether partner terms also apply.

Example user-facing consent summary:

> “Connect your collector account so Fan Passport can read your album progress and duplicate counts. We will not share your email, predictions, friends list, or private memories with the partner unless you choose to share them separately. You can disconnect this account at any time.”

### 11.3 Default Privacy Settings

Recommended defaults:

| Feature | Default |
|---|---|
| Collector profile visibility | Private |
| Public album completion | Off |
| Featured items | User-selected only |
| Duplicate discoverability | Off |
| Trade requests from strangers | Off for minors; optional for adults |
| Free-form messages | Disabled by default |
| Partner marketing | Off |
| Share email with partner | Off |
| Show exact location | Never |
| Show age/date of birth | Never |

### 11.4 Minors and Age-Appropriate Design

For users identified as minors under applicable law:

- Default profile visibility should be private.
- Public search discovery should be disabled.
- Trade proposals should be limited or require guardian-approved settings.
- No free-form direct messaging with unknown users.
- No sharing of email, phone, exact location, school, or date of birth.
- No partner marketing without required consent.
- Stronger reporting and moderation review for interactions.
- Clear guardian controls where the product supports child accounts.

### 11.5 Deletion and Revocation

When a user disconnects a partner:

- Stop future sync immediately.
- Revoke partner tokens if possible.
- Mark partner-synced inventory as disconnected.
- Preserve audit records only as legally required.
- Remove public partner verification badges if verification can no longer be confirmed, or label them as historical if contractually permitted.
- Send revocation event to partner if required.
- Honor deletion requests under applicable privacy laws.

---

## 12. Content Rights and Brand Approval

### 12.1 Rights Inventory

Before launching official partner content, FablePool should maintain a rights inventory covering:

- Sticker/card artwork.
- Player images.
- Team crests.
- National federation marks.
- FIFA marks.
- Tournament marks.
- Stadium names and imagery.
- Pack and album artwork.
- Partner logos.
- Sponsor logos.
- Editorial copy.
- Audio/video assets.
- User-generated media rules.

### 12.2 Asset Metadata

Every licensed asset should include:

| Field | Description |
|---|---|
| `asset_id` | Internal asset identifier |
| `licensor` | Rights holder |
| `partner_id` | Partner providing asset |
| `usage_contexts` | App, web, email, social sharing, paid ads, partner pages |
| `allowed_regions` | Geographic usage rights |
| `start_at` / `end_at` | Rights window |
| `approval_status` | Draft, submitted, approved, rejected, expired |
| `attribution_required` | Required copyright/trademark text |
| `derivative_allowed` | Whether cropping, animation, or overlays are allowed |
| `shareable` | Whether users can share externally |
| `removal_required_after_expiry` | Whether asset must be removed or hidden |

### 12.3 Brand Approval Workflow

Recommended approval flow:

1. FablePool drafts partner campaign or virtual album feature.
2. Internal product/legal review confirms scope.
3. Partner reviews UX, copy, art usage, and data flows.
4. Security/privacy review confirms consent and data processing.
5. Approved assets are locked by version.
6. Launch package is archived.
7. Any post-launch material changes require re-approval.

---

## 13. Inventory Sync Strategy

### 13.1 Sync Modes

| Mode | Description | Best Use |
|---|---|---|
| Manual self-report | User marks items collected | Unpartnered fallback, early MVP |
| Code-verified | Item/pack is unlocked via code | Campaign rewards |
| Partner pull sync | Fan Passport periodically reads partner inventory | Account linking |
| Partner webhook sync | Partner sends updates as inventory changes | Near real-time official sync |
| Bidirectional sync | Fan Passport and partner both write approved changes | Official trade/exchange integration |

### 13.2 Provenance Labels

Each inventory item should have a visible provenance label:

- **Fan Passport Original**
- **Self-Reported**
- **Code-Verified**
- **Partner-Verified**
- **Partner-Synced**
- **Trade Pending**
- **Trade Confirmed**

This prevents confusion between official collection state and user-managed collection planning.

### 13.3 Conflict Handling

Potential conflict examples:

- Partner reports item quantity `1`; Fan Passport self-report says `2`.
- User marks duplicate as available, but partner sync removes it.
- Trade proposal reserves an item that is later consumed elsewhere.
- Partner catalog changes item ID or retires item.

Recommended resolution:

- Partner-verified inventory has priority over self-reported inventory for official achievements.
- Self-reported data remains available as personal notes unless user chooses to overwrite it.
- Reserved trade items enter a pending state and cannot be offered twice.
- Conflicts are logged and surfaced to the user in plain language.
- Official catalog changes should be versioned, not overwritten destructively.

---

## 14. Virtual Album Strategy

### 14.1 Rights-Safe Fallback Album

Before any official sticker/card partnership, Fan Passport can operate a rights-safe virtual album using original collectibles:

- Country journey stamps using generic national colors or original iconography where lawful.
- Stadium visit badges using original illustrations or non-infringing metadata.
- Match memory cards generated from user activity.
- Prediction badges.
- Trivia badges.
- Challenge completion cards.
- Tournament milestone items.
- Fan-created memory cards with moderation.

These should avoid official sticker layouts, official card designs, player likenesses, team crests, and protected tournament marks unless licensed.

### 14.2 Partner-Enhanced Album

With partner approval, Fan Passport can add:

- Official collection checklist.
- Partner item IDs.
- Official completion progress.
- Licensed sticker/card thumbnails.
- Partner-branded pack rewards.
- Co-branded album pages.
- Partner-verified collection achievements.
- Official duplicate exchange rules.

### 14.3 Album Completion Achievements

Examples:

| Achievement | Trigger |
|---|---|
| First Sticker | User collects first album item |
| Group Complete | User completes all items in a group/set |
| Stadium Collector | User collects all stadium items |
| Matchday Memory | User unlocks item for attending/watching a match |
| Daily Trivia Streak | User earns daily quiz reward item |
| Verified Collector | User links a partner-verified album |
| Duplicate Dealer | User completes a safe item exchange |
| Album Legend | User completes an official or Fan Passport album |

For official achievements, badge names, logos, and reward wording must be approved by the partner if they reference partner IP.

---

## 15. Exchange Platform Readiness

A detailed exchange platform design will be provided separately. The partner integration plan requires the following readiness principles.

### 15.1 Exchange Types

| Exchange Type | Description | Partner Dependency |
|---|---|---|
| Social discovery | See collectors with matching wants/haves | Optional |
| Self-reported trade | Users record an offline exchange | No official inventory write |
| Fan Passport digital trade | Exchange Fan Passport-issued virtual items | No external partner needed |
| Partner-verified trade | Partner inventory is updated after confirmation | Requires partner API |
| Reward-based exchange | Trade leads to coupon/reward eligibility | Requires sponsor/partner rules |

### 15.2 Safety Controls

Minimum controls:

- Structured offers.
- No default free-form chat.
- Report/block tools.
- Trade cooldowns.
- Duplicate reservation.
- Confirmation by both users.
- Fraud scoring.
- Moderation escalation.
- Age-based restrictions.
- No public display of personal address or exact location.
- No encouragement of cash side payments.

### 15.3 Partner Trade Reconciliation

For official inventory-affecting trades:

1. User A proposes exchange.
2. User B accepts.
3. Items are reserved in Fan Passport.
4. Partner inventory availability is checked.
5. Both users confirm.
6. Partner API applies inventory delta or confirms external exchange.
7. Fan Passport marks trade confirmed.
8. Audit event and user notifications are generated.
9. Any mismatch moves the trade to dispute or cancelled state.

---

## 16. Partner Analytics and Reporting

### 16.1 Aggregate Metrics

Partner dashboards or exports may include:

- Campaign impressions.
- Partner link clicks.
- Account link starts.
- Account link completions.
- Code redemption attempts.
- Successful redemptions.
- Album sync opt-ins.
- Collection completion distribution.
- Achievement unlock counts.
- Trade proposal counts.
- Trade completion rates.
- Fraud rejection counts.
- Region-level engagement where legally permitted.
- Daily/weekly active collectors.

### 16.2 User-Level Data Restrictions

User-level reporting should be avoided unless necessary for fulfillment, fraud prevention, or contractual partner account linking.

Default not shared:

- Email.
- Phone.
- Exact location.
- Full birthdate.
- Private memories.
- Private predictions.
- Friend graph.
- Device fingerprint.
- Raw IP address.
- Free-form reports or moderation notes unless required for safety/legal action.

### 16.3 Privacy-Safe Identifiers

Use:

- Pseudonymous partner subject IDs.
- Per-partner user aliases.
- Rotating campaign click IDs.
- Hashed redemption code references.
- Aggregated cohorts.

Avoid:

- Reusing one universal cross-partner tracking ID.
- Sharing raw internal user IDs externally.
- Combining child data into marketing cohorts.

---

## 17. Commercial Models

### 17.1 Referral and Affiliate

Fan Passport drives traffic to partner shops or album apps.

Revenue options:

- Cost per click.
- Cost per acquisition.
- Revenue share.
- Fixed campaign sponsorship.

Best suited for early partnership phases.

### 17.2 Campaign Sponsorship

Partner sponsors challenges, pack drops, or album missions.

Revenue options:

- Fixed sponsorship.
- Sponsored placement.
- Reward issuance fee.
- Campaign production fee.

### 17.3 Code Redemption Licensing

Physical packs or retail purchases unlock Fan Passport rewards.

Revenue options:

- Per-code platform fee.
- Batch activation fee.
- Campaign management fee.
- Fraud/reconciliation reporting fee.

### 17.4 Official Virtual Album Licensing

Fan Passport hosts a co-branded official album.

Revenue options:

- Licensing fee.
- Revenue share on digital packs.
- Sponsored pack drops.
- Premium passport upgrade.
- Partner-funded live operations.
- Reward fulfillment partnership.

### 17.5 Exchange Platform Fee

If allowed by law and partner terms, Fan Passport may charge for premium discovery or convenience features. The recommended initial approach is **not** to charge per trade, to reduce regulatory and user-trust risk.

Allowed lower-risk monetization:

- Premium profile cosmetics.
- Verified collector badge sponsorship.
- Optional album analytics.
- Sponsor-funded rewards.
- Non-monetary challenge boosts.

Avoid or heavily review:

- Cash marketplace fees.
- Loot-box-style paid packs.
- Real-money item speculation.
- Gambling-adjacent prediction rewards.
- Trade mechanics targeted at children with monetized pressure.

---

## 18. Legal and Compliance Considerations

### 18.1 Licensing

Confirm rights for:

- Official sticker/card art.
- Album structure.
- Player likeness.
- National team marks.
- FIFA marks.
- Stadium imagery.
- Tournament data.
- Use in social sharing.
- Use in paid media.
- Use in app store screenshots.
- Use after tournament ends.

### 18.2 Privacy Laws

Design should support compliance with:

- GDPR and UK GDPR.
- EU Digital Services Act considerations for marketplace/community features.
- COPPA where applicable.
- Age Appropriate Design Code where applicable.
- CCPA/CPRA where applicable.
- Regional child privacy and consumer protection laws.
- Data processing agreements with partners.

### 18.3 Consumer Protection

Relevant areas:

- Paid packs.
- Randomized rewards.
- Scarcity claims.
- Expiration of rewards.
- Trade disputes.
- Misleading official endorsement.
- User-generated offers.
- Refund rights where purchases exist.

### 18.4 Platform Terms

App stores and payment providers may restrict:

- Paid randomized digital collectibles.
- Blockchain/NFT features.
- External purchase links.
- User-to-user trading.
- Child-directed monetization.
- Real-money marketplace mechanics.

### 18.5 Tax and Fulfillment

If physical rewards, coupons, or sweepstakes are involved:

- Confirm eligibility rules by region.
- Define tax responsibilities.
- Establish fulfillment SLAs.
- Maintain reward inventory reconciliation.
- Avoid illegal lotteries or contests.

---

## 19. Security Requirements

### 19.1 Baseline Controls

- TLS everywhere.
- Encrypted partner tokens.
- Strict secret management.
- Role-based internal access.
- Least-privilege partner scopes.
- HMAC-signed webhooks.
- Replay protection.
- Idempotency keys.
- Rate limiting.
- Audit logging.
- Anomaly detection.
- Data retention limits.
- Secure deletion workflows.

### 19.2 Redemption Fraud Controls

- Cryptographically signed redemption tokens where possible.
- Partner-supplied code batches transmitted securely.
- Store hashed codes rather than raw codes after validation.
- Prevent brute-force code attempts.
- Device/account/IP velocity checks.
- Campaign-specific redemption caps.
- Suspicious pattern review.
- Reconciliation exports to partner.

### 19.3 Trade Fraud Controls

- Duplicate reservation.
- Inventory verification before confirmation.
- Trade cooldowns.
- Risk scoring by account age, velocity, report history, and mismatch rate.
- Moderation escalation.
- Dispute states.
- Reversal policy where technically possible.
- No hidden item substitution.
- Clear offer summaries before confirmation.

### 19.4 Webhook Security

- Partner-specific signing secrets.
- Timestamp tolerance.
- Nonce or event ID replay detection.
- Signature verification before parsing business logic.
- Idempotent event handling.
- Dead-letter queue for repeated failures.
- Partner-visible delivery logs where appropriate.

---

## 20. Operational Model

### 20.1 Partner Onboarding Stages

| Stage | Description | Exit Criteria |
|---|---|---|
| Proposed | Business discussion and integration fit | Mutual interest and rights path identified |
| Design | Data flows, legal basis, UX, and scope defined | Signed implementation plan |
| Sandbox | Credentials and test environment enabled | Test cases pass |
| Pilot | Limited user/region/campaign launch | KPI and incident review accepted |
| Production | Full rollout | Operational SLAs active |
| Expansion | Additional campaigns/features | Change approval completed |
| Suspension | Integration paused for legal/security/product reason | Risk resolved or integration retired |

### 20.2 Launch Readiness Checklist

A partner integration should not go live until the following are complete:

- Signed commercial agreement.
- Data processing agreement where required.
- Security review.
- Privacy review.
- Content rights review.
- Brand approval.
- Support playbooks.
- Incident response contacts.
- Sandbox test completion.
- Load/rate-limit test completion.
- Consent screens approved.
- User-facing help center content.
- Rollback plan.
- Monitoring dashboards.
- Fraud thresholds configured.
- Moderation workflows active.

### 20.3 Support Responsibilities

Define ownership for:

| Issue Type | Fan Passport | Partner |
|---|---:|---:|
| Fan Passport account access | Primary | Supportive |
| Partner account access | Supportive | Primary |
| Album catalog errors | Shared | Shared/Primary if official |
| Code redemption failure | Shared | Shared |
| Reward fulfillment | Shared | Primary if partner reward |
| Trade dispute | Primary for Fan Passport trades | Shared for partner inventory |
| Fraud investigation | Shared | Shared |
| Privacy deletion request | Primary for Fan Passport data | Primary for partner data |
| Licensed asset takedown | Primary execution | Primary approval |

---

## 21. Rate Limits and Reliability Expectations

Endpoint-specific limits will be defined in the API specification. Partner planning should assume:

### 21.1 Fan Passport API Targets

| Integration Type | Suggested Limit |
|---|---:|
| Public collector profile reads | 120 requests/minute per IP or client |
| Authenticated user profile reads | 300 requests/minute per user |
| Partner catalog sync | Contract-specific batch windows |
| Inventory sync pull | 60 requests/minute per partner tenant unless raised |
| Redemption validation | 30 attempts/minute per user; stricter per code prefix |
| Trade proposal actions | 20 actions/hour per user initially |
| Webhook ingestion | Burstable with queue-based backpressure |

### 21.2 Reliability Targets

Suggested production targets:

| Component | Target |
|---|---:|
| Public profile API | 99.9% monthly availability |
| Inventory sync | 99.5% monthly availability |
| Code redemption | 99.9% during campaign windows |
| Trade proposal creation | 99.5% monthly availability |
| Partner webhook ingestion | 99.9% receiving availability with async processing |
| Analytics exports | Daily delivery by agreed time |

### 21.3 Degraded Mode

If partner systems are unavailable:

- Fan Passport should continue to load core passport features.
- Partner inventory should display last synced time.
- Redemption attempts may be queued only if partner agreement allows delayed validation.
- Trade confirmation that requires partner verification should pause rather than guess.
- Users should see clear status messages.

---

## 22. User Experience Requirements

### 22.1 Partner Connection Flow

Recommended flow:

1. User opens “Connect Official Collection.”
2. Fan Passport explains partner, data scopes, and benefits.
3. User starts partner authorization.
4. Partner authenticates user.
5. User approves requested scopes.
6. Fan Passport confirms connection.
7. Initial sync runs.
8. User chooses what to display publicly.
9. User can manage connection from settings.

### 22.2 Public Collector Profile

Profile should support:

- Display name.
- Avatar.
- Country/team support display where rights-safe.
- Collection completion summary.
- Featured items.
- Badges.
- Favorite match memories.
- Trade availability toggle.
- Share link.
- Report profile button.
- Privacy explanation.

### 22.3 Duplicate Discovery

Discovery should show:

- Items you need.
- Collectors who have duplicates.
- Items they want in return.
- Verification label.
- Trade safety score or trust indicators.
- Region/country only at broad level if useful and consented.
- No exact location.

### 22.4 Trade Proposal UX

A trade proposal should include:

- Items offered.
- Items requested.
- Verification status.
- Expiration time.
- Whether inventory will be reserved.
- Whether partner inventory will update.
- Warning against cash/off-platform side deals.
- Report/cancel controls.

---

## 23. Risk Register

| Risk | Severity | Likelihood | Mitigation |
|---|---:|---:|---|
| No official Panini agreement | High | Medium | Maintain rights-safe Fan Passport original album; keep Panini plan proposed |
| IP infringement | High | Medium | Rights inventory, legal review, no official assets without license |
| Partner API unavailable during tournament | High | Medium | Queueing, degraded mode, SLAs, incident contacts |
| Redemption code fraud | High | High | Signed codes, rate limits, velocity checks, audits |
| Trade scams | High | Medium | Structured trades, reservation, moderation, fraud scoring |
| Unsafe minor interactions | High | Medium | Age-based restrictions, no free-form chat, privacy defaults |
| Data over-sharing | High | Medium | Consent scopes, minimization, privacy review |
| User confusion between official and self-reported | Medium | High | Provenance labels and clear UI copy |
| Commercial model conflicts with app stores | Medium | Medium | Early platform policy review |
| Partner catalog changes late | Medium | Medium | Versioned catalogs and mapping tools |
| Region-specific legal restrictions | Medium | Medium | Regional feature flags and legal review |
| Marketplace regulatory exposure | High | Low/Medium | Avoid cash marketplace at launch |

---

## 24. Metrics of Success

### 24.1 User Engagement

- Partner account connection rate.
- Album completion interactions per user.
- Daily pack/code redemption rate.
- Public profile share rate.
- Duplicate list creation rate.
- Trade proposal completion rate.
- Challenge participation tied to collections.
- Return frequency for collectors versus non-collectors.

### 24.2 Partner Value

- Referral clicks.
- Redemption volume.
- Verified album sync opt-ins.
- Co-branded achievement unlocks.
- Reward conversions.
- Aggregate collection progress.
- Campaign lift versus baseline.
- Repeat engagement from partner-connected users.

### 24.3 Safety and Trust

- Fraud rejection rate.
- False positive fraud rate.
- Trade dispute rate.
- Moderation response time.
- Report volume per active trading user.
- Consent revocation rate.
- Support contacts per 1,000 collector actions.
- Minor safety incident rate.

### 24.4 Technical Health

- Partner API error rate.
- Inventory sync success rate.
- Webhook processing latency.
- Redemption validation latency.
- Trade confirmation latency.
- Queue backlog.
- Rate-limit events.
- Data reconciliation mismatches.

---

## 25. Partner Onboarding Package

FablePool should prepare a partner onboarding package containing:

1. Product overview.
2. Rights-safe demo environment.
3. Proposed integration models.
4. API specification.
5. Security architecture summary.
6. Privacy and consent summary.
7. Data processing overview.
8. Example user journeys.
9. Campaign options and commercial models.
10. Sandbox test plan.
11. Operational support model.
12. Moderation and safety policy.
13. Fraud prevention controls.
14. Reporting examples.
15. Launch timeline.

---

## 26. Recommended First Partner Pitch

### 26.1 Positioning

> “Fan Passport turns World Cup collecting into a daily digital journey. We can help official sticker and card partners increase engagement, drive album completion, activate physical packs digitally, and give collectors privacy-safe ways to showcase and exchange their collections.”

### 26.2 Proposed Starting Point

The recommended initial Panini-style proposal is **Model B + Model C**:

- Partner campaign code redemption.
- Official checklist/catalog import.
- User album progress display.
- Completion achievements.
- Aggregate reporting.

This offers strong fan value without immediately requiring full bidirectional trade infrastructure.

### 26.3 Expansion Path

If the pilot succeeds:

1. Add account linking and read-only inventory sync.
2. Add duplicate discovery.
3. Add structured trade proposals.
4. Add official partner-verified exchange reconciliation.
5. Launch a co-branded official virtual album.

---

## 27. Implementation Roadmap

### 27.1 Immediate Product Work

Build and validate:

- Partner connector abstraction.
- Consent and revocation service.
- Collector profile visibility settings.
- Rights-safe virtual album.
- Inventory provenance labels.
- Public profile share links.
- Redemption code framework.
- Event ledger.
- Rate limiting and audit logging.
- Moderation/reporting primitives.

### 27.2 Partner-Dependent Work

Begin only after agreement and credentials:

- Partner OAuth/account linking.
- Partner catalog ingestion.
- Partner inventory sync.
- Licensed asset ingestion.
- Partner webhooks.
- Official achievement unlocks.
- Trade reconciliation.
- Partner reporting exports.
- Co-branded UX and content approval.

### 27.3 Pilot Launch Shape

A practical first pilot:

- One region.
- One partner campaign.
- One album/checklist.
- Code redemption.
- Completion badges.
- Public collector profile sharing.
- Aggregate reporting.
- No official bidirectional trading in first pilot unless partner already has mature inventory APIs.

### 27.4 Production Expansion Shape

After pilot:

- Multi-region.
- Multiple campaigns.
- Account linking.
- Inventory sync.
- Duplicate tracking.
- Trade discovery.
- Partner rewards.
- Live ops calendar tied to matchdays.
- Daily trivia/pack drops.

---

## 28. Acceptance Criteria for This Integration Plan

This artifact is considered complete because it defines:

- Proposed Panini integration strategy without implying an active agreement.
- Integration models for other sticker/card and collectible partners.
- Staged rollout path from low-risk links to official virtual album.
- Technical architecture and connector responsibilities.
- Data model alignment for partner catalog, inventory, and collector profiles.
- Consent, privacy, minors, and revocation requirements.
- Content rights and brand approval process.
- Inventory sync and provenance strategy.
- Exchange-readiness principles.
- Commercial models.
- Legal, security, operational, rate-limit, and reliability considerations.
- Partner onboarding package and recommended first pitch.

The next milestone artifact should specify the collector profile sharing API in detail, including endpoint definitions, schemas, authentication, authorization, privacy handling, rate limits, and error formats.