选择付款解决方案或组合最适合您的企业的付款解决方案。
<<checkout>>
<<checkout>> 模式让您可以通过 QNB ALAHLI 托管和显示的交互来从付款人处收集付款详细信息。使用此集成模式，您永远不会直接看到或处理付款详细信息，因为这些信息由托管付款界面收集，并从付款人浏览器直接提交至 QNB ALAHLI。
<<checkout>> 可以通过以下任一方式实施：
- 嵌入页面 - 您现有的商家网站内的一个嵌入组件。
- <<hostedPaymentPage>> - 由 QNB ALAHLI 托管和显示的网页。
- <<checkout>> 集成起来简单快速。
- 您无需处理或存储任何付款详细信息，因而降低了 PCI 合规成本。
- 您可以使用 your payment service provider 提供的主题来显示 <<checkout>> 界面。这样，您可以利用 your payment service provider 的品牌。强势品牌可以让付款人提供的付款详细信息更加有说服力。
- 您可以自定义显示企业信息的 <<checkout>> 界面的内容。
- 如果您已订阅了通知，如果付款成功，您还可以选择接收通知。
- <<checkout>> 符合 WCAG（Web 内容可访问性指南）2.0 级别 AA 合规要求。
下方说明了 <<checkout>> 模式的付款流。
- 付款人在您的购物网站发起商品和服务的付款流程。作为响应，您的应用程序向 QNB ALAHLI 提交包含所需数据的 JavaScript 请求以显示所选付款界面：嵌入页面或 <<hostedPaymentPage>>。
- 向付款人呈现付款界面。显示内容（如企业信息和订单详细信息）以及付款界面的其他内容由请求中的数据控制。
付款人输入所需信息并单击“支付”。
QNB ALAHLI 收集并验证付款详细信息，然后处理付款。
- 如果付款成功，付款人可以从以下来源中的一个获取付款详细信息：
- QNB ALAHLI 托管收据（在嵌入页面中或托管页上）。这是默认行为。
- 您的购物网站。
- 电子邮件通知。您必须订阅付款人通知才能收到此通知。
如果付款未成功，<<checkout>> 将显示结果，允许付款人使用其他付款详细信息重试交易。
Hosted Session
如果您要控制付款页的布局和样式，且同时降低 PCI 合规性成本，请选择 Hosted Session 模式。Hosted Session JavaScript 客户端库让您可以在付款单字段（源自 QNB ALAHLI 并由其控制）中从付款人处收集敏感付款详细信息。网关在付款会话中收集付款详细信息并暂时存储这些信息供以后使用。然后，您可以在交易请求中包括付款会话（代替付款详细信息）来处理付款。
- Hosted Session 集成起来简单快速。
- 您无需收集、存储或处理任何敏感付款详细信息，因而降低了 PCI 合规成本。
- 您保持对付款页的样式和布局的控制。
- 您可以根据企业需求自定义付款人体验。
下方说明了 Hosted Session 模式的付款流。
- 付款人在您的购物网站发起商品和服务的付款流程。
- 付款人可以选择使用信用卡/借记卡、数字钱包、礼品卡来提供付款详细信息，或进行 <<ach>> 付款。
- 您的付款页：付款详细信息在 QNB ALAHLI 托管的内嵌框架中嵌入的表单字段中收集。
- 数字钱包：卡详细信息从钱包交互中收集并发送到 QNB ALAHLI。
- QNB ALAHLI 在付款会话中收集付款详细信息，您可以在任何参考会话的操作中使用这些信息。
<<directPayment>>
如果您需要完全控制交易，希望管理您自己的付款页或收集付款详细信息，您必须使用 <<directPayment>> 模式。付款详细信息被直接发送到 QNB ALAHLI 来处理交易。此商家管理模式需要您在应用程序中管理与收集付款人付款详细信息相关的安全性，因而提高 PCI 合规成本。
- 对整个付款体验提供全面控制。您拥有自定义付款解决方案的灵活性。
- 与所有应用程序、网站、呼叫中心、账单、交互式语音响应 (IVR) 集成
- 允许您直接与 QNB ALAHLI 通信，然后接收 API 呼叫的实时响应。这是一个同步连接，付款人不会离开您的应用程序，这意味着会话不会与付款人分离。
- 支持付款人不直接参与的高级 QNB ALAHLI 操作，如过账、退款、取消和查询。
下方说明了 <<directPayment>> 模式的信息流：
- 付款人决定进行购买，并直接向您的应用程序或网站提供他们的卡详细信息。您可以选择将收集的卡详细信息与之前存储的令牌中存储的详细信息结合。请参见多个卡详细信息来源。
- 您的应用程序或网站建立交易请求，并通过 <<webServicesIntegration>> 经由互联网使用 HTTPS POST 或 PUT 将其发送到 QNB ALAHLI。
根据您的企业需求，您可以将其他字段传入此交易请求。请参见其他功能。
在执行付款交易前，您可以为动态货币兑换 (DCC) 提交费率报价请求来检索付款人货币以及使用该货币的订单金额。
在此阶段，您还可以使用EMV 3DS 支付验证对付款人进行身份验证.请注意，如果付款人接受 DCC 出价，那么您必须在身份验证请求中提供 DCC 信息。 - QNB ALAHLI 将交易传送到收单行进行处理。
- 在您的 API 调用响应中，收单行返回响应，QNB ALAHLI 生成交易响应并将其传送到您的应用程序或网站。交易响应指示交易是否成功，并包括其他响应数据。
- 您的应用程序或网站根据交易结果显示收据或其他确认页或错误页。
<<batchIntegration>>
<<batchIntegration>> 允许您将批量操作（Capture、Refund 等）安全可靠的提交到 QNB ALAHLI 以供处理，无需进行直接的付款人交互。例如，您可以使用在线购物车触发授权，然后使用 <<batchIntegration>> 执行过账。
提交后，您可以定期请求批处理状态以确定批处理的当前状态，包括已上载、已处理和已递延操作的总数以及处理操作的时间和日期戳。相同批处理状态还通过 Merchant Manager 中的 <<batchIntegration>> 状态搜索屏幕对 your payment service provider 可见。
批处理完成后，您可以请求一个包含每个已上载操作的结果的响应文件。
- 安全有效地处理多个操作—您可以通过提交批处理而不是逐个处理每个操作来安全处理多个操作。
- 去除了安装本地应用程序的需要—您不需要在您的系统中安装应用程序。这去除了部署、更新和维护应用程序的成本。
- 去除了 PA-DSS 合规义务—向第三方提供付款应用程序的提供商必须遵守支付应用程序数据安全标准 (PA-DSS) 的要求。去除了在您的系统中安装应用程序的需要，从而去除了履行 PA-DSS 合规义务的成本。
- 同时支持小型和大型商家—此功能同时支持小型商家（主要需要易于使用但无需集成的解决方案）和大型商家（希望有效处理大量交易）的需求。
- 使用 <<tokenization>> 可减少 PCI 合规成本—使用 <<tokenization>>，您可以实现 <<tokenization>> 和 <<batchIntegration>> 处理的组合优势。
下方说明了 <<batchIntegration>> 模式的信息流：
- 您的集成将付款人操作整合到一个批处理中，并通过 QNB ALAHLI<<batchIntegration>> 服务经由互联网使用 HTTPS PUT 将成批操作上载到 QNB ALAHLI。请参见创建批处理请求。
您可以选择将收集的卡详细信息与之前存储的令牌中存储的详细信息结合。请参见多个卡详细信息来源。您还可以根据您的企业需求，将其他字段传入批处理请求。请参见支持的功能。
- 在处理批处理前，您需要通过发送由批处理内容的 SHA-1 摘要组成的消息完整性代码 (MIC) 来验证批处理内容，以检测所有缺少的或损毁的记录。请参见发送批处理请求。
- 验证完成后，将处理批处理中的每个操作。
- 处理期间，您可以掌握批处理状态以确定处理的记录数和总体状态。请参见检索批处理状态。
- 当状态指示批处理完成后，您可以请求批处理响应。批处理响应包括在初始上载的批处理标头中指定的响应值。下载批处理响应。