# 如何在自定义 POS 应用中接收刷卡支付

> Published: 2026-10-27
> Updated: 2026-10-27
> Author: Mathias Nielsen
> Category: Pay
> Canonical: https://finalpos.com/zh-Hans/blog/accept-card-payments-custom-pos-app-zh-Hans

刷卡表单并不等于刷卡终端。以下是在自定义或 AI 构建的 POS 应用中接收刷卡支付的 4 种真实途径、Apple、Google 及你的支付提供商对每种途径的要求，以及所需的时间。

要在自定义 POS 应用中接收刷卡支付，你需要通过支付服务提供商（PSP）并选择以下 4 种途径之一：认证读卡器、iPhone 上的 Tap to Pay、Android 上的 Tap to Pay，或者云端连接的智能终端。你的应用绝不会读取卡号。它只是将金额发送到经过认证的硬件或软件，并接收“批准”或“拒绝”的结果。每种途径都有来自 Apple、Google 或你所选提供商的特定要求，而真正耗费时间的是这些审批手续，而不是编写代码。

本指南将逐步梳理每种途径，提供无任何夸大的真实需求。我们为自己的 POS（Final）处理支付业务，因此我们亲自跑通了这里的每一步。

![在自定义 POS 应用中接收刷卡支付：在咖啡馆柜台前，顾客将感应式银行卡轻触商户的手机](https://storage.googleapis.com/final-os-media/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/aa1be6a479fcf8f3-accept-card-payments-custom-pos-app-hero.png)

## 为什么不能直接在 POS 中添加刷卡表单？

因为输入卡号表单会将交易归类为“无卡交易”，而门店柜台需要的是“有卡交易”。当顾客在网页表单中输入卡号时，该笔支付会被当作线上订单处理：手续费更高、面临更多的欺诈风险，且争议风险大部分归于商户。而当认证设备读取卡片或手机时，交易属于“有卡交易”，这对每个人来说都更便宜、更安全。

接收“有卡交易”需要经过认证的硬件或软件。这就是为什么下面介绍的每种途径都必须调用 PSP 的线下产品，而非仅仅依靠你自己的代码。手续费差异在 [有卡交易与无卡交易的对比](/en-US/blog/card-present-vs-card-not-present) 中有所解释。

## 途径 1：如何在自己的应用中使用读卡器？

选择一家提供线下 SDK 的 PSP，购买其认证的读卡器，并在你的应用中进行配对。Stripe Terminal、Adyen 等均采用这种方式。

1. 在 PSP 开立账号并开通其线下支付产品。
2. 集成其 iOS、Android 或 React Native SDK。
3. 订购认证读卡器并将其注册到你的账号下。
4. 在应用中搜索并连接读卡器，然后通过 SDK 发起收款。
5. 做好读卡器固件更新的准备（固件由 PSP 负责推送）。

你无法连接任意读卡器：只有经过你所选提供商认证的读卡器才能处理刷卡，因为认证覆盖了具体的读卡器、软件及支付处理商的组合。详见 [自定义 POS 应用的读卡器](/en-US/blog/card-reader-sdk-custom-pos) 和 [POS 的 EMV 认证](/en-US/blog/emv-certification-pos)。

## 途径 2：Tap to Pay on iPhone 需要什么条件？

Tap to Pay on iPhone 将手机直接变成读卡器。Apple 自己的步骤是：与支持的 PSP 合作、申请 Tap to Pay on iPhone 权限、集成 ProximityReader API 或 PSP 的 SDK、遵循 Apple 的人机界面指南、并提交应用进行审核（[Apple 的 Tap to Pay 概览](https://developer.apple.com/tap-to-pay/)）。Apple 明确指出，PSP 负责提供允许商户接收支付所需的认证。

在实际操作中，这意味着：

1. **组织开发者账号。** 权限申请必须由组织账号的账户持有人发起，而注册组织账号需要邓氏编码（D-U-N-S）。参阅 [邓氏编码与 Apple 开发者账号](/en-US/blog/duns-number-apple-developer)。
2. **申请表单。** 填写你使用的 PSP 名称以及你将要运营的地区。
3. **开发权限。** Apple 会先授予用于在自有设备上开发和测试的权限。
4. **Apple 的 UX 要求。** Apple 会在发放权限时一并附上其需求和营销指南，涵盖按钮标签、入口位置和引导流程。
5. **分发权限。** 你需回复 Apple 的邮件并重新申请分发权限。TestFlight 和 App Store 都需要此权限。
6. **App Review。** 应用通过审核后即可发布。

该功能支持 iPhone XS 或更新机型，不支持 iPad。完整操作指南见 [如何获取 Tap to Pay on iPhone 权限](/en-US/blog/tap-to-pay-iphone-entitlement)，审核技巧见 [含有 Tap to Pay 的应用如何通过 App Review](/en-US/blog/tap-to-pay-app-review)，替代方案见 [为什么 Tap to Pay 无法在 iPad 上运行](/en-US/blog/tap-to-pay-on-ipad)。

## 途径 3：Android 上的 Tap to Pay 有何不同？

Android 上没有 Apple 式的权限申请，但 PSP 的 SDK 会进行自身的安全检查。典型要求如下：

- 运行 Android 11 或更高版本且内置 NFC 的 Android 设备
- 通过完整性验证的 Google 认证设备
- 非调试构建：PSP SDK 拒绝在调试模式下处理真实碰卡，因此你需要使用模拟读卡器进行测试
- 位置权限以及 SDK 要求的其他权限

如果 Android 平板电脑符合提供商的要求，也是可以支持的。详见 [自定义应用中的 Tap to Pay on Android](/en-US/blog/tap-to-pay-android-sdk)。

## 途径 4：基于浏览器的 POS 能否接收刷卡？

可以，通过云端连接的智能终端来实现。你的服务器调用 PSP 的 API，将支付指令发送到柜台上的特定终端；终端处理刷卡并将结果汇报给你的服务器。这是 Web POS 唯一能使用的线下收款途径，因为网页本身无法读取碰卡支付，而 Safari 也无法连接蓝牙读卡器。

该途径适合配备固定终端的柜台服务型门店。由于增加了对网络的依赖，因此需提前规划门店断网时的应对方案。

## 如何为自定义 POS 选择支付提供商？

首先考虑你开展业务的国家/地区，其次是入驻审核与硬件支持：

| 考虑问题 | 为何重要 |
| --- | --- |
| 该提供商是否在你所在的国家/地区开通服务？ | Tap to Pay 和读卡器是按国家/地区逐步推出的 |
| 入驻是否为自助式？ | Stripe 支持自助入驻；Adyen 则专注于大型企业，且申请审核更为严格 |
| 它提供哪些 SDK？ | 各提供商在 iOS、Android、React Native 和服务器驱动终端方面的支持有所不同 |
| 哪些读卡器获得了认证？ | 只有经过认证的读卡器才能工作 |
| 是否支持离线支付？ | 离线脱机交易取决于特定提供商，且会将拒付风险转嫁给你 |
| 你是否会招募其他商户入驻？ | 如果会，你将扮演平台的角色，可能需要进行支付服务商（Payfac）模式安排 |

我们的详细对比请参阅 [自定义 POS 应用选用 Stripe Terminal 还是 Adyen](/en-US/blog/stripe-terminal-vs-adyen)。如果你计划代其他商家收款，请先阅读 [成为支付服务商（Payfac）还是使用既有平台](/en-US/blog/payment-facilitator-vs-platform)；若仅经营单一门店，你只需充当普通商户。

## 你继承了哪些合规要求，又需要保留哪些？

使用 PSP 的认证 SDK 或读卡器意味着持卡数据永远不会接触你的代码，从而使你的 PCI 合规评估范围保持在很小的程度。PSP 承担了支付认证工作。而你仍需负责：

- 填写向你的支付处理商提交的 PCI 自评问卷
- 运行 POS 的设备上的访问控制、日志记录和系统更新
- 正确生成小票、办理退款和原路扣减税费
- 遵守 Apple 及 PSP 针对 Tap to Pay 的展示与营销规则

如果你也在构建 POS 的其他部分，我们关于[如何利用 AI 构建你自己的 POS 系统](/en-US/blog/build-your-own-pos-system-with-ai)的专题文章涵盖了 PCI、税务和部署等内容，而 [自定义应用的 POS 硬件](/en-US/blog/pos-hardware-for-custom-apps) 则涵盖了打印机和钱箱。

## 接收第一笔刷卡支付需要多久？

| 步骤 | 典型耗时 |
| --- | --- |
| 包含邓氏编码的 Apple 组织账号（用于 Tap to Pay on iPhone） | 数天至数周 |
| 开通 PSP 账号并启用线下产品 | 当天至数周（取决于提供商） |
| SDK 集成与测试支付 | 1 到 3 周 |
| Tap to Pay 开发权限，以及随后的分发权限 | 数周 |
| App Review 审核 | 数天（若被拒绝则更久） |

## 能否在第一天就接收刷卡支付？

可以，只需将你的结账流程构建在已经具备相应审批资质的平台上即可。这就是 Final。你的 AI 在 Flow Studio 中构建结账流程，而当发起刷卡支付请求时，Final Pay 会处理读卡器或 Tap to Pay：

- **读卡器与 Tap to Pay 已获资质审批。** Final Pay 支持在受支持的设备上接收插卡、感应刷卡及 Tap to Pay。请参阅 [如何接收 Tap to Pay 支付](/help/take-a-tap-to-pay-payment) 和 [如何在结账时收款](/help/take-a-payment)。
- **由你自己的 AI 进行构建。** 通过 [Final 的 MCP 服务器](/help/connect-your-own-ai-mcp) 连接 Claude、Cursor 或任何 MCP 客户端。
- **一目了然的定价。** 无订阅费。现金交易 0 美元。刷卡交易在美国及全球其他地区为 2.49% + $0.10，加拿大为 1.99%，欧洲为 0.99%。

坦诚地说，折中之处在于：你必须通过 Final Pay 进行支付处理，而无法自由选择 PSP，且可用性因国家/地区和设备而异，详见 [Final Pay 可用地区](/help/where-final-pay-is-available)。如果支付本身就是你的产品，请使用上述途径自行开发集成。如果支付只是你收款的途径，那么所有的审批手续已经为你准备就绪。

## FAQ

**Q: 我该如何在自己的 POS 应用中接收刷卡支付？**
A: 通过支付服务提供商的线下 SDK：经过认证的读卡器、连接云端的智能终端，或手机上的 Tap to Pay。您的应用绝不会处理原始卡片数据；它只需发送金额并接收处理结果。

**Q: 基于 Web 的 POS 能否在线下接收刷卡支付？**
A: 可以，通过支付提供商的 API 驱动云端连接的智能终端来实现。网页本身无法独立读取碰卡支付。

**Q: Tap to Pay on iPhone 需要什么条件？**
A: 需具备：支持的支付提供商、由组织 Apple 开发者账号账户持有人申请的 Tap to Pay 权限、开发权限，以及经 Apple UX 审核通过后的分发权限，最后通过 App Review。该功能支持 iPhone XS 或更新机型。

**Q: Tap to Pay 支持 iPad 吗？**
A: 不能。Tap to Pay on iPhone 仅限 iPhone。iPad POS 应用需使用经认证的蓝牙读卡器或智能终端接收刷卡。

**Q: 自定义 POS 应该使用哪家支付服务商？**
A: Stripe Terminal 支持自助开通，小团队可以快速上手。Adyen 更适合大型企业，且在入驻审核上更为严格。具体选择取决于您所在的国家/地区、硬件需求和交易量。

**Q: Final 对刷卡支付如何收费？**
A: 无需订阅费。现金支付费用为 0 美元，刷卡支付在美国及全球其他地区为 2.49% + 0.10 美元，在加拿大为 1.99%，在欧洲为 0.99%。