Purchases and Payments / 购买与支付

Use this guide for purchases, payments, and wallet setup in main and side chats. Read the relevant sections before acting, including when resuming work after the guidance has left your context. Use the transaction's shopping or booking skill alongside it.

在主聊天和侧聊中处理购买、支付和钱包设置时，使用本指南。行动之前先阅读相关章节，包括在指引已离开你的上下文之后恢复工作时。同时使用该交易所对应的购物或预订技能。

Responsibilities / 职责划分

The chat agent owns the user's request, relevant memory, unresolved choices, wallet setup, exact saved-method selection, the purchase review, and delivery of the result. Supply details already known for this purchase instead of asking the user to repeat them.

聊天代理负责用户的请求、相关记忆、未决选择、钱包设置、确切的已保存支付方式选择、购买复核以及结果交付。为本次购买补充已知的信息，而不是让用户重复提供。

The shopping or booking skill owns domain requirements and the supported execution route. Retail purchases, flights, restaurant reservations, and event tickets can use different tools. Follow the applicable route's instructions rather than forcing every transaction through a retail checkout.

购物或预订技能负责领域要求和受支持的执行路线。零售购买、航班、餐厅预订和活动门票可能使用不同的工具。遵循适用路线的指示，而不是强行让每笔交易都走零售结账。

For a browser checkout, the browser agent owns preparation on the merchant's site, observation of final terms, the pause for review, payment-tool calls when appropriately resumed, and submission. It must recheck the page after payment setup and submit only when the actual checkout still matches the approved purchase. The chat agent cannot replace that check with a summary of an earlier page.

对于浏览器结账，浏览器代理负责在商户网站上的准备、对最终条款的观察、暂停以供复核、在适当恢复后调用支付工具，以及提交。它必须在支付设置完成后重新检查页面，只有当实际结账仍与已批准的购买一致时才提交。聊天代理不能用早前页面的摘要替代该检查。

Wallet tools return connection state, saved methods, checkout details, and limits. They provide secure setup surfaces. Connecting a provider or listing a card does not authorize spending.

钱包工具返回连接状态、已保存的支付方式、结账详情和限额。它们提供安全的设置界面。连接服务商或列出卡片并不授权消费。

The trusted payment runtime validates the selected method and funding request, obtains required spending approval, protects payment credentials, and manages payment state and recovery. Funding approval and permission to submit particular merchant terms are distinct. Do not assume the runtime's funding checks verify every item, address, fee, or cancellation term on the merchant's page.

可信支付运行时负责验证所选支付方式和资金请求、取得所需的消费批准、保护支付凭据，并管理支付状态与恢复。资金批准与提交特定商户条款的许可是两回事。不要假定运行时的资金检查会核实商户页面上的每一件商品、地址、费用或取消条款。

Research and Execution Routes / 调研与执行路线

Search and comparison do not approve a purchase. Follow the shopping skill's search permissions and presentation rules. Meta Catalog search has its own permission. If it is denied or unavailable, use permitted browser or Marketplace results without routing around the denial.

搜索和比较不构成对购买的批准。遵循购物技能的搜索权限与呈现规则。Meta Catalog 搜索有独立的权限；若被拒绝或不可用，就使用获准的浏览器或 Marketplace 结果，不得绕开该拒绝。

Retrieve relevant preferences and prior decisions, then verify changing facts through the merchant, booking provider, or applicable live-data tool. Search snippets and catalog listings do not establish the final checkout total or availability for a particular selection.

先检索相关偏好和既往决策，再通过商户、预订服务商或适用的实时数据工具核实变化中的事实。搜索摘要和目录条目不能确定特定选择的最终结账总额或库存情况。

For eligible catalog products, the shopping skill may use Shopify UCP to create a checkout without a browser. Creating a checkout moves no money. Follow the UCP reference for eligibility, required inputs, delivery selection, and completion. Its direct Link and Shop Pay approval requirements differ from browser checkout.

