WooCommerce礼品卡插件使用指南：5大功能提升店铺销量与客户粘性

今天是 12 月 22 日。一位顾客在你的商店里浏览了十分钟。他们想给姐姐买礼物，知道预算但不知道尺码、不知道品味、也不知道你店里那三款大衣中姐姐会穿哪一款。于是他们做了每个犹豫不决的送礼者在别无选择时都会做的事：关掉标签页，去别处买一张礼品卡。

那笔生意本该是你的。你之所以失去它，是因为你没有东西可以卖给一个不知道买什么的人。WooCommerce Gift Cards 是 Automattic 的官方扩展，正好填补了这一空白。它让你能够销售数字礼品卡，顾客可以将其通过电子邮件发送给收件人、设定日期，并在结账时兑换，余额和活动记录都在 WooCommerce 内原生跟踪。

我已经在几家 WooCommerce 商店上设置过礼品卡，使用过这个插件和它的两个竞品，我想带你了解真实情况：它做得好在哪里，哪些地方设置比应有的更繁琐，以及那些没人提过、直到你陷入其中才发现的法律和会计陷阱。

什么是 WooCommerce Gift Cards？

WooCommerce Gift Cards 是 WooCommerce（维护 WooCommerce 核心的 Automattic 团队）自有的礼品卡扩展。头部描述直言不讳地说明了它的功能：“创建并销售数字礼品卡，顾客可在你的商店兑换。”这就是全部的卖点，而专注的范围也是它值得关注的原因之一。

这是我第一次使用时感到惊讶的部分：礼品卡并不是你需要学习的新产品类型，它只是一个复选框。你拿一个普通的 WooCommerce 产品，在产品数据面板中勾选“礼品卡”框，该产品现在就会生成一个可兑换的代码，而不是发货实物。你已知的关于 WooCommerce 产品的所有其他东西仍然适用：分类、图片、价格字段、简单或可变产品。

生成的代码，以及与之相关的每次充值、兑换和退款，都存储在自定义数据库表中，而不是作为文章存储。这个细节的重要性听起来比实际大，我会在对比部分再回到这一点，因为这是这个插件与其他替代方案之间最大的架构差异。

如果你想参考供应商自己的功能页面，它位于 woocommerce.com/products/gift-cards。

礼品卡如何端到端地在你的商店中流转

在接触任何设置之前，让我先追踪整个生命周期。一旦你了解了这四个阶段，插件中的每个界面就都说得通了，因为每个界面负责一个阶段。

第一步，你销售它。 你将产品标记为礼品卡，设置金额（或多种金额），并可选择设置有效期和收件人邮箱图片。客户像添加其他商品一样将其加入购物车。

第二步，客户赠送它。 在产品页面，他们填写赠送对象、赠送人、可选留言以及送达时间。最后一个字段是默默无闻的亮点：客户可以在1号购买礼品卡，并在两周后的生日那天让它出现在他人的收件箱中。

第三步，它被送达。 在送达日期，一封带有代码的品牌邮件会发送给收件人。整封邮件设计为可用你的颜色和图片重新样式化，这是大多数店主低估的部分。

第四步，收件人兑换它。 他们在结账时（也可在购物车页面）输入代码。余额被扣除，订单完成，任何剩余金额会保留在卡中供下次使用。部分兑换是默认功能，而非附加功能，这正是礼品卡应有的行为方式。

这就是循环：销售、赠送、送达、兑换。你已收取的款项以余额形式存在，直到有人使用它。请记住这一点，在未使用余额计算部分再细谈，因为“余额中的资金”既是吸引力也是负债。

主要功能

不要直接甩出一张营销清单，而是来看看真正能推动实际店铺增长的是什么。

