定价出了国门，不能只换个货币符号：vibe 项目的多币种与本地化定价实战

站内有一篇《定价与收费墙设计实战》，讲的是定价结构：三档怎么分、免费试用怎么给、收费墙插在哪。本文讲的是定价的下一站：出了国门怎么办——用户在德国、印度、巴西打开你的价格页，看到的应该是什么货币？汇率谁定？税谁交？那篇管"定什么价"，这篇管"价怎么卖到全世界"。另有一篇《一人团队税务合规指南》讲的是你个人的税务申报；本文只讲产品侧的收税和开票——Checkout 那一刻发生的事。

美元定价的隐形税：非美用户多付 3-5%

几乎所有 vibe coding 项目的定价页都是这样起步的：$19/月，全世界一个价。看起来很公平，对吧？但对一个德国用户来说，真实发生的是：Stripe 按美元扣款，他的银行再按发卡行汇率 + 1-3% 货币转换费换成欧元。他付的不是 $19，是 €17.6 加一笔说不清的手续费——而你的竞争对手（做了本地化定价的）标价 €19 全包。

这笔"隐形税"有三个后果：

• 转化率漏损：价格页显示 $19，Checkout 显示 €17.83（含换汇），用户觉得"被加价了"，弃单。
• 客服工单："为什么扣的和标价不一样？"——每单都要解释一遍。
• 退款纠纷：用户按欧元算了一笔账，觉得多扣了，Stripe dispute 一开，你的拒付率上去。

结论：出海第一天就要想货币问题，不是"等有海外用户再说"。因为货币策略一旦定下来，价格表、Checkout、发票、退款全都要跟着改——晚改的成本是早改的 10 倍。

三种货币策略：没有最好，只有最配

图 2：三种货币策略。演进路线通常是：统一美元 → 自动换算 → 本地化定价，每一步都是上一阶段"有量了"之后的升级。

• 统一美元定价：全世界 $19，Stripe 自动换汇。零开发，适合刚起步、海外用户 <10% 的阶段。代价是用户承担换汇费。
• 自动汇率换算：$19 × 实时汇率 = €17.42，取整到 €17。看着本地化了，但价格每天浮动——用户今天看 €17、明天看 €17.5，信任感差。适合过渡期。
• 本地化定价：美国 $19、欧洲 €19、印度 INR 499，人工定价。转化率最高（价格稳定、符合当地心理价位），代价是维护一张定价表 + 防套利。适合"有量之后"。

一个观点：货币策略是跟着"海外收入占比"演进的，不是一步到位的架构。海外 <10% 用统一美元，10-30% 上自动换算，>30% 做本地化定价。提前做本地化定价，等于给还没来的用户交税。

技术实现：价格展示链路

图 1：价格展示链路。铁律：展示什么币种，就收什么币种——展示欧元、扣美元，等于让用户付一笔看不见的换汇费。

链路拆开，每一步都有坑：

1. 识别地区：IP（服务端 geo）最常用，但 VPN 用户会误判；浏览器语言是辅助信号；账号注册国家最准——用户自己选的。优先级：账号国家 > IP > 浏览器语言。给用户一个"切换地区"的手动入口，误判时有逃生通道。
2. 查定价表：有本地化价用本地化价，没有才走汇率换算。定价表存在数据库里，按 product × region 查。
3. 汇率换算：汇率每天抓一次（ECB/美联储公开接口），缓存 24 小时——Checkout 时刻的价格必须稳定，不能用户填卡号的 30 秒里汇率变了。
4. 格式化展示：Intl.NumberFormat 是标准答案。德国是 €19,99（逗号小数点），日本是 ￥2,000（无小数）。不要自己拼货币符号，格式错误比不本地化更伤信任。
5. 按展示币种结算：Stripe 建多个币种的 Price，Checkout 时传对应 priceId。展示欧元就收欧元——铁律。

// 多币种价格解析：本地化价优先，无则汇率换算（Next.js 服务端）
import { cache } from "react";

const FX_TTL = 24 * 3600; // 汇率缓存 24 小时，Checkout 价格必须稳定

// 定价表：product × region → 本地价（人工定价，无则走换算）
const LOCAL_PRICES: Record<string, { amount: number; currency: string }> = {
  "pro:US": { amount: 1900, currency: "USD" },
  "pro:EU": { amount: 1900, currency: "EUR" }, // 欧洲 €19，不是 $19 换算来的
  "pro:IN": { amount: 49900, currency: "INR" }, // 印度 INR 499，PPP 定价
};

