Understand gift subscriptions
A Gift subscription separates the sponsor who provides it from the recipient who claims it. Creating a sponsorship and its single recipient slot is separate from activating the recipient's membership.
For City Journal, Alex could purchase a Gift subscription for Morgan. Alex is the sponsor; Morgan should sign in with Morgan's own account when claiming the intended code.
Prepare the publication's gift option
Confirm the publication and intended Plan, then use the subscription setup guide to prepare a new subscription. Choose Gift in its Type selector. Existing saved subscription types are not editable in that form.
Agree the price, period and any trial settings with the person responsible for subscriptions. The website integration must support the gift purchase, sponsor contact and recipient claim flow. Do not assume every website has the same gift popup or buttons.
Understand the reader sequence
- Sponsor purchase: Alex uses the configured website purchase flow. A successful purchase can create the gift sponsorship and one recipient slot. Confirm payment separately; the existence of a gift record is not payment proof.
- Intended recipient contact: the sponsor supplies Morgan's email through the configured integration. This stores contact information and attempts invitation events. An attempted notification does not establish delivered email.
- Recipient claim: Morgan signs in with the intended account and submits the protected activation code through that site's claim flow. The code must belong to the publication and be unused. If a recipient identity is already bound to the slot, it must match the claimant.
- Membership inspection: after claim, inspect Morgan's membership and the access decision for the content they want to read. Claim and article access are separate observations.
Keep the activation code for the intended recipient. Code-based claim does not universally verify ownership of the stored contact email, so an emailed address alone is not an identity safeguard.
When membership starts and ends
Gift recipient membership is created during activation, rather than by the unclaimed slot alone. Its end date follows the configured subscription period or applicable trial and existing same-Plan membership rules. A recipient who already has a membership can therefore have a different result from a first-time reader.
Check the actual reader membership instead of promising a fresh full term from the purchase or claim date. These membership rules do not establish that billing only begins at claim.
A successful slot activation marks it activated, binds the recipient and clears the activation code. An already-activated gift cannot be claimed again. The Multi-Seat slot-clearing operation is not a gift reassignment workflow.
What the publisher can inspect
Open the sponsor's reader record from Audience, then inspect Sponsored subscriptions. Compare the Plan, subscription and type with the intended gift. Use the recipient's own membership record to confirm their dates and state.
The sponsor table is a summary. Its slot count and payer/renewal indicators do not prove delivered email, successful payment or current access for the recipient. Understand sponsored access explains those fields and the separate publisher attachment task.
For the implementation owner, share Sponsor and recipient tasks. Those technical operations are separate from everyday Admin inspection.