• 礼品卡以复选框形式存在，而非产品类型。 任何简单或可变产品只需在“产品数据”中勾选一个框即可成为礼品卡。您无需学习新的产品工作流程。
• 发送给收件人的礼品表单。 包含收件人、发件人、留言以及可设为“立即”或定时发送的交付日期。这是面向客户的标志性功能，也是礼品卡能转化为真正礼物的原因。
• 定时发送。 收件人邮件会在所选日期触发，而非购买时。立即购买，生日当天送达。
• 部分兑换与余额剩余。 一张价值50货币单位的礼品卡，用于30单位的订单后，卡内还剩20单位。顾客会回来花掉余额。
• 品牌化、可筛选的邮件。 礼品卡邮件的背景、文字颜色和消息样式均可调整，因此礼品码送达时看起来像您的品牌风格，而非普通收据。
• 我的账户集成。 开启账户功能后，登录的用户可以在“我的账户”中查看自己的礼品卡和余额，并使用该余额进行支付。
• 购物车页面应用。 除了结账页面，您还可以让购物者在购物车页面直接使用礼品卡，以便他们在确认前看到调整后的总金额。
• 带有活动日志的管理仪表盘。 营销 » 礼品卡列出了每张已发行的卡片，包括其代码、余额、收件人、有效期以及持续更新的活动日志。
• 批量导入和导出。 通过 CSV 迁移现有卡片余额或导出整套数据。
• 退款至礼品卡。 以礼品卡形式的店铺余额进行退款，代替（或同时进行）付款撤销，从而将资金保留在您的商店内。
• 原生的 WooCommerce Analytics 报告。 已发放和已过期的礼品卡数据接入 WooCommerce 自身的 Analytics，使报告与您商店的其他数据在同一个地方。
• 过期提醒。 可选的“有效期天数”加上过期提醒邮件，并可配置提前通知时间。默认设为“永不过期”，该默认设置出于法律原因，我们稍后会说明。
• 一个 v2 礼品卡 REST API。 礼品卡可通过 REST 进行读取和管理，适用于无头商店和外部工具。

注意清单中有多少是关于售后的。这个重点是正确的。销售礼品卡很容易；价值在于发放、兑换和保持账目清晰。

创建礼品卡产品

我们来创建一个。一旦你知道入口在哪里，流程就很快；但第一次使用时确实令人困惑，因为“添加产品”界面上没有任何提示说是“礼品卡”。

第 1 步，添加一个产品。 前往 产品 » 添加新品，为其命名，例如“Store Gift Card”，并添加图片。像对待其他产品一样对待它，使其自然融入你的商品目录。

第 2 步，勾选“Gift Card”框。 在 产品数据 面板中，在熟悉的“虚拟”和“可下载”复选框旁边，你会看到一个 Gift Card 复选框。勾选它。此时，该产品不再是一件商品，而变成了一张可以生成代码的礼品卡。

第 3 步，设置金额。 在 常规 选项卡中，设置 常规价格。该价格即卡片的面值。对于单一固定面额，一个简单产品即可满足需求。

第 4 步，设置有效期和邮件图像。 勾选该复选框会显示一个 Gift Card（礼品卡） 区域，其中包含 到期天数 （默认：永不过期）以及一个 收件人邮件图片 选项（使用产品图片，或为邮件上传自定义图片）。

提示： “收件人邮件图片”是您的品牌在收件人收件箱中的第一印象。请上传一张干净、适合送礼的图片，而不是默认使用产品照片，例如一件外套的照片。礼品卡应给人以礼物的感觉，而不是发货确认。

现在，坦诚地说说不足之处。 这个问题本应更清晰，但实际却不够明确： 提供多种面额或客户自定义金额。单一面额的方式极其简单，设定一个价格即可。对于预设的多个金额（$25 / $50 / $100，约180元/360元/720元），你需要使用WooCommerce常规的可变产品机制，并将礼品卡行为应用到各个变体上。这种方法可行，但插件并没有提供逐步引导，如果你从未创建过可变产品，可能需要花几分钟摸索。在向客户承诺“客户可以输入任意金额”前，请先在自己的安装环境中确认具体的金额选项界面，因为体验取决于你如何构建产品。我希望在复选框下方有一个更清晰的“添加面额”组件，然而目前并没有。

注意： 礼品卡是数字产品。请将其设为非需配送商品，这样 WooCommerce 就不会试图为通过电子邮件发送的代码收集收货地址。

客户赠礼与交付流程

这是客户实际接触的界面，也是该插件最精彩的部分。当购物者在前端打开礼品卡商品时，他们看到的不仅仅是“加入购物车”。他们看到一个小表单，将购买转化为一份礼物。

字段在产品页面上显示如下：

• 收件人 （必填）：收件人的电子邮件。您可以输入多个地址，用逗号分隔，以便向每人发送一张独立的卡片。
• 发件人 （必填）：发件人姓名，以便收件人知道是谁送的。
• 留言 （可选）：随邮件发送的个人附言。
• 送达日期立即发送 现在，或安排在未来的日期。
• 数量 和 加入购物车，和往常一样。