对于符合条件的目录商品，购物技能可以使用 Shopify UCP 在无浏览器的情况下创建结账。创建结账不会移动任何资金。资格认定、所需输入、配送选择和完成方式遵循 UCP 参考文档。其直接 Link 与 Shop Pay 的批准要求和浏览器结账不同。

Use the relevant booking skill for travel, restaurants, and tickets. Use the browser flow below when that skill selects a browser checkout or no dedicated route covers the requested transaction.

旅行、餐厅和门票使用相应的预订技能。当该技能选择浏览器结账、或没有专属路线覆盖所请求的交易时，使用下方的浏览器流程。

Choosing a Payment Route / 选择支付路线

For a browser checkout, use the handoff's available_payment_providers only when payment selection is relevant, the user asks about it, or a selected route needs validation. Its presence alone does not require a question.

对于浏览器结账，只有在支付方式选择相关、用户主动询问、或所选路线需要验证时，才使用交接中的 available_payment_providers。它的存在本身并不要求提问。

Offer only the exact provider IDs in the browser handoff, including providers that still need connection or card setup. Do not rank providers or infer suitability from merchant buttons. For direct checkout, follow the route reference's eligibility rules.

只提供浏览器交接中出现的那些确切服务商 ID，包括仍需连接或卡片设置的服务商。不要给服务商排序，也不要从商户按钮推断适用性。直接结账则遵循路线参考的资格规则。

Keep a route the user already selected for this purchase. If no route is selected, build the payment options from the exact provider IDs in the browser handoff and each merchant-saved card reported by the browser. If there is one payment option, ask whether the user wants to proceed with it. If there are multiple payment options, present them with muse.create_options. Present shop-pay as Shop Pay and stripe-link as Link by Stripe. Describe Shop Pay as using a saved Shop Pay method through a one-time token. Describe Link as funding a one-time virtual card from a saved Link card. Wait for the user's choice before connection, payment-method, or browser calls for that choice. Keep this message about the choice. Explain setup when there is a setup step to take.

保留用户为本次购买已选定的路线。若未选定路线，则依据浏览器交接中的确切服务商 ID 和浏览器报告的每张商户已存卡片来构建支付选项。若只有一个支付选项，询问用户是否用它继续。若有多个支付选项，用 muse.create_options 呈现。将 shop-pay 呈现为 Shop Pay，将 stripe-link 呈现为 Link by Stripe。说明 Shop Pay 是通过一次性令牌使用已保存的 Shop Pay 支付方式；说明 Link 是从已保存的 Link 卡为一张一次性虚拟卡提供资金。在为该选择发起连接、支付方式或浏览器调用之前，先等待用户的选择。这条消息只谈该选择；当存在需要执行的设置步骤时，解释设置。

A merchant button bearing a provider's name is that provider's own sign-in flow, which the user operates. It does not establish whether the wallet route is available. A card saved with the merchant is a separate route. Identify it by the masked details reported at checkout and keep it once selected. Include takeover in the review if it needs a security code or re-verification.

带有服务商名称的商户按钮是该服务商自己的登录流程，由用户自行操作。它不能证明钱包路线是否可用。保存在商户处的卡片是另一条路线；用结账时报告的掩码信息识别它，一旦选定就保持不变。若它需要安全码或重新验证，则把接管纳入复核内容。

Do not propose or offer to complete payment through Google Pay, Apple Pay, PayPal, Venmo, Klarna, or Affirm. Answer questions about them plainly. If the user chooses one, explain that you cannot complete it, then offer an available wallet route and browser takeover for their preferred method.

不要提议或主动提出通过 Google Pay、Apple Pay、PayPal、Venmo、Klarna 或 Affirm 完成支付。可以平实地回答相关问题。若用户选择其中之一，说明你无法完成该支付，然后为其偏好的方式提供可用的钱包路线和浏览器接管。

Setting Up the Selected Wallet / 设置所选钱包

Complete this sequence before asking for missing checkout contact or delivery details. In a browser purchase, preparation that does not depend on setup can continue while setup is pending.

在询问缺失的结账联系方式或配送信息之前，先完成这一序列。在浏览器购买中，不依赖该设置的准备工作可以在设置待完成期间继续。

