Phone card and offer experience

Draft, 18 September 2026 · QR Coupon Journeys. Architecture · Coupon terms · Payment setup.

The sender needs a card that opens quickly and scans easily. The recipient needs to recognize the site, understand the offer, and know exactly what happens when they provide a payment method. Use a calm indigo identity, a white high-contrast QR panel, concise headings and one primary action per stage. Keep provider marks and wallet buttons in their official components.

The interactive design source is a nonfunctional mockup. Its illustrative QR cannot activate an offer; its example date uses 18 September 2026 as the activation date. No payment credentials or network calls are used.

1. Sender's phone card

MeshWeaver                         Share

Your invitation
to learn.

Personal plan · up to 90 days
COURSES3M

┌─────────────────────────────┐
│                             │
│         LARGE QR            │
│                             │
└─────────────────────────────┘
Scan to sign in and claim your offer
memex.meshweaver.cloud

Nothing charged today. Plenty of free content.
Approve each purchase. Choose renewal separately.

[ Install on iPhone / Android ]
[ Copy link ]       [ Share ]

The hostname above is the initial design example, not an authorization to publish there. Actual cards display their validated configured destination. The signed-in card is a reusable campaign card; it contains no sender email, recipient identity, payment data or single-use login token. The same reusable GUID remains behind the home-screen icon and QR until revoked.

Show the exact claim deadline and computed offer rules below the main card. Display the current coupon wording “Up to 90 days, ending no later than 31 December 2026.” Do not make an unconditional “3 months free” promise near the end of the campaign. A revoked/expired card replaces the QR with a clear unavailable state, and Copy/Share are disabled. The publisher's management action is separate from the public card.

Use a real server-generated QR in implementation, at least 240 CSS pixels at common phone widths, with the required four-module quiet zone, error correction suited to screen display and no decorative logo covering the code. Keep the QR black on white in both themes. Test actual cameras at normal brightness and typical meeting distance. Include a textual URL and Copy link so a person can use it without a camera. QR fullscreen is an optional accessible mode, not a second URL.

An anonymous scanner sees the ordinary destination-site login gateway, not the protected offer data. A neutral heading can say “Sign in to continue your invitation”. Offer Create account and Sign in at equal clarity, then continue automatically to the same offer after verification/onboarding. Do not ask users to re-enter the coupon code. The reusable card page itself also requires sign-in when launched on a logged-out phone.

Do not insert registration marketing consent into the required payment-method consent. Explain method collection on the offer and in any public campaign material so the requirement is not a surprise after account creation.

3. Prefilled offer

Your learning offer is ready
COURSES3M applied

Personal plan · up to 90 days
For an activation today: access through 17 December 2026

Your name    [ from your profile, editable ]
Email        [ your verified account email ]
Course       [ selected course, when specified ]

Your card will not be charged to activate this offer.
There is plenty of free content to explore.
Some items require payment. You approve each purchase
individually.

Save a payment method for purchases you choose later.

[ Apple Pay ]
[ Google Pay ]
[ Card via Stripe ]

□ Save this payment method for purchases I confirm.

Keep learning after your offer ends (optional)
□ Renew my Personal plan from {date} at {price}/{period}.
  I authorize these recurring payments until I cancel.
  Cancel before {date/time} to avoid the first payment.

[ Save payment method & activate offer ]
Due today: 0

The implementation derives all dates, currency and due-today amounts server-side. The example is illustrative, not a hard-coded term. Account email changes use the platform's existing verified-email flow; editable billing email, if needed, is labeled separately and never changes claim identity. Do not demand a full billing address when the provider/setup policy does not require it.

Show the no-charge paragraph above the wallet/card choice. Repeat “Due today: 0 · No automatic renewal” at the final confirmation when renewal is not selected. When selected, use “Due today: 0 · Then / from until cancelled” and “Activate offer & approve renewal”. Avoid urgency timers, hidden paid continuations, prechecked consent, misleading savings claims and automatically selected paid extras. If method storage is required, say “A payment method is required to activate this offer” plainly and offer Back/Cancel; do not call this optional.

The renewal checkbox starts unchecked and is independent of method storage. The mockup includes its checked state to show the user's approved choice. Explain the benefit in concrete terms: “Keep your Personal plan without interruption after the offer ends.” The exact price, currency, billing interval, first charge date and cancellation terms sit beside the checkbox, not in a tooltip. The checkbox authorizes the named subscription's subsequent recurring payments; it does not authorize unrelated purchases. Changes to price, duration or feature choice require fresh review. Do not frame payment collection solely as convenience for paid catalog items when renewal is selected: say “Your saved method will also pay for the renewal you chose.”

