Frequently Asked Questions

Quick answers on the left. Deeper technical overview on the right for anyone who wants to understand how MintKit works.

Getting started

Do my customers need a MintKit account?

Short answer: No. Customers use your public storefront and open their card/ticket in a normal browser (phone or desktop).

Do I need crypto, a wallet, or to buy tokens?

Short answer: No. The goal is a normal SaaS-style experience. Any blockchain complexity stays behind the scenes.

What is the difference between MintKit Hub and MintKit Studio?

Short answer: Hub is the website for accounts, storefront and subscriptions. Studio is the separate app where digital products are created and managed.

Payments and plans

How do plans work in this college project?

Short answer: A Free Trial is shown first, then a Basic plan. A Pro tier is displayed as “coming soon” to show the roadmap.

Note: Stripe wiring is represented in the UI, with full billing flows intended for a later phase.

What happens when the free trial ends?

Short answer: Upgrading keeps full access. Without an active plan, editing/creating in Studio is intended to be limited or paused.

How do customers pay?

Short answer: The intended flow is Stripe checkout in normal currency, then the customer receives access to the purchased digital product.

Storefront and redemption

Can the storefront be hidden while setting up?

Short answer: Yes. Keep it inactive while building, then switch it on when ready.

What happens when a customer buys a card or ticket?

Short answer: The customer completes payment, then receives access (typically via an email link) to view and use their card/ticket.

Planned: email delivery + QR scan redemption flows.

Can tickets be restricted by time, person, or location?

Short answer: Not fully in the current submission. This is part of the longer-term roadmap (time windows, identity linking, geo-hints).

Technical overview

A deeper look at how MintKit Hub (Web2) and MintKit Studio (ICP/Web3) fit together. Some items are roadmap features for the full SaaS version.

Architecture at a glance

MintKit Hub (this site): Django dashboard for business profile, storefront layout, and plan UI. Stores settings in a traditional DB.
MintKit Studio (separate app): Internet Computer canisters handle minting logic, on-chain records, and card redemption flows.
Public delivery: cards can be shared via a link + QR/manual code, with public assets served from IC HTTP gateways/boundary nodes.

Goal: Hub stays simple for everyday users; Studio handles blockchain-grade integrity and long-term extensibility.

Identity, principals & access control

Internet Identity (II): users authenticate and act as a principal (IC identity).
Roles: access can be controlled by role (owner/admin/creator) so only authorised principals can mint, edit collections, or manage settings.
Auditability: actions can be attributed to a principal, which helps with traceability (who minted, who edited, who redeemed).

Roadmap: richer permissions (staff roles per storefront, scoped access per collection, optional “read-only” support accounts).

On-chain data model (what gets stored)

Collections: groups of cards (gift cards / tickets / vouchers) with limits and metadata.
Card templates: design/layout settings (backgrounds, text positions, styles) used to generate card outputs.
Mint records: created items can store references like public image URL, public metadata URL, plus redemption fields (QR/manual codes).
Redemption events (optional): append-only logs for “redeemed / when / by which method”, useful for reporting and dispute resolution.

IC canisters are designed to be upgraded; stable storage patterns help preserve critical records across upgrades.

Assets, thumbnails & public URLs

Card images: stored and served via IC-compatible asset hosting (asset canister / gateway approach).
Metadata: JSON metadata can be published alongside images (useful for wallets, explorers, and future integrations).
Performance: public assets can be cached at the edge (boundary nodes), keeping loads fast for customers.

Roadmap: signed URLs / access rules for “private previews”, plus optional encryption for sensitive payloads.

Redemption flow (QR + manual code)

Two methods: QR scanning for speed + manual code as a fallback (useful for damaged prints or low light).
State machine: valid → redeemed (or expired/void), preventing double-spend style re-use.
Staff tooling: scanner view can validate and mark redeemed with clear feedback.

Roadmap: “dynamic QR” (rotating codes) for stronger anti-screenshot protection, plus offline redemption modes for venues with poor signal.

Payments roadmap (Stripe + beyond)

Hub subscriptions: Stripe plans (free trial → paid tier) for access control and limits.
Transaction fees: optional platform fee per sale (real SaaS model; currently simplified for the college version).
Micropayments (x402): future option to support pay-per-action APIs (e.g., pay per mint / pay per redemption verification) using HTTP-402 style flows.

For the project submission: pricing UI demonstrates a realistic model even if billing automation is staged.

Privacy & security roadmap (VetKeys, VC, geolocation)

VetKeys: threshold-style key derivation for encrypting sensitive data while keeping verifiable on-chain state.
Verifiable Credentials: prove “this is a real business / verified organiser” without exposing unnecessary personal info.
Geolocation rules: optional constraints for redemptions (example: only redeem at venue / region), with careful UX so it doesn’t block legitimate customers.

These are advanced features and presented clearly as roadmap items until implemented.

Operational notes

ICP canisters run on cycles (compute budget). Production readiness includes monitoring, upgrade strategy, sensible limits, and clear separation between “Hub settings” and “Studio minting/redemption” responsibilities.