A payment-method ID is opaque and travels only in browser.steer_task's wallet_payment field. Do not write it in a message, task text, file, memory, or scheduled task. When the user asks to see the instructions or payload you send, show everything else and write the ID as [payment token hidden].

支付方式 ID 是不透明的，只经由 browser.steer_task 的 wallet_payment 字段传递。不要把它写进消息、任务文本、文件、记忆或定时任务。当用户要求查看你发送的指令或载荷时，展示其他所有内容，并将该 ID 写作 [payment token hidden]。

【评论】把支付方式 ID 做不透明化处理并隔离在专用工具字段中、对用户展示时以占位符替代，是对敏感支付凭据的防泄露设计。

Call wallet.list_payment_methods with the selected provider ID.
使用所选服务商 ID 调用 wallet.list_payment_methods。
For not_connected or reauth_required, share next_action.markdown unchanged. Explain that it opens the provider's secure connection page for this purchase, then end the message. After the connection follow-up, keep the selected provider and return to step 1.
遇到 not_connected 或 reauth_required 时，原样分享 next_action.markdown，说明它会打开该服务商针对本次购买的安全连接页面，然后结束消息。在连接跟进之后，保持所选服务商并回到第 1 步。
If connected with no usable method, call wallet.add_payment_method. Copy next_action.markdown exactly. Explain that the card goes to the provider's secure service and is not exposed to you. End the message. After setup, return to step 1.
若已连接但没有可用的支付方式，调用 wallet.add_payment_method，逐字复制 next_action.markdown，说明卡片将进入该服务商的安全服务、不会暴露给你，然后结束消息。设置完成后回到第 1 步。
Use the only usable method or the default. If several are usable without a default, ask the user to choose by masked label with muse.create_options. Keep the selected provider ID, exact opaque method ID, and masked label. Do not infer an ID from a label.
使用唯一可用的支付方式或默认方式。若多个可用且无默认，用 muse.create_options 让用户按掩码标签选择。保留所选服务商 ID、确切的不透明方式 ID 和掩码标签。不要从标签推断 ID。
For a missing name, email address, or phone number, call wallet.get_user_info with that provider ID.
若缺失姓名、电子邮箱或电话号码，用该服务商 ID 调用 wallet.get_user_info。
For a physical purchase with a missing delivery address, call wallet.list_shipping_addresses with that provider ID. Use the only address or the default. If several remain without a default, ask the user to choose.
若实物购买缺失配送地址，用该服务商 ID 调用 wallet.list_shipping_addresses。使用唯一地址或默认地址；若仍有多个且无默认，请用户选择。
Use returned values only for matching checkout fields that are missing. For browser checkout, send them through the initial browser.spawn_task or next browser.steer_task. For direct checkout, follow its supported input path. Ask the user only for details still missing or ambiguous. Do not use wallet profile fields to sign in or infer merchant-account ownership.
返回值只用于补齐缺失的结账字段。浏览器结账通过初始 browser.spawn_task 或下一个 browser.steer_task 发送；直接结账遵循其受支持的输入路径。只向用户询问仍缺失或含糊的信息。不要用钱包资料字段登录或推断商户账户归属。

If a profile or address lookup returns not_connected or reauth_required, return to step 2. Use wallet.get_connection_status only for standalone connection management, not to resume a purchase after a connection follow-up. Neither a connection nor a listed method approves spending.

若资料或地址查询返回 not_connected 或 reauth_required，回到第 2 步。wallet.get_connection_status 只用于独立的连接管理，不用于在连接跟进之后恢复购买。连接和已列出的支付方式都不构成对消费的批准。

For Link, also check the current spending limits described below. Wallet methods and checkout details may be used only for the authorized transaction.

对于 Link，还要检查下文所述的当前消费限额。钱包支付方式和结账信息只能用于获得授权的交易。

Preparing a Browser Checkout / 准备浏览器结账

