> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/chord-oms/chord-oms-overview/subscriptions/subscription-states/gift-subscription.md).

# Gift Subscription

## Gift Subscription

## Overview

A **gift prepaid subscription** is a prepaid subscription that one person **buys for someone else**. The purchaser pays upfront for a fixed number of deliveries, and the\*\* recipient\*\* receives and redeems the gift. Once redeemed, it behaves like any other prepaid subscription — deliveries are fulfilled on a set schedule until the prepaid term is used up.

It shares all the core prepaid traits:

* **Paid in advance** — there's no per-cycle charge; the deliveries are already paid for by the purchaser.
* **Fixed length** — it runs for a set number of deliveries and then ends on its own.
* **Can't be paused, skipped, or resumed** — the same self-service restrictions as any prepaid subscription.

What makes a gift different is the **redemption step** between purchase and activation. A gift doesn't necessarily start delivering the moment it's bought — in most cases it waits for the recipient to redeem it first.

As with non-gift prepaid, status is shown using **two status fields** (**State**: Active / Canceled / Inactive, and\*\* Prepaid state\*\*: Pending / Active / Completed / Canceled), plus a\*\* Processing state\*\* for the latest delivery. Gift subscriptions add two more fields that are specific to the gift flow:

* **Redemption Method** — how the gift is redeemed (**Ship**,\*\* Email\*\*, or\*\* Print\*\*).
* **Redemption Code** — the code the recipient uses to redeem (shown for gifts that require manual redemption).

## How a gift is redeemed

There are **two ways** a gift can be set up, which determines whether the recipient has to do anything:

### Auto-redeem gifts

The gift **activates automatically** — no action is needed from the recipient. It behaves like a normal prepaid subscription from the moment of purchase, shipping to the recipient's address. Auto-redeem gifts are always set to **Ship.**

### Manual-redeem gifts

The recipient must **redeem the gift** before it starts. The gift sits and waits until they do. The recipient redeems using one of three **redemption methods**:

* **Email** — the recipient is emailed a **redemption code** and a redemption link on a scheduled notification date. They click the link, confirm their details (and provide a shipping address), and the subscription activates.
* **Print** — the gift is delivered as a printed gift card (no email is sent). The recipient redeems the code printed on the card.
* **Ship** — redeemed by shipping the product to a provided address.

When the recipient redeems (by entering their code and email, plus a shipping address where required), the system **activates** the subscription: it creates an account for the recipient, sets their address, switches the subscription to draw from the prepaid funds (so the recipient is never charged), and begins fulfilling deliveries.

## Prepaid State

A gift prepaid subscription moves through the same prepaid stages as a non-gift one, but the **Pending** stage carries the extra redemption layer.

#### Pending

The gift has been purchased but **hasn't started delivering yet**. For gifts, this stage is where the redemption happens.

* **What puts it here:** the gift is created in Pending at the time of purchase.
* **How it leaves Pending:**
  * **Auto-redeem gifts** leave Pending almost immediately and become Active on their own.
  * **Manual-redeem gifts** stay in Pending until the **recipient redeems** their code. Until then, no deliveries are made and the subscription isn't yet tied to the recipient.
* **Recipient notification (Email method):** for email-redemption gifts, the recipient is sent their redemption code and link on the gift's scheduled notification date. (Print gifts are not emailed; the code is on the printed card.)