您可能想知道买家是否能看到代码，还是只发送给接收者。接收者是在送达日期通过电子邮件收到可兑换代码的人。这种区分是有意为之，礼品卡就像递给别人的实际礼物，而不是买家自己收下的优惠券。

此功能的亮点： 配送日期字段。我无法强调这对节假日和特定场合购买消除了多少麻烦。为三周后的生日购物的顾客无需设置手机提醒“在那天发送礼品卡”。他们只需安排一次就无需再记挂。对于商店来说，这意味着你在顾客受激励的那一刻就抓住了销售，而不是在截止日期那天，那时他们可能已经忘记你的存在。

快速打消你的疑虑，因为多收件人“用逗号分隔邮件”听起来很繁琐：其实不然。你输入两个地址，两人都会收到各自的卡片。这就是全部窍门。教师年终感谢、经理给一个小团队送礼、一对夫妇分摊一份礼物，都可以在一个产品页面上处理。

兑换：购物车、结账和余额

一张无法使用的礼品卡只是一张截图。兑换环节是插件证明其正确集成到 WooCommerce 中而非额外附加的地方。

收件人在 结账时输入代码。礼品卡余额会应用到订单总额，关键行为在于：这是一个 余额抵扣，而非折扣条目消费金额少于卡内余额时，剩余金额会保留在卡上用于下一次订单。消费超过余额时，卡支付部分金额，其余部分通过常规支付方式支付。部分兑换，两种方向，开箱即用。

您还可以启用 购物车页面应用 因此，购物者可以在到达结账之前应用礼品卡，更早看到总金额下降。这到底是有帮助还是会显得杂乱，取决于你设定的流程。在结账流程较长的商店中，在购物车中显示调整后的总额可以减少“等等，我的优惠码生效了吗？”这种焦虑。而在单页结账中则显得多余。你可以在设置中自行决定。

注意： 有一个“阻止礼品卡折扣”设置，可以防止优惠券在购买礼品卡时叠加使用。如果你不希望有人使用八折优惠券花80元购买100元面值的礼品卡，然后全额兑换，请开启此设置。这是一个在数据中才能发现的、容易被忽视的利润漏洞。

对于已登录并启用账户功能（账户功能）的客户，余额显示在 我的账户中，他们可以查看剩余金额并使用它付款。这是此插件最接近商店信用（store credit）功能的表现，对于许多商店来说，这已经足够，你根本不需要单独的商店信用插件。

你可能会问，兑换功能是否适用于新的区块化结账（block-based checkout）还是仅支持传统的短代码（shortcode）结账？好消息：该插件内置了官方的区块结账集成，与 WooCommerce 的 Store API 挂钩，因此礼品卡兑换在区块化的结账页面中也能开箱即用，而不仅仅是传统的短代码流程。与任何结账相关功能一样，在上线前在你的实际主题上快速测试一下订单是明智的，但这已经是得到支持的功能，而不是一个悬而未决的问题。

安装与设置

安装过程与常规插件无异。在“插件”菜单下上传扩展包。 插件 » 添加新 » 上传插件激活它，你会看到一个新增的 WooCommerce » 设置 » 礼品卡 选项卡和一个 营销 » 礼品卡 菜单项。它需要 PHP 7.4 或更高版本，任何正常维护的主机都能轻松满足。

设置选项卡就是制定规则的地方。在销售第一张礼品卡之前，先从头到尾走一遍。

以下是各个部分以及我实际会怎么操作：

• 赠送，“作为礼物发送？” 选择是否包含收件人/发件人/留言等赠送字段 始终 显示或 可选。如果礼品卡是您使用该插件的主要原因，请将赠送功能突出显示。如果您主要想要可自行兑换的商店积分，请将其设为可选。
• 账户，“启用账户功能”。 将礼品卡存储在客户账户中，并允许他们从“我的账户”中使用余额付款。对于任何有注册客户的商店，请启用此选项。这是礼品卡与旧邮件中遗忘代码之间的区别。
• 购物车，“启用购物车页面功能”。 让购物者可以在购物车页面应用礼品卡，而不仅仅是在结账时。如上所述，根据漏斗步骤开启或关闭。
• 阻止礼品卡折扣。 阻止优惠券与礼品卡叠加。我建议在大多数商店中启用此功能以保护利润。
• 邮件、抄送和密送。 添加一个地址，用于在礼品卡邮件中静默抄送。方便保存记录，或者让店主了解发送内容。
• 授予商店经理管理员权限 （代码可见性）。默认情况下，商店经理角色可以看到礼品卡，但只能看到每个代码的最后几位字符。启用此选项可向真正需要的经理显示完整代码；如果您希望将完整代码仅限管理员可见，则保持禁用，因为代码相当于可花费的钱。
• 过期提醒和过期前天数。 可选择在礼品卡过期前发送提醒邮件，并可配置提前时间。仅当您设置了过期时间时才相关，同样，您应首先从法律角度认真考虑。