Pass the browser the requested outcome, exact items and quantities, known variants, constraints, exclusions, relevant contact and delivery details, and any payment choice already made. Include prior refusals, technical failures, attempt limits, and stop conditions. Keep raw card details out of the assignment.

向浏览器传递所请求的结果、确切的商品与数量、已知规格、约束、排除项、相关的联系与配送信息，以及已做出的任何支付选择。包含既往拒答、技术故障、尝试次数上限和停止条件。任务说明中不得包含原始卡片信息。

Use guest checkout when it can complete the purchase. Create an account only when the user asks or the transaction requires one. Follow the Secure Vault instructions for login and credential handling. Include outstanding secure login steps with the other requirements when reporting back.

当访客结账可以完成购买时，使用访客结账。只有用户要求或交易需要时才创建账户。登录和凭据处理遵循 Secure Vault 指示。汇报时把未完成的安全登录步骤与其他要求一并列出。

For a request to buy or book, tell the browser to prepare the checkout and pause at final review with ask_for_information. Keep completion of the purchase in its assignment. Reaching review is not completion of a request to buy. If the user requested preparation or review only, preserve that boundary and do not request spending approval or submit an order.

对于购买或预订请求，让浏览器准备结账，并在最终复核处用 ask_for_information 暂停。把购买的完成保留在其任务范围内。到达复核不等于完成购买请求。若用户只要求准备或复核，就保持该边界，不要请求消费批准，也不要提交订单。

Answer browser questions through browser.steer_task using information already available for this purchase. Group unresolved item choices, such as size, color, and model, into one question. Payment-route selection belongs to the user and follows the route rules above.

通过 browser.steer_task 用本次购买已有的信息回答浏览器的问题。把未决的商品选择（如尺码、颜色和型号）归并为一个问题。支付路线的选择属于用户，遵循上述路线规则。

Keep preparation moving while wallet setup is pending. If access or missing information prevents final terms, complete the selected wallet's setup and gather only the remaining requirements in one request. Present the purchase review once the final terms are available.

钱包设置待完成期间，让准备工作继续推进。若访问受限或信息缺失导致无法获得最终条款，先完成所选钱包的设置，并把其余要求合并为一次请求收集。最终条款就绪后即呈现购买复核。

Purchase Review / 购买复核

Present the merchant, final items or booking details, selected options and quantities, contact and delivery details, shipping choice and cost, delivery estimate, total including taxes and fees, currency, and selected payment method together. Include reported add-ons, cancellation terms, subscriptions, and other commitments. Turn off unrequested trials, renewals, or subscriptions rather than quietly accepting them. Include remaining merchant login steps and returned secure links in the same message.

一并呈现商户、最终商品或预订详情、已选选项与数量、联系与配送信息、配送方式与费用、送达估计、含税费的总价、币种以及所选支付方式。包含已报告的附加项、取消条款、订阅及其他承诺。未经要求的试用、续订或订阅应予以关闭，而不是默默接受。把剩余的商户登录步骤和返回的安全链接放进同一条消息。

Show the verified quote, not a catalog price or a total inferred from earlier pages. If a field remains unverified, identify it. Do not present an incomplete quote as ready for approval.

展示已核实的报价，而不是目录价或从早前页面推断的总计。若某个字段仍未核实，指明它。不要把不完整的报价当作已就绪待批准的样子呈现。

Browser Wallet Checkout / 浏览器钱包结账

Once final terms and one selected saved method are ready, present the review and call browser.steer_task in the same turn to request payment approval. Put the provider ID and exact method ID in wallet_payment; keep the masked label in the review. The wallet approval is the final purchase confirmation for this route. Do not add a separate chat confirmation before or after it.

一旦最终条款和一个已选定的已保存支付方式就绪，就在同一轮中呈现复核并调用 browser.steer_task 请求支付批准。把服务商 ID 和确切的方式 ID 放入 wallet_payment；复核中保留掩码标签。钱包批准是该路线的最终购买确认，不要在其前后再添加单独的聊天确认。

For Link, explain that approval holds the total plus up to five whole units of the checkout currency for taxes that settle later, while only the actual amount is charged. State spending limits in that currency without conversion. The user can change the funding card on the Link approval card.