export const getPrice = cache(async (product: string, region: string) => {
  const local = LOCAL_PRICES[`${product}:${region}`];
  if (local) return local;
  // 无本地价：美元基准 × 缓存汇率，取整到友好数字
  const rate = await getCachedFxRate("USD", regionCurrency(region));
  const converted = Math.round((1900 * rate) / 100) * 100;
  return { amount: converted, currency: regionCurrency(region) };
});

export function formatPrice(amount: number, currency: string, locale: string) {
  // 不要自己拼符号！Intl 处理逗号/小数点/符号位置
  return new Intl.NumberFormat(locale, {
    style: "currency",
    currency,
  }).format(amount / 100);
}
// formatPrice(1999, "EUR", "de-DE") → "19,99 €"
// formatPrice(1999, "EUR", "fr-FR") → "19,99 €"（符号位置都不同，别手拼）

对应的 Stripe 侧：一个产品建多个 Price（price_usd_19、price_eur_19、price_inr_499），Checkout Session 按用户地区传对应的 priceId。Price 建好后金额不可改（只能归档新建），所以调价时记得更新定价表里的映射——这是最常见的运维遗漏。

本地化定价：PPP 折扣与防套利

本地化定价的核心是 PPP（购买力平价）：印度用户的人均收入是美国的 1/20，$19 对他相当于美国人的 $380。不降价等于放弃这个市场。实战做法：

• 分档：欧美日韩澳 = 基准价；拉美/东南亚 = 6-7 折；印度/非洲 = 3-5 折。档位别太多，3 档够了。
• 定价表示例：pro 档美国 $19 / 欧洲 €19 / 巴西 R$49 / 印度 INR 499。注意欧洲 €19 不是 $19 换算（约 €17.5），而是取了当地心理价位——19 这个数字在欧洲和在美国一样好卖。
• 防套利：印度价 INR 499（约 $6），美国用户切个 VPN 就能 3 折买。手段三件套：① 支付时校验账单国家与 IP 国家一致；② 账号地区锁定（90 天只能改一次）；③ 价格差太大的档位，要求当地支付方式（UPI/PIX）。套利防的是规模化，防的不是个人——一个用户折腾 VPN 省 $13，随他去；有人批量倒卖账号，才值得你动手。

观点：PPP 定价不是"便宜卖"，是"按当地意愿付费卖"。INR 499 在印度的体感和 $19 在美国的体感接近，转化率反而更高。全球统一定价看似公平，实则是对低收入地区用户的"价格歧视"——只不过歧视的方向是把他们排除在外。

税务：卖到国外就要交税

图 3：税务合规三档。一句话：在哪收钱，就在哪交税。Stripe Tax 是 90% 一人项目的答案；月入过万刀再考虑 MoR。

这是最容易被 vibe coding 忽略的一块：你在德国收了 €19，里面含 19% 的 VAT（增值税），这笔税你要交到德国去。不交？欧盟的 VAT 合规是按"销售地"征税的，查到就是罚款。三档方案：

• 第 1 档：Stripe Tax——Checkout 时自动按用户地址算税率、自动生成税报。每月多付 Stripe 0.5% 左右的费用，90% 的一人项目到这就够了。开启就是在 Checkout Session 里加 automatic_tax: { enabled: true }，一行配置。
• 第 2 档：手动税率表——欧盟统一 20% VAT、美国大部分州数字产品免税、其他不管。简单粗暴，适合"只卖欧美"的阶段。但税率变了你要自己跟，适合有会计的团队，不适合一人。
• 第 3 档：Merchant of Record（MoR）——Paddle、Lemon Squeezy 这类平台当你的"代销商"：他们是法律上的卖家，收税、开票、报税全包，你只管收钱。代价是 5%+ 的手续费。适合月入过万刀、卖到几十个国家的阶段。

发票是税务的另一半：欧盟 B2B 客户要凭发票抵税，发票上必须有你的税号、对方税号、税率、税额。Stripe Tax / MoR 都会自动生成合规发票；自建的话，发票模板必须找会计师过一遍——格式错了，客户的财务不认，款就收不回来。

划界重申：本文只讲产品侧（Checkout 那一刻收税、开票）；你作为独立开发者的个人所得税申报，见站内《一人团队税务合规指南》，那是另一套完全不同的东西。