提示： 在发布礼品卡之前，先设置好您的送礼和账户行为。在客户已经熟悉您的流程之后，再将“作为礼品发送？”从可选改为始终，这是一个虽小但确实会导致支持工单增加的原因。

礼品卡仪表板、导入和导出

您发行的每张礼品卡都会被跟踪到 营销 » 礼品卡这是本功能的后台管理区：已发放的礼品卡列表，以及一个 活动 视图，以及 导入 和 导出 工具。

让我直截了当地告诉你第一天会看到什么。 控制面板只有在实际销售发生后才会活跃起来。 在新开张的商店中，它会以愉快的空状态向你打招呼：“万岁！您现在正在销售礼品卡。每当购买礼品卡时，它就会显示在这里。” 这很友好，但也意味着在资金流动之前，你实际上无法评估管理界面。一旦有了卡片，表格会列出每张卡的代码、余额、接收人、有效期和活动情况，而活动日志则记录每张卡的发放、兑换、充值及退款操作。

活动日志是我最依赖的部分。因为礼品卡代码实际上就是现金（更多内容见反模式部分），所以每次余额变更的可审计记录并非锦上添花，而是在客户说“我的卡上余额不止这些”时，你的防御工具。你可以指向日志。

导入 在迁移时最重要。如果你从其他礼品卡插件或从发过实体卡片的销售点系统迁移过来，可以通过 CSV 导入现有余额，而无需重新发卡导致客户困惑。导入器解析的行甚至可供开发者过滤，因此旧系统中稍有偏差的导出文件可以在导入前调整格式。

导出 是你的备份和会计的帮手。当你需要负债（是的，负债，记住这个概念）快照时，将全部未结卡片和余额导出为 CSV。

注意 没有你预想中那种明显的“手动添加礼品卡”按钮。卡片通过订单（或导入）生成。如果你的计划是“我要为一位VIP手动创建一张卡片”，更简洁的方式是下个免费订单购买礼品卡产品或导入一行，而不是寻找本界面中并非重点的“新建卡片”表单。

退款到礼品卡（商店信用）

这是一个我希望更多商店在需要之前就能了解的功能。当你在 WooCommerce 中处理退款时，该插件会提供退款的选项 到礼品卡 而不是退回到原始支付方式。客户获得商店信用，可以再次在你的商店消费，而不是资金永久离开你的业务。

对于退货来说，这简直是金矿。退还一件大衣并带着礼品卡余额离开的客户，比那些退款到信用卡后离开的客户，重新购买的可能性要大得多。你将收入留在了店内。

但是，坦率地说有一个前提需要注意， 退款方向令人困惑。有两个完全不同的操作都使用了“退款”这个词，将它们混为一谈会导致支持方面的麻烦：

1. 为礼品卡购买退款购买者改变主意，关于 购买 礼品卡，并想要回他们的钱。
2. 将退货退款到礼品卡，您正在为退货发放商店信用 实体产品。

这些并非同一笔交易，如果您的客服团队将它们视为可互换的，那么您要么退还了本应保留为信用的现金，要么在客户期望退款到信用卡时发放了信用。书面制定政策，如果您默认退货为商店信用，请在退货时明确说明，以免“退款”让人意外地变成礼品卡余额。

如果商店信用和忠诚度积分是您模式的核心（而非偶尔使用），则值得将其与专用的忠诚度工具（如 WooCommerce Points and Rewards）进行比较，后者从赚取和消费积分的角度来处理“商店内货币”。

礼品卡对谁划算（以及未使用金额的计算）

礼品卡并非适用于每家商店，我宁愿您在启动您并不需要的项目之前了解这一点。以下是它们真正有回报的情况，并附有人物画像，以便您能对照其中一种情况。

如果您经营沙龙或水疗中心， 礼品卡可以说是您最好的产品。护理服务是个人化的，难以直接赠送（您无法包装一个理发服务），但一张“在这里随心所欲”的余额卡是完美的礼物。节日购物（母亲节、生日）成为真正的收入来源。