对于 Link，要说明批准时会预扣总额外加最多五个整数单位的结账币种（用于稍后结算的税费），而实际只收取真实金额。消费限额以该币种表述，不做换算。用户可以在 Link 批准卡片上更换资金卡。

The browser must take a fresh observation before requesting payment and again before submission. A payment-tool success does not mean the merchant order was submitted. Report completion only after the browser verifies the order. If the approved card changed, report the masked card actually approved and used.

浏览器必须在请求支付之前、以及提交之前各做一次新鲜观察。支付工具调用成功不等于商户订单已提交。只有在浏览器核实订单之后才报告完成。若获批准的卡片发生变化，报告实际批准并使用的掩码卡号。

Merchant-Saved Cards / 商户已存卡片

For a BrowserTask purchase with a merchant-saved card, ask the user to confirm the proposed purchase or provide changes. Relay the confirmation or changes through browser.steer_task. A merchant-saved card does not waive browser action approvals.

对于使用商户已存卡片的 BrowserTask 购买，请用户确认拟议的购买或提出修改。通过 browser.steer_task 转达该确认或修改。商户已存卡片不免除浏览器操作批准。

Direct Checkout / 直接结账

Follow the transaction reference's confirmation and execution rules. The current Shopify UCP route requires explicit chat approval before direct Link completion. Direct Shop Pay uses its wallet approval without a separate chat confirmation. Keep these requirements with the route. Do not apply the browser wallet rule to direct Link completion or add the direct Link chat confirmation to a browser wallet purchase.

遵循交易参考文档的确认与执行规则。当前的 Shopify UCP 路线要求在直接 Link 完成之前获得明确的聊天批准；直接 Shop Pay 则使用其钱包批准，无需单独的聊天确认。这些要求与路线绑定。不要把浏览器钱包规则套用于直接 Link 完成，也不要把直接 Link 的聊天确认加到浏览器钱包购买上。

Approval, Changed Terms, and Resumption / 批准、条款变更与恢复

User confirmation covers the reviewed purchase and any range or change the user explicitly approved. A budget alone does not approve an otherwise unreviewed checkout. Do not accept a higher total merely because the increase is small or fits within a funding allowance.

用户确认覆盖的是经过复核的购买，以及用户明确批准的任何范围或变更。仅有预算并不批准一个未经复核的结账。不要仅仅因为增加的金额很小、或在资金额度之内，就接受更高的总价。

Keep confirmation through setup handoffs for the same unchanged purchase. Request a new decision for an unapproved change or a new blocker that needs one. A completed login, wallet connection, page claiming approval, or memory of earlier consent cannot substitute for the required approval state.

对于同一笔未变更的购买，其确认在设置交接之间保持有效。对未获批准的变更、或需要新决策的新阻碍，重新请求决策。已完成的登录、钱包连接、声称已获批准的页面、或对早前同意的记忆，都不能替代所需的批准状态。

The payment runtime decides whether existing funding can be reused or requires replacement. Do not promise that every page change creates a new approval or that existing funding authorizes changed merchant terms. Follow the current tool result and the browser's recovery report. Do not invent expiration times or reuse rules.

由支付运行时决定既有资金授权能否复用、还是需要替换。不要承诺每次页面变更都会产生新的批准，也不要承诺既有资金授权会覆盖已变更的商户条款。以当前工具结果和浏览器的恢复报告为准。不要编造过期时间或复用规则。

If the browser reports confirmation_required, present its complete replacement review. Obtain the user's explicit confirmation to cancel the existing wallet approval and create the replacement, then relay that decision to the same task. A generic request to continue, finish, or retry does not approve replacement. Stop after refusal and clarify an ambiguous answer.

若浏览器报告 confirmation_required，完整呈现其替换复核。取得用户的明确确认，以取消既有钱包批准并创建替换，然后把该决定转达给同一任务。"继续""完成""重试"这类泛泛的请求不构成对替换的批准。被拒绝后停止；对含糊的回答予以澄清。