Consent must be accepted before any wallet sheet or card setup can start. Wallet controls have their provider-defined label; the surrounding text explains that this is saving a method, not making a purchase. Show three choices in the design; at runtime show native wallet controls only when eligible. Where a wallet cannot be used, show a small noninteractive row explaining why when known, e.g. “Apple Pay is not available in this browser”, alongside the working card option. Never draw a fake Apple Pay/Google Pay button that opens a generic checkout.

Stripe processes all three methods. Card via Stripe is the requested third choice, not an independent processor competing with the wallets. Brand marks, wallet sheets, verification disclosures and method-saving limits follow the provider specification. A bank may show a temporary verification hold; do not describe that as an activation charge or promise that no bank-side authorization can ever appear.

4. Success and recovery

Success copy: “Your offer is active. Nothing was charged today.” Then show the exact plan end date, the selected course/curriculum or Explore courses, and Manage saved payment method. Without renewal show “No automatic renewal.” With renewal show “You approved renewal at / from ” and an equally accessible Manage or cancel renewal link. Keep “Each separate purchase needs your confirmation” close to billing settings; explain that scheduled subscription charges follow the mandate already approved through its checkbox. Do not show success before verified setup, the bounded grant, and any selected renewal schedule are all reconciled.

If installing the course fails after activation: “Your offer is active. We’re still preparing your course.” Offer Retry course setup without rerunning payment setup or consuming another claim. A cancelled wallet sheet returns to the same prefilled form. A declined verification says “Your payment method wasn’t saved. Nothing was purchased.” A provider callback still being reconciled says “Checking your saved payment method…” and resumes after refresh. Do not loop indefinitely or convert an unknown status into success.

For a subsequent non-free item purchase, show item, total including known tax, currency and selected method, then a distinct “Pay ” confirmation. This is a new purchase, never fulfillment of the free activation. Cancellation leaves the offer intact. There is plenty of free content, which must remain clearly discoverable without starting paid checkout. Native mobile apps, if added later, require their own distribution and billing-policy plan; this proposal is a web app installed from a browser.

5. Install on iPhone / Android

Use one Install on iPhone / Android entry point with platform-aware instructions and a manual platform switch. Installing never silently adds an icon.

Environment	Interaction
iPhone/iPad browser	Guide the person to Share → Add to Home Screen, with current browser-specific guidance and a suggested “Course card” name. Do not promise an Android-style programmatic install prompt.
Android browser supporting install prompt	User click triggers the captured eligible install prompt. If it is unavailable, show browser menu instructions instead.
In-app browser	Offer Open in browser / Copy link, then show the appropriate install guidance.
Already installed	Show Open card and a brief installed state; do not repeat the install pitch.
Desktop/unsupported	Show the URL and explain how to open it on the phone.

Add a scoped manifest with stable app id, start URL for this exact card, short name, theme/background colors and suitable maskable/icon assets. Do not let different card links overwrite the user's existing portal icon unexpectedly: test per-card identity and scope, and use a generic “My QR cards” installed shell if the target browser cannot reliably support multiple card installations. A service worker may cache static shell/icon assets; authenticated card/offer/API responses, claims and payment pages are network-only by default. Offline opens show a neutral “Connect to display your current card” page; a cached QR must not claim that an expired/revoked offer is active.

Standalone authentication is a release test, not an assumed shared-cookie behavior. If the installed web app needs sign-in again, it must retain the card continuation. Signing out clears private client state without deleting the home-screen icon. Do not request notifications, camera, contacts or location to install or display a QR.

Accessibility and acceptance

Use framework controls, typed data binding, visible labels, clear focus states, at least 44-pixel touch targets, sufficient contrast, reduced-motion support and live regions for setup/install status. At 320 CSS pixels, enlarged text and translated copy must fit without horizontal scrolling. Copy/Share work independently of QR scanning; all method choices and consent work with keyboard and screen reader. A wallet sheet is not opened automatically on page load.

Verify with actual iPhone Safari and Android Chrome devices, both browser and installed modes, light/dark themes, long names, unavailable wallets, new accounts, expired sessions, failed network, cancelled installation and replayed links. Use provider-rendered payment buttons in the built product; mockup labels are not production assets.

Browser references checked for this draft

WebKit: web apps on iOS and iPadOS — home-screen manifest/icon behavior and Add to Home Screen.
WebKit features in Safari 26 — current iOS web-app installation behavior; verify target OS versions during implementation.
Chrome: custom PWA installation experience — install-prompt capability and user-initiated installation.