A surprising share of digital-download support pain starts with a simple mismatch: the person who paid is not the person who will use the file. A partner buys a template pack as a gift. An office manager buys five seats of a plugin for a team. A coach buys a workbook for a client. If your delivery assumes buyer = user, all three of those sales go sideways in the same way — one link, one key, forwarded around until nobody knows who owns what.

Here's how to handle gifts and team purchases cleanly, with whatever delivery tool you use.

Why forwarding the buyer's link is the failure mode

The obvious shortcut — "just forward the download email to them" — breaks almost everything your delivery is supposed to protect:

  • Limits burn wrong. The recipient's downloads count against the buyer's allowance, and the buyer's own later download may be the one that fails.
  • Stamping names the wrong person. If the file is stamped per buyer, the recipient ends up with a copy carrying someone else's identity — awkward for a gift, and messy if that copy ever leaks.
  • Revocation becomes all-or-nothing. A refund, a chargeback, or a team member leaving means killing the one link everyone shares — punishing the people who should keep access.
  • Support can't tell who has what. When the recipient writes in saying "my link stopped working," you have no record they were ever a user.

The fix is a principle, not a feature: every end user gets their own link and, where relevant, their own key, issued against their own email.

Gift purchases: the clean pattern

  1. Ask at the buy page. One line of copy — "Buying this as a gift? Add the recipient's email and we'll deliver it to them directly" — prevents most of the problem before it exists. If your checkout can't collect a second email, say so on the buy page and tell buyers what to do instead (below).
  2. Deliver to the recipient, in the recipient's name. The recipient gets their own tokenized download link with its own limits and expiry. If the product carries a license key, the key is issued for that purchase and associated with the recipient, not forwarded from the buyer's inbox.
  3. Keep the buyer in the loop, not in the chain. The buyer should get a receipt and confirmation that the gift was delivered — not the only copy of the delivery email.
  4. Handle the no-gift-checkout case honestly. If your tool only delivers to the buyer's email, the workable fallback is: buyer downloads nothing, forwards nothing, and instead contacts you (or uses your stated process) to re-issue delivery to the recipient's email. Put that process on the buy page and in the delivery email, before a confused buyer forwards their personal link and creates the mess above.

Team and multi-seat purchases: one payment, N users

Team sales feel like one order. Delivery should treat them as N individual deliveries that happen to share one payment:

  • One payment, N links and keys. Each team member receives their own download link and their own license key at their own email. That is what makes "5 seats" a real, countable thing instead of a hope.
  • Count seats by issued keys, not by trust. If a sixth person needs access, that's a sixth seat to sell — visible to you because keys are issued per person, not guessed from download counts on a shared link.
  • When a member leaves, revoke one key. This is the scenario that decides whether your setup works. With per-person keys, a departure is a single revocation: that person's key and link stop working, everyone else's access is untouched, and a replacement member gets a fresh key. With a shared link, a departure means either leaving access open for someone who no longer should have it, or resetting access for the whole team.
  • Transfers are re-issues, not forwards. A seat moving from one employee to another should be: revoke the old key, issue a new one to the new person's email. Forwarding the old key makes the new holder a stranger in your records — and makes the next revocation guesswork.

Transfer etiquette, stated up front

Most misuse is just undefined expectations. Three sentences on your buy page or in your license terms cover nearly all of it:

  • "Each purchase covers one user. Gifts and team seats are delivered to each user's own email."
  • "Need to move a license to someone else? Contact us — we'll re-issue it to the new user and retire the old one."
  • "Please don't forward your download link or key; forwarded copies may stop working, and we can always issue a fresh one to the right person."

Sellers worry this sounds restrictive. Buyers mostly read it as professionalism — and it converts the "can I share this with my team?" support email into a team sale.

What this requires from your delivery tool

You don't need a dedicated "gift feature" or "team portal" to do any of this. You need four delivery primitives, and you should check your tool actually has them:

  1. A unique, tokenized link per buyer — so a re-issue to a recipient is a distinct link, not a copy of the buyer's.
  2. Per-product download limits and expiry you control — on FileFreight that's up to 25 downloads and 30 days on Free, unlimited downloads and never-expiring links on Pro.
  3. A license key per paid order, with validation and revocation — FileFreight issues a key with every paid order when keys are enabled, keys can be checked from your app with one API call (POST /api/licenses/validate), and any key can be revoked at any time. Refunds revoke access automatically.
  4. Per-buyer PDF stamping — PDFs are stamped with the buyer's identity on first download, so the copy a recipient holds should be issued to them, not forwarded from the purchaser.

FileFreight doesn't have a one-click gift checkout or seat-management dashboard — the patterns above are seller practice built on those primitives: collect the recipient's email at sale time (even a simple checkout note or follow-up email works), and make sure each end user ends up with delivery issued to them personally.

Honest caveats

  • FileFreight is delivery only: secure tokenized download links, per-product limits and expiry, per-buyer PDF stamping on first download, and a license key per paid order (validation API, revocation anytime, automatic revocation on refund). Files up to 500 MB per product. Payments go through your own Stripe account; we never touch your money.
  • It is not a merchant of record — sales tax and VAT handling stay with you, unlike MoR platforms that take them on (and take a bigger cut for it).
  • There is no importer yet — moving an existing catalog over is manual, which is why we offer free white-glove migration help for the first 20 sellers who ask.
  • It is not a Shopify app and not a marketplace — it won't bring you discovery or traffic; it's for sales through your own channels.
  • Pricing is simple: Free is 5% per sale; Pro is $19/month with zero per-sale fees. If you sell very little, a per-sale plan can genuinely be cheaper — do your own breakeven math.

Gifts and team purchases are some of your best orders — someone liked your product enough to buy it for somebody else, or a whole office. They only become support problems when delivery pretends the buyer and the user are the same person. Separate those two roles, and the same orders become the easiest upsells you have: the second seat, the fifth seat, and next year's gift.

— FileFreight (getfilefreight.com)