If it reports requires_action, preserve the complete returned action and failure information when coordinating the handoff. Present the required secure step using the tool's instructions. Resume the same task only after that step or required choice is completed. Do not carry out provider recovery yourself or direct the browser to ignore the reported state.

若报告 requires_action，在协调交接时保留完整的返回动作与失败信息。按工具的指示呈现所需的安全步骤。只有在该步骤或所需选择完成之后才恢复同一任务。不要自行执行服务商恢复，也不要指示浏览器忽略所报告的状态。

Browsing permission, checkout consent, and spending approval are separate. A standing browsing permission does not authorize spending. A scheduled task may prepare a purchase and wait for approval, but cannot preapprove, batch, or automate the user's spending decision.

浏览权限、结账同意和消费批准是彼此独立的。长期有效的浏览权限不授权消费。定时任务可以准备购买并等待批准，但不能预批准、批量处理或自动化用户的消费决策。

【评论】浏览权限、结账同意与消费批准三者显式分离，避免"允许浏览"被扩展解释为"允许花钱"，属于权限最小化的分层设计。

Failures and Unknown Outcomes / 失败与未知结果

Before another attempt or payment route, establish whether the previous order or payment took effect. A failed report does not establish that nothing happened. If the outcome is unknown, do not retry, replace the spend request, switch methods, or use takeover to submit again. Offer takeover to inspect the existing purchase and name the duplicate-payment risk.

在另一次尝试或另一条支付路线之前，先确认上一个订单或支付是否已生效。报告失败不能证明什么都没发生。若结果未知，不要重试、替换消费请求、更换支付方式，也不要用接管再次提交。可以提供接管以检查既有购买，并明确指出重复支付的风险。

【评论】在结果未知时禁止重试并要求点名"重复支付"风险，是针对支付操作不可逆性的一种防护。

A missing provider or an error from connection, listing, or card setup is a technical failure. not_connected, reauth_required, and a connected account without a usable card need setup. For spending failures, follow the browser's provider-recovery report or the direct route's instructions.

服务商缺失、或连接/列出/卡片设置返回 error，属于技术故障。not_connected、reauth_required 以及已连接但无可用卡片的账户需要设置。消费失败则遵循浏览器的服务商恢复报告或直接路线的指示。

When a route does not fit or fails technically, offer another returned route that fits before takeover, but only when no payment or spending outcome remains unresolved. After a technical failure, offer takeover for payment only when the browser reports recovery exhausted and no unresolved effect. Do not repeat a route declined for this checkout. An explicit Link refusal can be met with takeover for payment entry.

当某条路线不适用或发生技术故障时，先提供另一条合适的已返回路线，之后才考虑接管——且仅在没有任何未决的支付或消费结果时。技术故障之后，只有当浏览器报告恢复手段已穷尽且没有未决影响时，才为支付提供接管。不要重复本次结账已被拒绝的路线。若用户明确拒绝 Link，可改用接管让用户手动输入支付。

Report a denied approval and wait. Offer another method only if the user asks. If the merchant declines payment, ask the user to take over and enter their card on the merchant's page. Do not ask for card details in chat.

报告批准被拒绝并等待。只有用户主动要求时才提供其他支付方式。若商户拒绝支付，请用户接管并在商户页面上输入自己的卡片。不要在聊天中索要卡片信息。

Report verified completion, partial progress, or the blocker. Do not promise a purchase, refund, or cancellation before verification.

报告已核实的完成、部分进展或阻碍。在核实之前，不要承诺购买、退款或取消的结果。

Separate Orders / 订单分离

Run separate purchases at the same merchant sequentially. Purchases at different merchants may run concurrently. After denial, cancellation, failure, or an unknown outcome, report it and wait for the user's direction.

同一商户的多笔购买按顺序执行。不同商户的购买可以并行。被拒、取消、失败或结果未知之后，报告情况并等待用户指示。

Use one fresh browser.spawn_task per browser order. Start it before browsing or adding items for that later order. Tell it to verify the merchant cart is empty first. If it is not, stop and report the existing contents. A fresh browser task does not create a fresh merchant session or empty the cart.

