如果Twitter能实现付款将如何？

如果Twitter能实现付款将如何？

伊隆马斯克将“支付”作为其战略的关键部分作为空白页。Simon Taylor对这个“假设”进行详细推理，这是一个很好的案例研究，详细阐述了基础设施、货币化和用户体验。

如果 Twitter 依靠产品最初的简单性和类似协议的体验，它可能会成为全球支付的主宰者。 

我对Twitter作为一个支付 "品牌 "感到兴奋，因为。

• Twitter @handles看起来就像金钱的电子邮件地址。在2009年，Twitter是一个非常不同的产品，因为它起源于一个基于短信的协议。例如，要给另一个用户直接发信息，你会写一条普通的推文，如 "DM @user hey this is a direct message"。
• 推特是第一个开发者，而其他社交网络则不是。在2009年，一个由第三方应用程序组成的生态系统围绕着Twitter和它的API。其他社交网络将试图 "拥有 "支付，并承担深层次的监管和基础设施负担；而Twitter可以抽象出这一点。
• 我认为Square作为一个 "专属供应商 "的模式是可以成功的。支付基础设施很困难，我认为Square会更像Stripe。它的API使所有这些都变得简单，它的第一个客户是Twitter。Square最终建立了一个业务，通过将复杂性抽象为简单的体验，极大地简化了商家的支付。

快进到 2022 年，支付格局发生了巨大变化，但看起来却非常相似。 

我们需要一个人类可读的通用货币地址系统。

每个单独的支付类型和品牌都试图成为消费者的重心。但是消费者有许多来自许多供应商的付款类型，这些供应商因地理位置而异。 
从消费者的角度来看，金钱或支付没有重心，这让生活变得混乱和复杂。

下面是已经出现了创建标准试图将所有这些结合在一起的各种尝试：

• 银行账户世界中的 IBAN （国际银行帐号）。IBAN 就像是真实法定货币实际所在位置的 IP 地址。但是消费者有多个钱包，有多个不是银行的提供商。IBAN 对 web3 和那个未来根本没有帮助。
• 像 Apple Pay 这样的 Xpays 已经建立了钱包来保存卡、账户和身份。但苹果的商业模式坚持征收苹果税，而且他们的产品非常以美国为中心。Apple 也没有完全接受 web3。 
• ENS 和 Unstoppable Domains 等Web3 地址服务 试图成为价值转移的人类可读地址。但它们对整个金融服务领域的采用或向后兼容性有限（到目前为止）。
• Plaid、MX 和 Truelayer 等开放式金融服务 在帐户钱包和 web3 之间路由，但 不是人类可读的。他们自然也更倾向于 B2B 而不是 B2C，如果没有渠道冲突就很难解决这个问题。

这些解决方案中的每一个都从基础设施或他们拥有的比特开始，并试图将所有其他支付类型纳入其中。 

Twitter @handle 方法可以通过有意地更加抽象来创造不同的消费者体验。如果每个支付轨道都有自己的网关和域，@handle 将成为指向这些的指针。

消费者体验
Twitter 用户可以使用几种简单的机制将现有帐户链接到他们的@handle：
通过开放式银行连接账户，授权卡详细信息或 X-Pays，对于 web3，使用类似 Wallet Connect 的东西。
毫无疑问，Elon 会希望支持闪电网络和 Jack Dosey 在比特币网络上所做的工作。

• 用户设置默认接收付款的偏好。Twitter 上的持有“钱包”直接进入基础帐户或服务。这对品牌也同样有效。
• 付款：付款需要对方在结账时接受@handles。然后@handle 需要指向商家接受的支付方式（例如，借记卡）。从那里开始，标准支付流程适用。尽管可以显着改善体验。
  例如：Privacy.com 创建了一个链接到基础帐户的一次性消费者虚拟卡，Shop Pay 预先填写了包含交付详细信息的整个结帐表格（体验是如此之快，就像在电动汽车中加速一样，一开始就令人生畏！ )

@handle 作为支付的通用指针
作为一个原则，你越深入支付堆栈，事情就会变得越复杂，但单位经济效益就越好。 
为了抽象化并快速进入市场，Twitter 应该避免深入任何给定市场的基础设施，并提供一种违反直觉的解决方案。
与其构建 Twitter 与支付类型的集成，不如让 Twitter @handle API 成为一个简单的标准，并让钱包支持它。
实际实施需要更多思考，但有两件事让我印象深刻，值得探索

1. 开发人员的简单性
2. 以解决互操作性的项目为基础

在 web3 中，存在无数次构建“Layer 0”互操作层的尝试，但很少有人考虑向后兼容法币银行系统。其中大部分是关于边缘案例，如反洗钱、欺诈以及支付方案和网络的个别规则

Twitter 的角色都可以抽象为：支持根据已知支付地址、帐号或卡号解析@handle 的请求。

让我们假设 Twitter @handles 成为金钱的通用指针：
在这种情况下，会出现几种收入模式。

1. 每次 API 调用收费： 一个实体想要从 Twitter 提取凭证，Twitter 传递一个代表该支付方式相关信息的令牌。易于实施并将 Twitter 置于 SaaS 领域。 
2. 基点定价： 取交易金额的百分比（例如，Interchange）。这可能会变得复杂，因为每个支付轨道都有其商家通常支付的费用模型。它也变得更难计算；Twitter 需要知道涉及的交易金额，而不是一个不干涉的凭证提供者。

也许更有趣的是由于成为支付凭证中心而出现的广告和数据机会。

互联网经济的很大一部分是基于广告，谷歌、亚马逊、Meta，在某种程度上，Twitter 依靠广告来推动他们的业务。
广告的圣杯是通过“漏斗”将潜在客户从认知到考虑再到购买。品牌花费数十亿美元来争夺注意力以吸引购买。

卡网络和支付数据承载着转移资金所需的数据，但它放弃了广告和忠诚度世界所需的一切。 

如果@handles 成为所有支付类型的通用指针，Twitter 能否在广告和忠诚度循环方面做一些有意义的事情？
可能是

创建飞轮
如果Twitter可以执行一个轻量级的支付抽象，让开发者可以建立多轨制，他们将有一个巨大的机会。而如果你在这周围撒上广告圈，那就很可爱了。

这种方法的挑战：
1.社交和支付在西方似乎从来都不顺利。 

2.支付基础设施难。 访问支付渠道比 Google Maps API 等更复杂。支付系统都以不同的方式工作，这些方式因地理位置而异，并有自己的规则。 

例如，卡行业有一个称为 PCI/DSS（支付卡行业数据安全标准）的合规标准。如果有人存储 与卡相关的任何东西 ，它必须遵守。许多提供商对此进行了抽象（如 Skyflow、Basis Theory 和 VGS），但如果你想支持 所有支付类型，那只是十亿拼图中的一小块。
Twitter 转移资金的能力越小，它就越有可能制造飞轮。 

3. 支付边缘案例很糟糕。 付款可能会出现很多问题，具体取决于付款的目的。如果你在网上买东西，货物送到了吗？如果货物出现但有问题怎么办？每个支付轨道及其参与者都在不同程度上解决了这个问题。