退款与汇率：按原币种退

多币种的最后一个坑在退款：用户用欧元付了 €19，一个月后退款，你退 €19 还是按当前汇率退？答案是：按原币种、原金额退（Stripe refund 默认就是这么做的）。

• 不要按"当前汇率换算成美元退"——汇率波动会让用户觉得少退了，dispute 见。
• 退款的换汇损失谁承担？Stripe 的规则是：退款时 Stripe 不收手续费，但当初的换汇差不退。这笔小钱你承担，别跟用户算——为几毛钱吵一架，亏的是你的评价。
• 部分退款（比如按比例退）同样按原币种算，别换算。

价格心理学：尾数定价也要本地化

$19.99 的"9"在美国是"便宜"的信号，但这个心理机制不是全球通用的：

• 日本：￥1,980 比 ￥2,000 好卖，但 ￥1,999 反而显得"算计"——日本消费者对"9 尾数"的敏感度和美国不同，取整到 980/1980 更自然。
• 中国：8 是吉利数字，￥88/￥188 的转化率玄学般地高于 ￥89/￥189。出海中国的产品，这点本地化值得做。
• 欧洲：€19 比 €19.99 更常见——欧洲人对"整数价"的接受度更高，觉得更"诚实"。
• 取整规则：自动换算来的价格（€17.42）必须取整，取到"心理价位"（€17 或 €19），而不是精确换算。精确到分的换算价，看起来像"机器算的"，信任感直接掉一档。

观点：本地化定价定的是"心理价位"，不是"汇率换算"。€19 和 $19 数字一样，但背后的逻辑完全不同——前者是"欧洲人觉得 19 欧元值"，后者是"美国人觉得 19 美元值"。汇率只是参考，心理价位才是答案。

支付方式：货币之外，本地支付更重要

做了多币种，但只收信用卡？在很多市场，这等于没做：

• 拉美：巴西的 PIX（即时转账）、墨西哥的 OXXO（便利店现金付）——信用卡普及率低，没有本地支付方式，转化率直接腰斩。
• 印度：UPI 是绝对主流，信用卡只覆盖一线城市白领。INR 499 的定价配上 UPI，才是完整的印度策略。
• 东南亚：GrabPay、GCash、 Dana，各国都不一样。
• 欧洲：SEPA 直接扣款、iDEAL（荷兰）、Sofort（德国），信用卡反而不是首选。

Stripe 对这些大多有现成支持，开几个 payment_method_types 的事。但注意：每种支付方式的费率、到账周期、退款规则都不同，接之前看一眼文档里的费率表。观点：货币解决"看得懂"，支付方式解决"付得出"——前者是体验问题，后者是生死问题。

免费试用与多币种：试用到期扣哪种货币

试用期 + 多币种有个经典坑：用户在印度用 INR 499 的价格开始 14 天试用，到期扣款时，你按什么扣？

• 锁定试用开始时的币种和价格：试用开始显示 INR 499，到期就扣 INR 499。用户预期明确，无纠纷。
• 不要试用期间调价：试用第 10 天你把印度价调到 INR 599，到期扣 599——用户会觉得被"钓鱼"。调价只影响新用户，老用户（包括试用中的）按开始时的价格走。
• 试用结束提醒邮件写清楚币种："3 天后将从你的卡扣除 INR 499"，而不是"扣除 $6.01"——提醒邮件里的币种必须和当初展示的一致。

这和收费墙那篇的"试用选型"是上下游关系：那篇决定"给不给试用、给多久"，这篇决定"试用在多币种下怎么结算"。两篇拼在一起，才是完整的试用策略。

数据分析：按币种看收入，别被汇率骗了

多币种上线后，你的 MRR（月度经常性收入）会变成一个"汇率幻觉"重灾区：

• 统一记账本位币：选美元（或你的主币种），所有收入按入账当日汇率折算。不要按"当前汇率"重算历史——上个月赚的 €1000，上个月值 $1080，这个月值 $1050，历史数据不许变。
• 分币种看增长：dashboard 里除了总 MRR，加一列"按币种拆分"。你会发现"总 MRR 涨了 5%"可能是"美元涨了 10%、欧元跌了 5% 对冲"——币种结构变化本身就是信号（比如某个市场在爆发）。
• 汇率波动准备金：欧元收入占比超过 30% 时，考虑留 3-5% 的汇率波动准备金。不是让你去炒外汇，而是别让"欧元跌 5%"变成"这个月白干了"的惊吓。

