驾驭多币种支付：金融机构如何构建高效一卡多钱包管理体系

在东京使用一张多币种卡进行支付，其体验与任何其他银行卡交易无异。

然而，在这看似简单的支付背后，发卡机构需要执行一系列复杂操作：识别交易币种、匹配对应钱包、判断是否存在余额不足并决定是否启用其他账户进行补足，并在必要时进行外汇兑换。

随后，这笔交易必须在项目记录和外部合作伙伴之间完成授权、清算与对账。

越来越多的消费者正在进行这类支付，这也使得其背后的复杂性日益凸显。

据统计，2025年亚太地区发行的银行卡跨境交易量增速是境内交易量的两倍多，而旅游商户的消费支出增速则达到整体银行卡消费增速的约2.5倍。

联合国旅游组织数据显示，2025年前三个月，全球国际旅行人次已超过3亿，较上年同期增长5%。

阿联酋的LuLu Exchange在构建其多币种卡项目时，就曾面临实际运营挑战。

尽管该产品首先在一个市场推出，但其所涉及的架构问题具有更广泛的普适性。

任何机构若要开发类似产品，都需要一个清晰的运营层来协调涉及的系统与合作伙伴。

一方面，传统银行卡通常只检查一个主账户余额来批准交易。

而多币种项目则可能拥有多个活跃钱包，每个钱包都拥有独立的余额、消费限额、定价和费用规则。

在授权之前，发卡平台需要明确哪一个钱包应为此次购买提供资金，以及当该钱包余额不足时应如何处理。

大多数金融机构都可以获取这些单独的组件，因为发卡方、处理方、外汇提供商、清算合作伙伴和对账工具都已成熟。

这种碎片化的技术堆栈表明，这些功能组件可能分散在多个供应商之间。

例如，发卡功能连接至钱包管理，处理功能负责交易授权，外汇提供商管理货币兑换。

而清算和对账可能在其他地方进行，这使得金融机构不得不手动管理它们之间的对接。

增加一种货币可能需要在更广泛的银行卡项目中进行调整，而不仅仅是钱包本身。

当这些更新分散在不同供应商处时，一个相对常规的产品决策就可能演变为一个庞大的技术项目。

以往的尝试往往依赖于独立的处理系统、发卡基础设施、外汇提供商和清算系统。

尽管每个组件都执行其特定功能，但公司缺乏一个统一的运营层来管理整个项目的逻辑。

在该公司的交易量级别上，这种架构限制了产品的进一步发展。

引入新币种可能需要全新的集成工作，而调整交易限额或费用则成为涉及多家供应商的协调难题。

规模化发展意味着在交易量增长的同时，运营复杂性也随之增加。

LuLu Exchange业务转型副总裁Joseph Cleetus表示：“我们一直在寻找合适的合作伙伴来支持推出我们的多币种卡，Stitch的解决方案立刻引起了我们的共鸣。”

Cleetus指出，Stitch与LuLu Exchange团队紧密合作，协助该公司管理将该项目推向市场所涉及的外部利益相关方。

Stitch将发卡、交易处理、外汇、账本管理和对账等功能整合到一个统一的运营环境中。

统一的数据模型让LuLu Exchange能够共享账户余额和交易活动的视图，而一套标准化的API则允许在不为每个功能维护独立连接的情况下管理项目规则。

在新的架构中，交易处理和外汇功能与钱包管理紧密连接，而银行卡组织连接、清算和对账则在另一端运行。

底层账本则记录着项目中的余额和交易流动情况。

银行赞助商和支付网络继续履行各自的职能，而Stitch则在这些关系之间协调卡片、钱包和交易逻辑。

统一的运营层还赋予产品团队更多控制权，能够灵活调整卡片的行为模式。

币种、费用、交易限额和钱包优先级都可以在项目内部进行配置，而无需分散在多个供应商系统之中。

架构决策决定了产品团队在产品上线后能保留多少控制力。

机构需要清楚，币种、限额和定价的调整是通过简单配置即可实现，还是每一次更新都需要投入工程资源、获得供应商批准并进行新的发布。

这个问题的答案，将直接影响项目在新旅行路线产生商业价值或客户行为变化时，能够多快地作出响应。

当匹配的钱包余额不足时，项目需要制定清晰的规则，以确定接下来应使用哪个账户余额，以及交易中有多少金额需要进行货币转换。

这一决策不仅影响客户体验，也关系到机构的外汇经济效益，并决定了其运营团队后续需要对账的工作量。

维护一个可靠的“单一事实来源”同样重要，因为所有相关系统都需要一致地记录交易。

如果缺乏可靠的单一事实来源，运营人员可能需要在客户完成购买后，跨多个系统追溯不一致之处。

假设一位客户进行了一笔100新元的消费，但其欧元钱包中只剩下等值70新元的余额。

对于一个围绕单一余额设计的平台来说，拒绝支付是最简单的处理方式。

然而，一个多币种项目可以转而检查是否有其他钱包来弥补这30新元的差额。

客户可以根据偏好排列其币种钱包的优先级。当匹配的钱包余额不足时，平台会检查下一个可用钱包，并仅转换完成购买所需的金额。

因此，一次授权就可以从多个币种余额中扣款，而无需客户在支付前手动转移资金。

交易获批后，将同步更新相关钱包和账本账户。

随后的清算和对账环节将确认项目的记录与从支付网络和清算合作伙伴接收到的信息一致。

客户看到的只是一个完成的购买，而LuLu Exchange则需要确保其背后每一笔资金流动都被正确记录。

LuLu Exchange推出的可充值预付旅行卡支持阿联酋迪拉姆（AED）及其他25种货币，让客户通过一个产品即可管理26个币种钱包。

该卡通过LuLu Money应用程序以数字和实体形式提供。

支持这些多币种功能带来了持续的运营需求。

旅行模式不断变化，新的交易路线不断涌现，定价策略也需要定期审视。产品团队还可能希望引入新的钱包或调整余额的使用顺序。

Stitch的解决方案让LuLu Exchange能够灵活调整这些配置，而无需为每一次修改都重建底层架构。

该卡通过API和PCI认证的卡片小部件连接到LuLu Money应用程序。

客户无需离开现有应用程序，即可管理PIN码、调整消费限额、冻结或解冻卡片以及查看交易历史。

实施时间也将影响机构是选择内部搭建技术堆栈，还是通过统一的运营层解决方案。

Stitch表示，其平台可将实施时间缩短80%，部分项目甚至可在短短90天内上线，而传统供应商通常需要9到12个月。

LuLu Exchange在阿联酋构建了其项目，但其经验教训具有全球普适性。

只有当机构能够在不每次都重构整个技术堆栈的情况下调整其行为模式时，多币种卡才能作为一个长期产品发挥作用。

客户在支付时会根据预期判断卡的表现，他们希望使用正确的余额并顺利完成交易。

该项目能否在不进行新一轮集成和运营修复的情况下持续迭代和演进？

尽管底层基础设施对客户而言是不可见的，但它决定了金融机构能保留多少核心控制权。