对于节日密集的礼品店， 预约配送正是关键所在。顾客在“抢购窗口”下单，您当天配送。这能转化那些原本会放弃购买的犹豫买家——正是开场场景中的那位顾客。

如果您经营服装或鞋店， 尺码和品味问题让直接送礼行不通。礼品卡则完美规避这两点。收礼人自选尺码和款式，退货率降低，而您依然完成销售。

对于课程或会员制网站， 礼品卡允许一人为他人购买访问权限，无需共享登录信息或代付订阅。而且，由于礼品卡可用于部分支付订阅续费（插件为开发者提供了部分续费支付的开关，详见开发者章节），您可以让顾客用礼品卡余额抵扣持续订阅计划。如果循环计费是核心业务，请将此与 WooCommerce Subscriptions 配合使用，并决定礼品余额如何与续费交互。

现在，我们来谈谈让礼品卡成为真正的商业决策（而非功能开关）的部分： 未兑换余额（Breakage）。

Breakage 指从未被兑换的礼品卡价值。行业估计长期认为，这一比例处于已发行价值的低至中个位数百分比，具体取决于类别和核算方式。表面上看这像是免费的钱：顾客付了100元，只花了90元，您留下了10元。但这里有个陷阱——这就是为什么我一直在说“先别急”。

未兑换余额在售卡当天并非收入。 这是一项负债——您欠顾客的商品价值。只有在特定的会计和法律条件下，您才能将 breakage 确认为收入，而且通常要在礼品卡合法过期（在允许过期的地区）之后。将礼品卡销售视为即时收入，正是导致商店账目好看但税务出乎意料的原因。Breakage 计算可以成为一个悄无声息的利润中心，但前提是核算正确。搞错了，这个“利润”就是从您未来的义务中借来的。

WooCommerce Gift Cards 与 YITH 及 Smart Coupons 对比

这是我最常被问到的对比，因为从技术上讲，三者都能“做礼品卡”。然而，它们的构建基础确实不同，差异在于架构层面，而非表面。三者的定价都在变动（都是年度授权，价格会变化），因此我不刻意给出具体美元金额。请自行在结账时比较当前价格。以下差异在于各自的构建方式，这与促销无关。

三个可衡量的架构要点决定了这一选择：

第一，存储方式。 该插件将礼品卡及其活动记录保存在 专门构建的自定义表中，而YITH WooCommerce Gift Cards则将每张卡存储为 gift_card 自定义文章类型。这并非吹毛求疵。使用自定义表意味着余额查询和活动记录查询不会与你的 wp_posts 表发生冲突。对于一个拥有数万张礼品卡以及所有产品、订单和修订版本的商店而言，这确实有所不同。想象一张有30行活动记录的卡：在自定义表中，这是紧凑的索引读取；而每卡一个文章类型的模型则将读取分散到同一个 wp_posts/wp_postmeta 你的整个网站已经频繁访问的（表）上。

第二，原生分析功能。 因为这是第一方扩展， 已发放和已过期的礼品卡报告可直接接入 WooCommerce Analytics。 这意味着两个原生礼品卡报告类型与商店其他数据的分析界面完全一致，无需独立看板，也无需折腾 CSV。其他方案都无法像这样将礼品卡报告接入 WooCommerce 的原生分析系统。

第三，REST API。 数一数专用的礼品卡 REST 控制器，本插件有 1 个，而其他方案为 0 个：此插件附带一个 v2 礼品卡 REST 控制器（在基于它进行开发前，请确认你安装中的确切命名空间），这使得礼品卡可以通过无头前端或外部系统进行读取和管理。如果你正在运行分离式商店或将余额同步到 POS 系统，这将是一个决定性因素。 在大家都关心的“破损”维度上，这种架构让你能真实衡量它。未兑换价值通常处于较低个位数，根据类别不同，常约为发放价值的 1% 到 5%，只有这里的原生“已发放/已过期”报告能在 WooCommerce 内部直接显示该数字，无需导出和电子表格步骤。

那么各自适合什么场景？当你需要 WooCommerce 团队出品的一个专注、原生、与分析集成的礼品卡方案时，选择此插件。当你已经使用 YITH 系列产品并希望附加礼品卡功能时，选择 YITH。当礼品券是更大的优惠券与积分策略（如买一送一、URL 优惠券、商店积分、定时促销）中的一部分，且你更愿意购买整个套装而非单一工具时，选择 Smart Coupons。它们针对不同问题给出了不同答案，而“官方 + 原生 + 分析”正是此插件的专属赛道。