真实故事：改版价格页的 30 天

虚构但典型的故事：独立开发者阿南的 SaaS，美国用户占 70%，欧洲 20%，其他 10%。价格页只有美元价。某天他做了三件事：① 欧洲用户显示欧元价（€19，含税价明示）；② 加了 Stripe Tax；③ 德国加了 SEPA 支付。

30 天后数据：欧洲转化率从 1.1% 涨到 1.7%（+55%），客服"价格疑问"工单从每周 8 封降到 1 封，欧洲退款率从 4.2% 降到 2.8%。总改动：一个周末。阿南的总结很实在："我以前觉得多币种是'大公司才做的事'，现在觉得它是'有欧洲用户就要做的事'——门槛不是技术，是我以为门槛很高。"

这个故事的启示：多币种的 ROI 在"已有海外用户"的产品上是立竿见影的，因为它在修的不是"增量"，而是"漏损"——那些本来要付钱、被货币体验劝退的人。

货币切换器的 UX 细节

价格页右上角的货币切换器（USD ▾），是个小功能，但细节决定信任感：

• 默认选中用户地区货币，而不是默认 USD。德国用户打开看到 $19，还要手动切欧元——第一步就输了。
• 记住用户选择：localStorage 存下来，下次打开直接用。用户切到欧元，说明他想看欧元，别每次都重置。
• 切换时注明"含税/未税"：欧洲习惯标含税价，美国习惯标未税价。切换货币时顺手把税的口径也切了——€19（含 VAT）和 $19（+tax）是两套话术，写死一套会吓跑另一半人。
• Checkout 页不许再变：价格页切了欧元，Checkout 必须还是欧元。两边不一致是最伤信任的——用户会立刻关掉页面，因为"价格变了"在任何文化里都是危险信号。

B2B 与 B2C：两套不同的货币逻辑

上面讲的都是 B2C（个人用户）。如果你卖的是团队版/企业版，货币逻辑不一样：

• B2B 按"客户账单地"不按 IP：企业客户在德国注册、员工在全球出差，IP 天天变。货币按公司注册地锁定，写进合同。
• 企业客户要报价单（Quote）：$19×50 席 ×12 个月 = $11,400，财务要走审批。报价单锁定 30 天价格和币种——这 30 天内汇率怎么变都不影响，自建报价单系统或用 Stripe Quotes。
• 发票是刚需不是赠品：B2C 用户不在乎发票，B2B 客户没有合规发票就不付款。B2B 的发票必须支持：税号、公司抬头、明细行、付款期限（Net 30）。
• 年度付的汇率锁定：年付 €228，一次性扣，锁定 12 个月。别搞"每月按当月汇率扣"——企业财务最恨不确定性。

一句话：B2C 的货币是"体验问题"，B2B 的货币是"流程问题"。前者拼的是本地感，后者拼的是财务合规。你的产品如果两条腿走路，两套逻辑都要有。

上线 Checklist

• 货币策略已定：统一美元 / 自动换算 / 本地化定价（按海外收入占比演进）
• 地区识别三信号：账号国家 > IP > 浏览器语言 + 手动切换入口
• 定价表 product × region，本地化价优先、换算兜底
• 汇率缓存 24 小时，Checkout 价格稳定
• 价格展示用 Intl.NumberFormat，不手拼货币符号
• 展示什么币种、收什么币种（Stripe 多币种 Price 对应）
• PPP 分档定价 + 防套利三件套（账单国校验/地区锁定/当地支付）
• Stripe Tax 已开（automatic_tax.enabled），发票自动生成
• 月入过万刀且多国销售 → 评估 MoR（Paddle/Lemon Squeezy）
• 退款按原币种原金额，不换算

最后说句实话：多币种这套东西，技术上都不难——难的是意识。AI 不会主动提醒你"德国用户要交 VAT"，它只会把 $19 翻译成 €19 放在那。而出海产品的生死，往往就藏在这些"翻译一下就行"的地方。定价出了国门，拼的不是价格，是本地感：当地货币、当地格式、含税价、合规发票——每一处都在告诉用户："我是为你这个市场准备的。"

而本地感的终极检验很简单：找一个目标市场的朋友，打开你的价格页和 Checkout，全程不解释，看他有没有皱眉。皱眉的地方，就是本文 checklist 里你还没打勾的那一项。