Understand sponsored access
Sponsored subscriptions let one account provide a Gift or Multi-Seat subscription for other readers. In Wallkit, sponsored access here is the shared system for those types, rather than a third subscription type or a generic free-access switch.
Use Understand gift subscriptions for one recipient and Manage team subscriptions for a sponsor-paid set of slots.
Know the people and records
| Piece | What it represents |
|---|---|
| Sponsor | The account that owns the sponsorship; new sponsorships initially name the sponsor as payer. |
| Subscription | The configured Gift or Multi-Seat choice under a publication's Plan. |
| Sponsorship | The parent record connecting the sponsor to that subscription. |
| Slot | One recipient place or pending invitation under the sponsorship. |
| Recipient membership | The individual reader's Plan/subscription relationship after the supported activation path. |
For City Journal, Alex's sponsorship and Morgan's reader membership are separate records. A payer preference identifies an intended payment arrangement; it is not a receipt for a successful charge.
Configure the appropriate subscription
Prepare a new subscription under the intended Plan using Add subscriptions to a Plan. Its Type selector offers Gift or Multi-Seat alongside Standard. Multi-Seat also exposes Number of seats.
Choose the type that fits the agreed recipients and timing. The gift and team guides explain their different claim and duration behavior. The website's purchase/contact/claim experience requires the corresponding integration; Admin configuration alone does not install it.
Attach a sponsorship as the publisher
This is a publisher record-attachment task, separate from a reader's purchase. Use it only for the intended sponsor and configured subscription.
- Confirm the publication, then find the sponsor's reader record.
- Open Sponsored subscriptions and click its Add button.
- Choose Gift or Multi-seat, then select the intended subscription under its Plan in Plans and subscriptions.
- Click Attach, then inspect the resulting entry and actual slot state.
Attachment creates the sponsorship/slot records through the selected type's path. It does not submit a provider payment or establish delivered invitations. For Multi-Seat, it can also create the parent membership and start its term; Gift recipient membership waits for claim. Plan this consequence before attaching.
A saved record does not guarantee that every slot or later event was created successfully. Confirm the saved state before assuming the recipient can proceed.
Read the sponsor table carefully
| Visible field | How to read it |
|---|---|
| Plan, Subscription and Type | The configured choice linked to the sponsorship. |
| Ends | An end date from the sponsorship's first associated membership, or N/A when none is supplied. It is not a complete audit of every recipient's dates. |
| Slots, shown with an activated label | The numerator counts slots with a recipient object; the denominator counts returned slots. That label alone is not proof of each slot's activation or current access. |
| Paid by sponsor | The stored payer preference, not proof of successful payment. |
| Renewal/trial indicators | Membership summary values when supplied; inspect the individual recipient and payment state separately. |
An unclaimed gift can lack a recipient membership date. A Multi-Seat recipient shares the parent's term. For the intended reader, use Read a reader's membership and the integration's content-access decision.
Keep the other ways of granting access separate
A free subscription, promo discount, Group membership and invitation have their own conditions. None should be treated as equivalent to a sponsor-funded subscription or a successful payment.
The configured sponsorship flow also separates payment, contact notification and recipient claim. In the supported Gift recipient integration flow, turning off sponsor payment changes a payer flag; it does not itself refund a charge or delete the recipient's membership.
Share Sponsor and recipient tasks with the implementation owner for the technical flows.