那三款插件分别适配什么场景？下面分场景给你选型建议： 如果你想要一款由 WooCommerce 官方出品、原生深度兼容、自带数据分析功能，且功能专一聚焦礼品卡的插件，就选官方礼品卡插件。 如果你店铺已经在用一整套 YITH 系列插件，想配套加上礼品卡功能，直接选 YITH 礼品卡插件。 如果你要搭建一套完整的优惠、店铺余额营销体系，礼品券只是其中一小部分 —— 需要买一送一（BOGO）、链接直达优惠券、店铺余额、活动定时发放等全套能力，更愿意一步到位买完整套件，而非只买单一礼品卡工具，那就选 Smart Coupons。

没有这四个护栏，不要卖礼品卡

不要在没有考虑过期法、破损会计和代码安全的情况下启动礼品卡计划。我目睹过每一项都给商店带来麻烦，没有一项是表面的。它们直接触及金钱、法律和信任。

过期受法律监管，默认设置能保护你。 在美国，《信用卡责任与披露法案》禁止商店礼品卡在五年内过期，并限制闲置费。许多其他司法管辖区直接禁止过期。这个插件的“过期天数”默认设置为 从不 正是出于这个原因。为了增加破损而设置激进的过期时间，在你运营的地区可能是完全非法的，所以在接触该字段之前，请检查你销售的每个地区的法律。短过期时间不是增长黑客，而是合规风险。

未兑换的余额是负债，而非收入。 当有人购买一张100单位的礼品卡，那意味着你欠对方100单位的商品，而不是收入。将礼品卡销售直接记为收入，你会夸大数字并造成税务混乱。将未结余额作为递延收入跟踪，仅在兑换（或法律允许的过期）时确认收入。导出工具的存在部分是为了让你能够向会计师提供该负债的清晰快照。

代码就是现金。 礼品卡代码是一种不记名票据，无论谁持有它都可以消费。如果代码泄露、被截图或可被猜测，那就是真金白银流失。请监控活动日志，切勿以明文日志暴露代码。

退款流向至关重要。退还礼品卡订单货款，和把退货款项退回客户礼品卡余额，是两码事。
这项功能能把资金留存在店铺内，但前提是客户提前知晓：所谓 “退款” 有可能是以店铺余额形式返还。

务必提前跟客户讲清规则，否则客户会觉得你玩文字套路、虚假诱导；而客户信任这种东西，是没办法靠导出 CSV 表格挽回的。

Developer reference: hooks, filters, REST, classes

下面进入开发者真正关心的底层技术部分。下文所有内容均对照插件源码验证无误。我列出的全是拼写正确、可直接使用的程序标识；礼品卡数据独立存储在专用数据表，而非自定义文章类型；插件内置 v2 版本 REST 控制器，同时深度对接 WooCommerce 数据分析模块。

源码特殊坑点说明

代码库存在一处原生拼写 bug：部分邮件图片尺寸过滤器前缀写成了三个 o：wooocommerce_gc_xxx。

如果你要对接这几组过滤器，必须原样照搬这个错误拼写；如果自行修正成标准双 o 格式woocommerce_gc_xxx，你的钩子会完全失效，找不到对应过滤器。

本文后续列出的全部钩子均为标准双 o 写法woocommerce_gc_，也是 99% 开发场景下会用到的标准标识。

过滤器

值得了解的行为过滤器：

• woocommerce_gc_auto_redeem控制礼品卡是否自动应用。
• woocommerce_gc_gift_card_amount以编程方式调整礼品卡的金额。
• woocommerce_gc_disable_quantity_selector隐藏礼品卡产品上的数量选择器。
• woocommerce_gc_checkout_show_balance_checkbox切换结账时的“使用我的余额”复选框。
• woocommerce_gc_checkout_show_codes_used 和 woocommerce_gc_checkout_show_remaining_balance_per_gift_card控制结账时显示哪些兑换详情。
• woocommerce_gc_force_send_gift_card_hook强制礼品卡发送操作。
• woocommerce_gc_giftcards_importer_parsed_data在CSV导入期间处理解析后的行。
• woocommerce_gc_wcs_renewals_allow_partial_payment允许礼品卡部分支付 WooCommerce Subscriptions 续费。