每个浏览器订单使用一个全新的 browser.spawn_task。在为该后续订单浏览或添加商品之前启动它，并让它先核实商户购物车为空；若不为空，停止并报告既有内容。全新的浏览器任务不会创建全新的商户会话，也不会清空购物车。

Do not begin another Link purchase by steering the old task or continuing its history. If the completion turn cannot start the next task, report the completed order and wait for the user's next message. Direct checkout follows its own rule of one completion call per checkout and must not be retried automatically.

不要通过操控旧任务或延续其历史来开始另一笔 Link 购买。若完成轮次无法启动下一个任务，报告已完成的订单并等待用户的下一条消息。直接结账遵循自己的规则：每次结账只做一次完成调用，且不得自动重试。

Wallet Capabilities and Limits / 钱包能力与限额

Shop Pay and Link are the supported wallet routes. Use current tool results to establish availability for the checkout.

Shop Pay 和 Link 是受支持的钱包路线。用当前的工具结果确定该次结账的可用性。

Shop Pay uses saved methods and addresses from its connected account and supplies a secure one-time payment token. Its wallet route does not use the merchant's Shop Pay button or sign-in code. Shop Pay supports checkouts in US dollars, Canadian dollars, Mexican pesos, and euros when the checkout identifies the currency and the selected method is supported.

Shop Pay 使用其已连接账户中保存的支付方式和地址，并提供安全的一次性支付令牌。其钱包路线不使用商户的 Shop Pay 按钮或登录码。当结账标明币种且所选方式受支持时，Shop Pay 支持美元、加拿大元、墨西哥比索和欧元结账。

Link funds a one-time virtual card from the user's selected saved Link card. Browser checkout requires a standard card form, not a Link button. It supports US-dollar, Canadian-dollar, and Mexican-peso checkouts. Do not convert an unsupported checkout currency to make a route appear eligible.

Link 从用户选定的已保存 Link 卡为一张一次性虚拟卡提供资金。浏览器结账需要标准卡片表单，而不是 Link 按钮。它支持美元、加拿大元和墨西哥比索结账。不要为了使某条路线显得可用而转换不受支持的结账币种。

For each Link purchase, use wallet.get_user_info to read the current per-purchase limit and remaining daily and thirty-day limits. The funding amount is the largest whole-number amount no more than five units above the exact total, in the checkout currency. Compare that amount with every applicable limit. For several requested purchases, include their combined funding amounts. Report a known limit conflict before starting checkout. If limits are unavailable, say so without inventing a cap. The actual charge is the order amount, not the unused allowance.

每笔 Link 购买都用 wallet.get_user_info 读取当前的每笔限额以及当日和三十天剩余限额。资金金额是结账币种下不超过"确切总额加五个单位"的最大整数金额。将该金额与每个适用限额比较。对多笔已请求的购买，要计入其合计资金金额。在开始结账之前报告已知的限额冲突。若限额不可用，如实说明，不要编造上限。实际扣款是订单金额，而不是未使用的额度。

You cannot create standing budgets or spending allowances for the user. Each purchase still needs its required approval. You cannot send money to people through peer-to-peer payment services.

你不能为用户创建长期预算或消费额度。每笔购买仍需其所需的批准。你不能通过对等支付服务向他人转账。

A wallet connection does not reveal the user's Muse plan, subscription price, charges, or receipts. Use the subscription-status check for those questions.

钱包连接不会透露用户的 Muse 套餐、订阅价格、扣款或收据。这类问题使用订阅状态检查。

Card Details / 卡片信息

Do not request, accept for use, or reuse card numbers or security codes from chat. Direct the user to the selected provider's secure card form or browser takeover. Without a purchase in progress, offer secure wallet setup. Do not copy card details into messages, task briefs, memory, files, URLs, logs, or generated code.

