01所有支付方式，一页呈现
托管收银台将银行卡、Apple Pay、Google Pay 和 USDC 并列展示。左侧是订单 9F21-0716——三个明细项、€0.50 手续费、应付 €49.00——右侧是支付方式选择。客户选择，页面自适应，商户只需集成一次。
- 银行卡、USDC 和钱包按钮同屏呈现
- 完整订单——明细、费用、总额——与支付表单并排显示
- 无论哪种方式，都是同一个“支付 €49.00”按钮
02同一个 URL，适配手机
同一个收银台 URL 会自动重排为手机布局：订单折叠为摘要栏，支付方式按钮保持原位，银行卡表单保留各字段标签。桌面端有的，移动端也有——若你希望在自己的应用内而非浏览器里完成支付，iOS 和 Android SDK 会基于同一订单，以原生方式呈现同一个收银台。
03自带说明的收据
用 USDC 支付，得到的是会计看得懂的收据。方式：Base 网络上的 52.95 USDC →︎ 以 EUR 结算，汇率以收据上所印为准，1 EUR = 1.0807 USDC。参考号 9F21-0716，发送至客户邮箱，也可当场下载。客户付的是加密货币，账上记的是 €49.00。
04不止是链接，更是链接后台
支付链接有了真正的工作台：Arc Studio SRL 共 8 个链接，涵盖已支付、有效和已过期，每行都有金额、支付笔数和状态。上方卡片实时计分——4 个有效链接，本月通过 18 笔链接支付收款 €2,304.50，今日已收 €49.00。创建、搜索、导出，一气呵成。
- 每个链接都显示 URL、金额和状态
- 顶部显示本月收款和今日已收
- 在跟踪链接的同一视图中创建链接
05针对订单退款
退款针对的是订单，而不是某种支付方式。抽屉面板打开 9F21-0716，金额默认为全额 €49.00，原因必填，另可添加备注，备注会出现在导出文件和客户收据中。资金自动按原支付通道退回——银行卡退回原卡，USDC 订单按其 EUR 结算金额退回——通常 1–3 个工作日到账。
- 全额或部分退款——不超过原交易金额即可
- 原因必填，备注会带到收据上
- 无论哪种通道，都自动原路退回
06你的收银台，一眼就是你的
品牌定制只是一个设置页面，而不是一个服务项目：上传 Logo，设置强调色、文字色和背景色，选择字体和圆角样式。保存前，实时预览会渲染你真实的收银台——桌面端或移动端皆可；强调色会应用于支付按钮焦点、状态标记和当前标签页。可使用沙盒分配的收银台域名，也可使用你自己的域名。
07支付方式，开关即用，无需开发
支付方式就是背后接着服务商的开关：支持 3-D Secure 的银行卡、以钱包按钮呈现的 Apple Pay 和 Google Pay、跨 Ethereum、Base 和 Solana 的 USDC，以及通过 vIBAN 参考号的 SEPA 银行转账。旁边的结算面板把规则说得很清楚：客户在确认前就能看到换算结果；你始终以 EUR 结算。
- 每种方式一个开关，所属服务商标注在同一行
- USDC 结算：自动兑换，每日 23:00 付款
- 银行卡路由，3-D Secure 策略清晰可见
08即插即用的集成
创建订单，跳转到托管页面，接收结果。支付界面、支付方式逻辑和收据都由 Gateway 承担。你的团队不必开发、修补收银台前端，也不必在支付方式变化时持续跟进维护。
09以订单为单位
一切都挂在订单上，而不是支付方式上。订单 9F21-0716 包含各个明细项——€38.50 的品牌识别冲刺、€6.00 的字体授权、€4.00 的加急交付——外加 €0.50 手续费和一个总额。无论用哪种方式支付，你都以这个参考号来查询、对账和退款。
10配置变更，不会打扰进行中的会话
支付方式和品牌的变更仅对新的收银台会话生效——保存的页面上会明确说明。正在付款的客户，不会遇到页面在手下突然变化。
11银行卡，做到位
银行卡流程是最枯燥的部分，我们都处理好了：内联校验，3-D Secure 与强客户认证内置于流程之中，路由策略清晰可读，每个沙盒都有专属测试卡供集成联调。接受加密货币，绝不会让银行卡流程变差。
12Apple Pay 和 Google Pay
钱包就是按钮，而不是一个项目。Apple Pay 和 Google Pay 在同一页面上以一键支付面板呈现，使用设备令牌支付——真实卡号绝不会到达页面——并沿用同一订单和同一收据。启用只需在支付方式界面打开一个开关。
13USDC 结算为 EUR
加密货币按收银台上显示的汇率计价，并结算为欧元。商户不会意外持有代币头寸；账目始终保持单一币种。
14覆盖三条网络的 USDC
USDC 支付方式由一个开关统一控制，覆盖 Ethereum、Base 和 Solana。客户在其钱包所在的网络上付款；商户这边无需任何改动。
15通过 vIBAN 银行转账
转账支付带有 vIBAN 参考号，因此收到的 SEPA 款项天然就能对应到订单。为希望通过银行支付发票的客户开启此方式，对账依然自动完成。
16该有的本地支付方式，一应俱全
除银行卡和钱包外，收银台还提供欧洲买家期望看到的账户到账户支付和本地支付方式，并按客户所在国家呈现，而不是堆成一长串列表。
17先买后付
BNPL 与其他支付方式并列在同一行——客户分期付款，商户一次收款，订单参考号保持不变。一个开关，同一张收据，同一套对账。
18懂客户的支付方式排序
页面按客户可能使用的方式排序——国家、语言、设备，以及是否曾向你付过款——让相关选项排第一，而不是第四。
19以客户的币种报价，以你的币种结算
以客户的币种显示金额，并在确认前说明换算方式，同时始终以 EUR 结算。客户看到的是熟悉的数字；你的账本只有一种币种。
20客户母语的收银台
托管页面会本地化标签、错误提示和收据。没有人会因为按钮语言不对而放弃付款。
21已保存银行卡与一键支付
回头客只需轻点一下，即可使用已存的银行卡付款。卡片存放在我们这一侧的保险库中，并以令牌引用，因此你的系统只保存引用，绝不保存 PAN——第二次购买比第一次更快。
22订阅与定期扣款
定期扣款按你定义的计划执行——金额、周期、起止时间——并基于令牌化的银行卡。每个周期都会生成独立的订单和收据，因此订阅也能像其他交易一样逐笔对账。
23重试，挽回收入
定期扣款遇到软拒绝时，会按计划重试，而不是直接核销，只有在必要时才通知客户。续费失败不再是悄无声息的流失。
24网络令牌与卡片更新
已存储的银行卡以网络令牌形式保存，持卡人换卡或卡片过期后依然有效。过去一换卡就中断的订阅，现在会继续扣款。
25API 与开发者专区
订单通过 API 创建并带幂等键——重试的请求返回原结果，绝不会重复扣款——开发者专区提供密钥和文档。收银台是托管的；集成只需少量端点，文档就放在设置所在之处。
26订单生命周期 Webhook
你的后端在支付发生的第一时间获知：订单生命周期的签名 Webhook 事件——已支付、失败、已退款——你这边验证签名，我们这边提供重放保护。
27iOS 与 Android 移动端 SDK
原生应用在应用内呈现同一个收银台，而不是把用户踢到浏览器。SDK 内置支付方式逻辑、钱包面板和 3-D Secure；订单和收据，就是你的后端已经掌握的那一份。
28适配你现有平台的插件
购物车插件无需开发人员，即可将现有店铺接入 Gateway——安装、粘贴密钥、测试支付一笔。这些订单与 API 订单一样，进入同一个后台。
29嵌入你自己页面的支付字段
当支付必须在你自己的页面布局内完成时，可直接嵌入支付字段：输入框由我们托管并承担 PCI 范围，周围的页面完全由你掌控，银行卡数据绝不会经过你的服务器。
30一次性、多次使用与有效期
支付链接可以在一笔付款后关闭，也可以持续收款——演示中的工作坊席位已收到 3 笔付款，咨询时段已收到 6 笔。链接默认 30 天后自动失效，失效的链接会明确提示，而不是悄悄失败。
31测试模式
集成联调使用测试会话，搭配与沙盒密钥一同发放的测试卡，在任何真实资金流动之前完成。测试与正式的流程完全一致，测试通过的，就是上线交付的。
32看得懂的路由
银行卡交易遵循一套用您熟悉的维度编写的路由策略——卡品牌、发卡国家、币种、金额——而不是黑盒。在显示支付详情的同一界面，就能看到这笔支付走了哪条路由。
33流失订单前，再试一次
遇到软拒付时，系统会在同一个收银台会话内切换备用路由重试，客户不会看到失败提示。大多数被挽回的支付，客户根本不知道它曾有风险。
34用大白话解释拒付
原始的发卡行代码会被转换为运营人员能够直接处理的原因——卡片过期、余额不足、发卡行风控——并自动归类，让多笔支付中的规律一目了然。
353-D Secure 是策略，不是阻碍
大多数支付仅凭设备与行为信号即可通过；策略要求时才会触发升级验证。策略由您设定——始终验证、基于风险，或在规则允许时豁免——整个流程由托管页面承载。
36一行记录，轻松对账
收银台、收据和结算使用同一个订单编号。查询 9F21-0716 的人只会找到一条 €49.00 的记录——而不是银行卡记录在一个系统、加密货币记录在另一个系统。
37结算与付款
结算规则在配置处一目了然：自动兑换为 EUR，结算至 RO49 •••• 0421，每日 23:00 付款。会计明天看到的数字，商户今天就能在界面上读懂。
38可追溯的付款
每笔付款都可展开查看其对应的订单，手续费逐项列明。银行流水与可导出的清单一一对应，月末对账只需查询，无需调查。
39部分退款
退款金额可在原始扣款金额内自由编辑——面板会显示上限，低于上限的一律视为部分退款。同一订单的十次部分退款，仍可对应同一个编号对账。
40退款原因，有据可查
每笔退款都需填写原因，并可附加备注，备注会随之流转：出现在导出文件和客户收据中。半年后，没有人需要再回忆为什么订单 9F21-0716 得到了全额补偿。
41收据发送
收据会通过电子邮件发送给客户，也可当场下载，退款收据同样如此。商户无需自己制作收据模板。
42结算前撤销
在当日批次提交前取消，会释放授权冻结，资金不会发生任何流动——无需退款，无手续费，客户账单上也没有需要解释的记录。
43风控默认开启
银行卡支付在您看得懂的路由策略下执行 3-D Secure。钱包支付使用设备自带的身份验证，Webhook 事件在被信任之前会先进行签名验证。
44用您自己的语言写规则
筛查规则读起来就像一句话——首次使用的银行卡在 Y 国发起超过 X 的金额——并据此执行：放行、验证或拦截。可信与受限的银行卡、邮箱和地址名单也在同一界面中管理。
45频次与设备信号
同一张卡、同一台设备或同一地址的反复尝试，由频率规则拦截，而不是等人事后发现。信号直接显示在支付详情上，而不是埋在一个评分里。
46附带证据的争议处理
拒付发生时，背后的订单会一并呈现：授权结果、3-D Secure 结果、收据、发货、退款历史。直接在该界面应诉，证据包由系统记录生成，而非凭记忆拼凑。
47卡数据永远不会到您手上
收集卡信息的页面由我们托管，并符合 PCI 范围要求。无论客户在我们的域名、您的域名还是您的应用内付款，您的服务器看到的只有令牌和订单编号——绝不会出现卡号。
48静态加密，数据留在欧盟
支付数据静态加密，并在欧盟境内处理。对欧洲商户而言，数据存放在哪里是一个明确的答案，而不是脚注。
49每个操作都有记录
退款、支付方式变更、品牌设置变更、密钥轮换——每一项都会写入审计日志，记录操作人、时间戳和原因。特权操作需先填写原因才能执行。
50按需分配角色
财务查看付款，客服查看订单并办理退款，开发人员查看密钥和日志。权限按角色授予，而不是共用一个账号。
51客户目录
付款人会沉淀为客户视图——谁付了款、付款频率、使用何种方式——回头客因此是一条记录，而不是在导出文件里碰巧匹配上的相同邮箱。
52搜索与 CSV 导出
在搜索框中通过链接或编号查找支付；账务需要时，可将当前视图导出为 CSV。后台的设计前提，就是会计一定会来问。
53按日、按方式查看数据
交易量、通过率、退款和支付方式占比，时间范围由您选择。足以回答钱去了哪里、哪种支付方式值得推广——无需导出任何文件。
54背后的运营视图
Gateway 与 Protocore Center 无缝对接：其中的支付链接后台会列出每个链接及其关联的结算转账，并提供打开 Tracer 的链接以查看完整链路。您的运营团队可以从收银台一路看穿到账本。
55白标或 powered-by
演示收银台属于 Arc Studio SRL：他们的名称、他们的标识、他们的订单。可以保留 powered-by-Protocore 页脚运行，也可以完全白标——无论哪种，页面看起来都是您自己的。