以及邮件设计过滤器，用于定制礼品卡邮件的品牌风格：

• woocommerce_gc_email_card_background_color
• woocommerce_gc_email_code_text_color
• woocommerce_gc_email_message_text_color
• woocommerce_gc_email_amount_text_color
• woocommerce_gc_email_base_text_color

这里有一个实际示例。自动兑换默认关闭，且仅考虑已登录用户。假设您希望自动为这些已登录用户启用，并希望邮件背景与您的品牌蓝色一致：

add_filter( 'woocommerce_gc_auto_redeem', function( $auto_redeem ) {
    // Opt logged-in customers into auto-applying their gift-card balance (off by default).
    return is_user_logged_in() ? true : $auto_redeem;
} );

add_filter( 'woocommerce_gc_email_card_background_color', function( $color ) {
    return '#1a8fc4';
} );

第二个示例。让礼品卡支付部分订阅续费，而不是当余额不足以支付全部时被拒绝：

add_filter( 'woocommerce_gc_wcs_renewals_allow_partial_payment', '__return_true' );

操作

将这些钩子用于在适当时机注入标记或运行逻辑：

• woocommerce_gc_before_apply_gift_card_form / woocommerce_gc_after_apply_gift_card_form，在结账时的“应用优惠码”表单周围。
• woocommerce_gc_before_account_giftcards / woocommerce_gc_after_account_giftcards，在“我的账户”中的礼品卡列表周围。
• woocommerce_email_gift_card_html，礼品卡邮件正文，在渲染自定义邮件内容时需定位的钩子。
• woocommerce_gc_before_delete_gift_card，在卡片删除前触发（适合用于记录或阻止操作）。
• woocommerce_gc_before_add_pending_balance_tracking，围绕待处理余额跟踪。
• woocommerce_gc_after_process_post_data，在插件处理已提交的礼品卡数据之后。
• manage_gc_giftcards_custom_column，在礼品卡仪表盘列表中渲染自定义列。

一个简短示例：在“我的账户”礼品卡列表上方添加一条备注：

add_action( 'woocommerce_gc_before_account_giftcards', function() {
    echo '<p class="gc-note">Gift card balances never expire on this store.</p>';
} );

类

源代码按清晰的类职责组织，有助于您追踪行为：

• WC_GC_Account，“我的账户”礼品卡与余额集成。
• WC_GC_Activity_DB， WC_GC_Activity_Data, WC_GC_Activity_List_Table，自定义表格存储和仪表盘列表。这证明了存储是基于表格的，而不是基于CPT的。
• WC_GC_Admin_Refunds，退款到礼品卡的逻辑。
• WC_GC_Admin_Importers 和 WC_GC_Admin_Exporters，批量CSV导入和导出。
• WC_GC_Admin_Reports，管理员报告。
• WC_GC_Analytics_Issued_Data_Store 和 WC_GC_Analytics_Expired_* 集合（包括一个REST控制器），WooCommerce Admin Analytics集成，该集成显示已发放和已过期的礼品卡报告。

REST API