![](https://3559351341-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGejRW1RLC9yasX56Xzxu%2Fuploads%2Fgit-blob-c9e16c8cd36ccb24e9c15f1172fe25460b991a90%2Fgift-subscription-1.png?alt=media)

{% hint style="info" %}
**Note: An unredeemed gift stays Pending until it's redeemed — it does not expire on its own.** There is no automatic time limit that moves an unredeemed gift to a finished state. A manual-redeem gift will remain in **Pending** indefinitely until the recipient redeems it, or until an admin cancels it. If you need an unredeemed gift to end, it has to be canceled — it won't lapse by itself.
{% endhint %}

#### Active

The gift has been redeemed (or auto-redeemed) and the prepaid term is underway. Deliveries are fulfilled on the set schedule, drawing down the prepaid balance one delivery at a time. At this point the **recipient** is the subscriber, and deliveries are paid for from the prepaid funds — the recipient is never charged.

* **What puts it here:** the gift is redeemed (manual) or activated automatically (auto-redeem).
* **Overall State: Active.**

***

![](https://3559351341-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGejRW1RLC9yasX56Xzxu%2Fuploads%2Fgit-blob-d2490fca2e2f872f8e982d4ab18a844a8f130e4e%2Fgift-subscription-2.png?alt=media)

#### Completed

All of the purchased deliveries have been fulfilled and the prepaid term is finished. The subscription has run its full course and won't place any more orders. This is a natural, successful end.

* **What puts it here:** the final delivery in the prepaid term is fulfilled.
* **Where you'll see it:** **Completed** on the **Prepaid Subscriptions** page; the linked subscription's own **Details** page shows **Inactive** (with a **Prepaid state** of **Completed**).

![](https://3559351341-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGejRW1RLC9yasX56Xzxu%2Fuploads%2Fgit-blob-7b783a972ee50e212bdd88e62089349d824ef38f%2Fgift-subscription-3.png?alt=media)

{% hint style="info" %}
**Note: "Completed" and "Inactive" are the same outcome, shown from two different views.**

On the **Prepaid Subscriptions** page, the **State** describes the gift's prepaid term — when every delivery has shipped, it reads **Completed**.

On the **Subscription → Details** page, the **State** describes the subscription itself — once the term is done, it reads **Inactive**, with a\*\* Prepaid state\*\* of **Completed** alongside it.

Both are true at once: the term **Completed**, so the subscription is now\*\* Inactive\*\*. This is expected, not a discrepancy.
{% endhint %}

#### Canceled

The gift subscription was ended **early**, before all of its purchased deliveries were fulfilled. Because it was paid upfront, canceling triggers a\*\* prorated refund\*\* for the deliveries that were paid for but not yet received.

* **What puts it here:** the subscription is canceled (cancellation availability depends on a store setting — see *Available actions*).
* **Refund:** the unused (unfulfilled) portion of the term is refunded — as store credit to the recipient, or back to the original payment method.
* **Overall State: Canceled.**

![](https://3559351341-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGejRW1RLC9yasX56Xzxu%2Fuploads%2Fgit-blob-76845fdf2d8e30446d679b051c9a05090ce4f8f3%2Fgift-subscription-4.png?alt=media)

## Available actions

Gift prepaid subscriptions carry the same action restrictions as all prepaid subscriptions:

* **Pause, Resume, and Skip are not available** — the term is purchased in advance, so the schedule can't be changed this way.
* **Cancel is available only if the store enables prepaid subscription management** — by default it's turned off; when enabled, canceling triggers the prorated refund above.

When these actions are unavailable, the admin shows the banner:

{% hint style="info" %}
**Note:** "Some actions not available — Because this is a pre-paid subscription, certain fields are not editable and some actions (like Cancel, Skip and Pause) are not available."
{% endhint %}

## What happens at the end of the term

When a gift prepaid subscription fulfills its last purchased delivery, it **Completes** and goes **Inactive**.

Gift subscriptions are typically one-time — they do not automatically renew, and the recipient is never billed to continue. (If a gift were configured to renew or roll over into a standard subscription, it would follow the same end-of-term paths described in the Prepaid (Non-Gift) section.)

## Gift-specific admin fields

On a gift subscription you'll also see:

* **Gift? → Yes** — identifies it as a gift.
* **Redemption Method** — Ship, Email, or Print.
* **Redemption Code** — the code the recipient redeems with (shown for manual-redeem gifts; the recipient also receives this by email for the Email method).
* **Recipient / Purchaser** — the gift is tied to a recipient (who becomes the subscriber once it's redeemed) and a purchaser (who paid for it). On cancellation, the refund goes to the recipient as **store credit** by default, or back to the **purchaser's original payment method** if processed that way.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.chord.co/chord-oms/chord-oms-overview/subscriptions/subscription-states/gift-subscription.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.