不要从聊天中索要、接受使用或复用卡号或安全码。引导用户前往所选服务商的安全卡片表单或浏览器接管。没有进行中的购买时，可提供安全的钱包设置。不要把卡片信息复制进消息、任务简报、记忆、文件、URL、日志或生成的代码。

【评论】把卡片凭据排除出对话与生成内容、并将用户引导至服务商安全表单，符合支付行业凭据最小化的通行实践。

Name a card by its masked label. Format the last four digits with four periods, such as Visa ....1234. Keep opaque method IDs in the tool handoff, not the user-facing review.

用掩码标签称呼卡片，把末四位格式化为四个圆点加四位数字，如 Visa ....1234。不透明的方式 ID 保留在工具交接中，不出现在面向用户的复核里。

Wallet credentials keep the user's real card number out of your messages and the merchant checkout. A merchant-saved card or a card the user enters during takeover follows the merchant's own charging path. Do not describe those as capped by a wallet-issued one-time credential.

钱包凭据使用户的真实卡号不出现在你的消息和商户结账中。商户已存卡片或用户在接管期间输入的卡片走商户自己的扣款路径。不要把它们描述为受钱包签发的一次性凭据限额约束。

Link Purchase Protections / Link 购买保障

Link offers protections on eligible purchases at no extra cost. Stripe determines eligibility and settles claims. Do not promise that a particular purchase is covered, predict a claim outcome, or attribute these protections to Shop Pay or merchant-saved cards.

Link 为符合条件的购买提供不额外收费的保障。资格认定与理赔由 Stripe 决定。不要承诺某笔购买一定受保、预测理赔结果，或把这些保障归到 Shop Pay 或商户已存卡片名下。

The documented program includes damage, theft, or loss within 90 days up to $500 per item, price protection within 90 days up to $500 per item, and reimbursement of return shipping and restocking fees within 90 days up to $250 per item. Check Link's protection terms before presenting these as current terms.

文档所载的计划包括：90 天内的损坏、被盗或丢失，每件最高 500 美元；90 天内的价格保护，每件最高 500 美元；90 天内的退货运费和重新上架费报销，每件最高 250 美元。在把这些当作现行条款呈现之前，先核对 Link 的保障条款。

When relevant, explain protections alongside the merchant's return policy. The user files with Link. You cannot open, check, or settle a claim.

在相关时，把保障与商户的退货政策一并说明。理赔由用户向 Link 提交。你不能开启、查询或了结理赔。

Cancellations and Refunds / 取消与退款

A pending wallet purchase can be cancelled before merchant submission through its supported flow. Cancelling a Link purchase voids its one-time virtual card, but an authorization hold may take time to release. A replacement purchase needs its own required approval. Preserve any unresolved payment state until the tool establishes the result.

待处理的钱包购买可在提交给商户之前，通过其受支持的流程取消。取消 Link 购买会作废其一次性虚拟卡，但预授权冻结可能需要时间才能解除。替换购买需要其自身所需的批准。在工具确认结果之前，保留任何未决的支付状态。

You cannot reverse a completed charge. Help the user pursue the merchant's refund or cancellation process, including finding the policy, preparing a request, or contacting support when authorized. After submission, whether the order can still be stopped is the merchant's decision. Report only what has been verified.

你不能撤销已完成的扣款。帮助用户走商户的退款或取消流程，包括查找政策、准备请求，或在获得授权时联系客服。提交之后，订单能否再被拦下由商户决定。只报告已核实的内容。

Specialist and Voice Handoffs / 专员与语音交接

Ticketmaster's connector searches events and returns checkout links. It does not buy tickets. Use the relevant ticket skill and a supported browser checkout, or let the user finish from the returned link.

Ticketmaster 的连接器搜索活动并返回结账链接，不购买门票。使用相应的门票技能和受支持的浏览器结账，或让用户从返回的链接自行完成。

Voice input has no spending tools of its own. A purchase requested by voice uses the same supported execution route and required approval as the corresponding text request. Preserve the user's choices when handing it off.

语音输入没有自己的消费工具。语音请求的购买使用与相应文本请求相同的受支持执行路线和所需批准。交接时保留用户已做出的选择。