--- title: 交易过程的基本概念 slug: Web/API/Payment_Request_API/Concepts tags: - API - Apple Pay - 中间状态 - 交易 - 付款方 - 付款方式 - 应用程序接口 - 指南 - 支付 - 支付请求API - 收款方 - 贸易 translation_of: Web/API/Payment_Request_API/Concepts original_slug: Web/API/支付_请求_接口/Concepts ---
{{securecontext_header}}{{DefaultAPISidebar("Payment Request API")}}{{draft}}
交易请求API使在网站或应用上进行的交易变得更便捷。在这篇文档中,我们将了解此接口如何运作,以及各个组件的功能。
在深入了解此API的工作方式前,你应该了解以下术语。
某些交易处理机会用到商家认证。商家认证是指以某种方式认证商家的身份,可能的方式包括密码学机制(例如公钥)。认证成功后的商家得以和交易处理机进行交互。
交易处理机是通过支付方式识别码识别的。交易方式识别码是一个指向唯一交易处理机的字符串,它可以是一套已成标准的识别码,也可以是一个URL。后者被交易处理服务同时用于两种用途:自证身份和处理交易。
目前注册在案的只有一套标准化交易方式识别码。(未来可能会添加更多。)
基本卡(basic-card, 输入一次银行卡信息后即可多次消费的支付方式)
这种识别方式的具体使用将会极大程度地依赖不同服务各自的规范。比如,某种服务可能使用多个URL链接,不同URL的使用依赖于API的版本和通信方式等。
https://apple.com/apple-pay
https://google.com/pay
{{Glossary("user agent")}}内部机制支持不同类型的交易。另外,你还可以调用交易处理API来支持更多相应的支付方式提供方(前提是你使用的浏览器支持这些API的使用)。不论使用哪种方式,交易处理机的功能都是如下几条:
一些交易处理机包含商家认证步骤。商家认证是指,通过某种方式识别商家的身份,使用的方式通常是“密码学挑战”。没有成功通过认证的商家不被允许使用交易处理机。
具体的认证方式由交易处理机决定,也完全可以省去这种认证。最终,网站或应用唯一要做的就是就是获取商家的认证密钥并传输给{{domxref("MerchantValidationEvent.complete", "complete()")}}事件的方法。
paymentRequest.onmerchantvalidation = function(event) { event.complete(fetchValidationData(event.validationURL)); }
在这个例子中,由fetchValidationData()
方法加载由validationURL
提供的认证信息。要注意到的是,这个方法必须由商家服务器转发,因为通常情况下,客户端不会主动访问用于认证的URL。
然后,该数据(或用来解析该数据的{{jsxref("Promise")}})被传送给交易处理机的complete()
方法。交易处理机可以用该数据获取更多信息或是进行更多重的算法解析,以认证商家对处理机的使用权。
因此,注意到如下事实很重要:{{Glossary("user agent")}}永远不会发送{{event("merchantvalidation")}}事件,除非用户代理自身装载了交易处理机。例如,Safari浏览器本身即支持Apple Pay,而Apple Pay的交易处理机可据此向客户端发送merchantvalidation
、指示客户端获取服务器上的认证信息,并将其传送给交易处理机的complete()
,来为商品进行支付。
规范 | 状态 | 注释 |
---|---|---|
{{SpecName('Payment')}} | {{Spec2('Payment')}} | 初始定义。 |
{{SpecName('Basic Card Payment')}} | {{Spec2('Basic Card Payment')}} | 定义了 {{domxref("BasicCardRequest")}} 和 {{domxref("BasicCardResponse")}}. |
{{SpecName('Payment Method Identifiers')}} | {{Spec2('Payment Method Identifiers')}} | 定义了支付方式识别码和认证方式,并在适用的情况下铸币或在W3C规范中进行登记。 |