BigCommerce 官方把店铺币种区分为 active currency 和 transactional currency 两类；这两种口径并不必然相同。官方币种概览明确说明，active currency 可能仅用于展示，订单则仍以店铺默认币种交易。因此，别把商品页的币种符号当成最终扣款证明：先确认币种用途，再对照结账说明和订单记录；三处不一致时，先暂停扩大流量，查清配置与支付方式。
跨境卖家：准备启用或调整多币种展示，需要确认买家实际看到和支付什么。
独立站运营人员：需要回应买家对价格或扣款币种的疑问。
上线验收负责人：需要留存跨市场核验依据，并决定通过、修复或暂缓上线。
先区分页面展示与支付交易的币种口径
BigCommerce active currency 是买家当前看到的呈现币种；它可能只是展示用途，也可能与实际交易币种相同。BigCommerce transactional currency 则是 BigCommerce 传给支付提供方、用于处理买家付款的交易币种。商家到账的结算币种又是另一层口径，不能拿结算单上的币种倒推买家看到或支付的币种。
这也回答了常见的“商品页显示美元，结账会不会按美元扣款”疑问：单看商品页无法判断。如果某个币种只设为展示币种，买家可能在页面看到该币种的估算价格，而订单仍以默认币种交易；应继续读结账页对实际币种和金额的说明，并在订单记录中核实。
验收时先对照以下两种情况：
| 验收选项 | 买家侧表现 | 关键判定依据 |
|---|---|---|
| 仅展示币种 | 商品页以所选币种展示价格，结账说明实际将以另一币种交易 | 结账页明确显示实际币种和金额；订单交易币种与说明一致 |
| 交易币种 | 页面展示币种与结账交易币种一致 | 结账页的交易币种、支付方式配置及订单币种彼此一致 |
表格是核验逻辑，不代表每家店铺都会出现相同页面文案。主题、币种设置、支付方式和结账实现都会影响实际呈现；应以店铺后台和买家侧页面共同确认，不要仅凭“$”“€”等符号作结论。
用同一买家会话核对商品页、购物车和结账金额
同一会话、同一商品、同一地区入口是比对页面金额的基本条件。否则，地区识别、主动切换币种、购物车已有商品或价格表差异，都可能让前后页面看起来不一致。
先记录商品页的币种代码、商品金额、促销标记及价格说明；加入购物车后，再记录小计、折扣、税费和运费的币种与金额；进入结账时，重点抄录订单总额旁关于交易币种的说明。币种代码比货币符号更有辨识度，记录 USD、EUR 等代码，避免把不同币种共用的符号误认成同一种货币。
商品目录默认币种、按汇率换算后的展示价格，以及按币种单独设定的价格，也不是同一件事。官方文档说明，自动换算不会重写商品目录的默认价格；商家可维护换算率，或在支持条件满足时通过价格表配置不同币种的商品价格。币种在商品目录与购物车中的处理方式还指出，购物车切换币种时，已有购物车可能仍锁定原交易币种。发现金额或币种变化时，先检查当前购物车是否沿用原币种，再核对价格来源与换算设置；不要为了让某个页面数字看起来一致，就直接更改店铺默认币种。
检查折扣、税费和运费是否沿用同一口径
商品标价对上，并不表示最终应付金额已经验收通过。折扣、税费和运费可能按不同的基础价格或币种处理，因此应逐项记录金额、币种代码以及页面说明，而不是只比较总价。
特别留意以下边界：
- 折扣是否应用于当前选择的币种；优惠券、促销和客户组折扣的支持范围可能不同。
- 税费是否已含在商品展示价中，结账页是否重新计算或另行列示。
- 运费是固定费率、承运商报价，还是经过币种换算后的金额；页面显示的运费币种是否与交易币种一致。
- 店铺是否使用按币种分别配置的价格；这可能影响价格筛选或促销适用方式。
BigCommerce 文档列出多币种功能的支持与不支持项，也具体说明了促销、商品价格筛选和运费的处理差别。因此，出现差异时，应先回查店铺使用的主题、结账类型、价格配置及当前官方功能说明，再判断是预期换算还是配置缺口。官方多币种处理说明可用于核对这些功能边界；不能仅因币种符号相同，就认定各项费用都沿用相同的计算口径。
核对支付方式，再把订单字段当作验收凭据
商品页、购物车与结账页一致，仍不等于支付链路配置正确。目标交易币种须有适用的支付配置；支付提供方是否能处理该币种、支付设置是否匹配店铺渠道，以及商家最终用什么币种结算，都是不同检查点。交易币种与商家结算币种不同时，支付或发卡机构可能按自身汇率换算并产生费用；这些换汇费用和费率不由 BigCommerce 控制。
如果订单币种和买家看到的价格不一致，先区分“展示币种”和“交易币种”，再看订单字段，而不要只比较金额。订单 API 文档将 currency_code 与 default_currency_code 分别用于展示币种和交易币种，并说明多币种订单还可能带有店铺默认币种及其兑换率字段。订单币种字段说明可帮助技术人员交叉确认后台记录；运营人员也可以先在订单详情和导出记录中查找币种代码及结账记录，再交由技术人员核对字段含义。
按以下 6 步留存一组可复核的验收记录：
- 记录入口和会话条件。 写明测试市场入口、主动选择的币种或默认币种状态，并用全新会话开始复测。
- 固定测试商品。 选定一个商品与具体规格，保存商品页上的金额、币种代码、促销信息和价格说明。
- 检查购物车。 记录小计、折扣、税费和运费；不要在购物车已有商品时切换币种后，就默认认为交易币种已改变。
- 抄录结账说明。 保存支付方式列表、订单总额、实际交易币种提示及任何换算说明；不要仅凭支付标志或币种符号推断结果。
- 核对订单记录。 完成获准的测试流程后，将买家侧记录与后台订单的展示币种、交易币种及金额字段交叉比较。
- 分别复测主动选择和默认币种。 两种会话分开记录，保留页面截图、结账说明与订单记录的对应关系，避免把前一次会话的购物车状态带入下一次判断。
支付提供方配置也要单独确认。部分交易操作要求支付提供方按订单对应的币种与渠道完成配置；配置不匹配时，后续交易管理可能出现问题。交易与支付提供方配置要求可作为技术核查入口。支付条件应以店铺当前后台、提供方账户和官方支持范围为准，不要把某一店铺的可用方式推广为所有店铺都适用。
用真实 Safari 买家会话复测，再作上线判断
Safari 买家侧验收的重点是复现买家实际经过的入口、商品页、购物车和结账说明，而不是只看后台预览或响应式视口。使用 Safari 建立干净会话，按市场入口进入页面，记录币种选择状态；再完成上述页面核验。若需要排查页面脚本或网络请求，可用 Web Inspector 检查资源与运行情况。Web Inspector 功能说明将其定位为检查和调试网页的工具，并不替代真实的支付授权或成功扣款证明。
Safari 响应式设计模式适合观察视口尺寸、像素比例和页面布局变化，但 Apple 的文档明确提醒：预设视口只是近似模拟，不能完全代表真实设备上的布局与行为。需要验收移动端实际交互时，应另外使用模拟器或真实设备测试；不能把响应式预览截图当作真实手机买家体验的证据。响应式设计模式的用途和边界和连接设备进行网页检查的方法说明了两类测试的区别。
最终可以按证据作出三种判定：
- ✅ 通过： 商品页与购物车金额口径可解释，结账页明确给出交易币种，订单记录也与结账结果相符；目标支付方式已确认适用。
- ⚠️ 修复后复测： 展示价、折扣、税费或运费有差异，但能定位到换算、价格表、购物车币种锁定或主题展示问题。
- ❌ 暂缓上线或扩大流量： 结账页没有清楚说明实际交易币种，订单字段与买家侧记录矛盾，或支付方式对目标币种的支持尚未确认。
若团队目前靠个人电脑轮流测试，常见问题是 Safari 环境难以复现、会话状态互相干扰，以及截图和配置记录分散；临时借用设备也不一定能持续保留同一测试环境。若任务需要反复进行 Safari 买家侧复测，可评估 RUVCLOUD 的远程 Mac 方案，先确认所需地区、访问方式与团队权限是否适用，并比较套餐信息及美国节点选项。这类环境仅用于获得远程 macOS/Safari 测试条件，不会改变 BigCommerce 的支付资格、店铺规则或交易结果；若测试长期高频且需要物理接口，自购设备或真实移动设备可能更合适。