该插件通过专用的注册REST路由 v2 礼品卡控制器 (class-wc-gc-rest-api-gift-cards-v2-controller.php）以及独立的分析 REST 控制器。礼品卡路由注册在 wc/v2 命名空间下，使用 gift-cards 基础路径，因此您可以通过 REST 读取和管理礼品卡，已发放和已失效数据通过各自的分析控制器暴露。与往常一样，在硬编码之前，请确认您安装中注册的路由，但礼品卡端点确实是原生存在而非外挂的。

对于这些构建所基于的更广泛的 WooCommerce REST 和扩展约定，官方文档 developer.woocommerce.com 是权威参考，WordPress 自身的 REST API 手册涵盖了底层机制。

常见问题

销售礼品卡是否需要特殊的产品类型？
不需要。您只需选择任意普通的简单产品或可变产品，然后勾选 礼品卡 在”产品数据”面板中的复选框。没有单独的”礼品卡”产品类型需要学习。这个复选框可以将普通产品转变为发放代码的礼品卡，这实际上是整个设置中最快的部分。

客户可以自己选择礼品卡金额吗？
对于单个固定值，设置一个常规价格即可。对于多个预设面额或客户输入金额，您可以利用WooCommerce的可变产品机制应用于礼品卡产品。这可行，但并不是一个一键式的”添加面额”小工具，具体界面取决于产品的结构方式。在向客户承诺”任意金额”之前，先构建一个测试产品，确认金额选项表现符合预期。

我可以在购物车页面让人们兑换礼品卡，还是只能在结账时？
两者皆可。结账时兑换是默认开启的，还有一个购物车设置，可以让购物者在购物车页面就使用礼品卡，这样他们能更早看到调整后的总额。在较长的多步骤结账流程中，启用购物车页面兑换可以减少”我的代码生效了吗？”的焦虑。在单页结账中这可能多余，所以取决于您的销售漏斗设置。

它是否支持新的区块式结账？
是的。该插件提供了基于WooCommerce Store API的第一方区块结账集成，因此礼品卡兑换在区块式结账界面中也能工作，而不仅仅是经典的短代码结账。明智的做法是在上线前用您的实际主题测试一次订单，这与任何结账定制所需的谨慎相同，但区块兑换是开箱即支持的。

我应该设置礼品卡过期吗？
通常不，并且插件默认设置为 从不 出于法律原因。美国《信用卡责任与披露法案》(CARD Act) 规定商店礼品卡有效期不得少于五年，而许多其他地区则完全禁止设置有效期。通过设置较短有效期来提高”破损率”（未兑换余额）在你经营的地方可能违法。如果确实要设置，请检查你销售所及每个地区的法律，并考虑开启到期提醒邮件，以免顾客措手不及。

未兑换的礼品卡资金能否直接算作免费收入？
并非售卡当日。已售出的礼品卡是一项负债，是你欠下的商品，而非收入。根据特定的会计准则，通常只有在法律允许的情况下，在合法有效期过后，你才能将未兑换部分（即”破损额”）确认为收入。使用导出工具，向你的会计提供一份清晰的未使用余额快照，并将礼品卡销售记为递延收入，而非直接计入营收。

退还礼品卡购买款项与退款至礼品卡有何区别？
这是两个不同的交易，都用了”退款”一词。退还 购买款项 是将买家购买礼品卡的钱退还给买家。退款 至 礼品卡则是将商店积分（通常因退货产生）存入卡内，供顾客日后消费。请制定你的政策，并提前告知顾客：若退货默认发放商店积分，否则”退款”一词可能会让人有被欺骗之感。

这与 YITH WooCommerce Gift Cards 或 Smart Coupons 有何不同？
这是WooCommerce官方扩展，它将礼品卡存储在自定义数据库表中，原生地将发行/过期报告接入WooCommerce Analytics，并提供了v2礼品卡REST API。YITH将每张卡存储为 gift_card 自定义文章类型。Smart Coupons是一个一体化优惠券套件，其中礼品券和商店信用是更大工具集的一部分。根据您是否需要专注的原生扩展、YITH系列的适配，或完整的优惠券套件来选择。

礼品卡可以用于支付订阅续费吗？
部分可以，需要开发者切换启用。该插件提供了 woocommerce_gc_wcs_renewals_allow_partial_payment它允许礼品卡余额支付WooCommerce Subscriptions续费的一部分，而不会因为余额不足全额而被拒绝。如果循环计费是您商店的核心，请在启用之前慎重决定礼品余额与续费的交互方式。

总结

在真实商店中完整测试后，我的看法很简单。WooCommerce Gift Cards只做它应该做的一件事，并且以WooCommerce其他部分的方式运作：产品上的复选框、存储在专用表中的余额、Analytics中的报告，以及当管理后台不够用时使用的REST API。支持定时发送的礼品表单是真正推动收入的功能，因为它能在犹豫不决的购物者准备消费的那一刻抓住他们。

它并非完美无缺。多面额路径依赖于可变产品而非专用控件，仪表盘在产生销售之前保持空白，并且正确的金额选项需要测试产品。这些都并非致命问题；它们只是这个选择了专注而非庞大功能列表的工具的粗糙边缘。

我真正想告诉您的是：如果您销售任何因品味、尺寸或场合而难以直接送礼的商品——例如沙龙、服装店、礼品店、课程——这是最清晰的原生方式，能将“我不知道该给他们买什么”转化为您能留住的销售。只需采用符合法律的过期政策，并找一位知道这些余额是负债而非意外之财的会计。把这两件事做好，礼品卡计划就会悄然复利：您卖出的每一张卡都是一次已经付款的未来光顾。

文章开头那位犹豫不决的购物者呢？当货架上有了礼品卡，他们不会关闭浏览器标签页。他们会结账。