本页假设你已阅读 Secure Elements 概览 —— 其中涵盖了加载 SDK 以及共享的 client-token 流程,这两者在此同样适用。
在线演示
该演示会自行生成令牌并自动挂载字段。输入任意能通过 Luhn 校验的卡号,填写持卡人姓名并提交。如果表单无响应,使用 Remint token & remount。 在新标签页打开 →
铸造一个 tokenization 令牌
调用POST /v1/client-token,并传入 "purpose": "tokenization":
virtualCardId。但它确实需要你访问令牌上的不同 scope —— 使用 MANAGE_PAYMENT,而不是 CREATE_VIRTUALCARD —— 并且它的有效期更长(默认 30 分钟),因为用户填写卡片表单通常比一次 reveal 点击花费更久。
渲染字段
renderFieldsForTokenization 没有 fields 选项 —— PAN、有效期和 CVV 始终作为一个组合的 frame 一起挂载,因为 CVV 校验与品牌相关(Amex 的 CVV 为 4 位,其他品牌为 3 位),只有当该字段能知道旁边 frame 中输入的卡号时才可行。你无法像 createCardViewer 的字段那样将它们独立挂载。
挂载
INVALID_STYLE、MOUNT_TIMEOUT 或 MOUNT_FAILED(frame 加载失败,或该实例已被挂载)时以 FluzElementsError 拒绝。frameHostOrigin 会在你调用 renderFieldsForTokenization 时同步校验,与 createCardViewer 相同 —— 未识别的来源会在到达 mount() 之前抛出 INVALID_FRAME_HOST_ORIGIN。
跟踪字段状态
brand 仅出现在 pan 的状态上,由已输入的数字推断:amex、visa、mastercard、discover、diners 或 jcb。使用 isValid 来控制你自己的提交按钮并驱动行内校验信息 —— 这些字段都不会向你的页面暴露底层值。
excludedCardBrands(例如 ["amex"])不会阻止输入 —— 一旦检测到匹配品牌,就会将 pan 的 isValid 置为 false,因此用户仍可输入该卡号,但在使用不同卡之前,submit() 不会成功。
提交
在你自己的页面上以普通输入的方式收集持卡人姓名和账单地址 —— SDK 不会把它们渲染在 Fluz 托管的 frame 内,因为它们不属于卡数据。你自行处理它们是否会影响你自身的 PCI DSS 范围,取决于你更广泛的持卡人数据环境;请与 QSA 确认。cardholderName 仅在第一个空格处分割为名/姓 —— "Mary Ann Smith" 会变为名 "Mary",姓 "Ann Smith";单词姓名将同时作为名和姓。若要复用账户上已有的地址而不收集新地址,传入 billingAddress: { userAddressId: "<uuid>" }。
submit() 几乎不会以拒绝方式失败,且绝不会因拒付而抛错。它只会在 MOUNT_FAILED(尚未挂载)或 SUBMIT_FAILED(“a submit() call is already in progress” —— 当已有一次提交在进行中时,忽略第二次调用)时同步抛出。其他所有结果 —— 成功、拒付、校验失败、超时 —— 都会正常 resolve,并通过下方的回调传达。处理结果
onSuccess 会在该卡被添加为资金来源后触发。onDeclined 则在处理方拒绝该卡时触发 —— 这仍是正常且可预期的结果,不是错误:
onError 用于所有不属于正常拒付的情况:
清理
完整示例
/mint-tokenization-token 是你自己的后端路由 —— 它会使用你的 Fluz OAuth 访问令牌调用 POST /v1/client-token,并传入 "purpose": "tokenization"。
下一步
Secure Elements 概览
令牌铸造、SDK 加载与 CSP。
Card Reveal
另一个 Secure Elements 能力 —— 向用户展示其自己的卡片详情。
在线演示
试用在预发布环境运行的加卡表单。
示例集成
可运行的纯 HTML 与 React 安全卡片输入示例,附带令牌铸造服务器。