# LLM Documentation

This file contains links to all documentation sections.

## Table of Contents

### 接入准备

- [准备工作](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/start/step/index.md): 准备工作文档介绍了使用PingPongCheckout前的必要步骤，包括获取沙箱账户、确定对接方案、API授权配置及生产环境验证。覆盖了从测试到正式上线的全流程，适用于希望集成支付解决方案的开发者。
- [沙箱准入说明](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/start/registerSandbox/index.md): 沙箱准入说明提供了进入PingPong支付系统测试环境的步骤。适用于开发人员在正式上线前进行功能测试和集成调试。流程包括通过指定网站注册账号，选择商户类型并提交信息，以及获取必要的测试参数如accId、clientId和salt。确保所有准备工作完成后，联系技术支持以配置环境。
- [沙箱约束限制说明](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/start/limitSandbox/index.md): 沙箱环境为开发者提供了一个安全低门槛的测试平台，支持大部分核心链路和对接逻辑。但请注意，沙箱非100%保真生产环境，存在功能限制，如部分支付方式无法完全测试或仅能模拟成功状态。此外，沙箱与生产环境数据隔离，切勿混淆使用。
- [验收测试场景](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/start/acceptance/index.md): 验收测试场景文档详细列出了收单验收的关键注意事项，包括沙箱环境特性、幂等性处理要求及信用卡3D验证测试方法。适用于准备上线前的最终测试阶段，确保支付流程安全可靠。

### 快速启动

- [沙箱环境使用说明](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/sandbox/index.md): 沙箱环境提供给开发者进行接口开发和调试，账号仅限于该环境中使用。访问地址为https://sandbox-acquirer-payment.pingpongx.com。提供了多种测试账号与支持的本地支付方式，包括WeChat Pay、AlipayCN等，并列出了可用于测试的卡号及其属性，如是否支持3
- [Klarna测试资源](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/Klarna/index.md): Klarna测试资源提供用于在线支付集成的测试账号和支付物料信息，支持美国、芬兰、德国及奥地利等地区的支付模拟。关键特性包括对账单和运输地址信息的严格校验，以及虚拟行业接入时的特殊配置需求。
- [Capture](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/modify/Capture/index.md): Capture功能用于国际信用卡支付等支持单独捕获的支付方式，分为授权和捕获两个步骤。支持自动和手动捕获策略，默认为自动捕获。手动捕获需设置captureDelayHours参数并调用CAPTURE-预授权确认API。关键参数包括merchantTransactionId、merchantCaptu
- [VOID](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/modify/Void/index.md): VOID操作用于取消已授权但未捕获的支付，释放预留资金。适用于支持单独Capture的支付方式如国际信用卡支付。通过调用VOID-预授权撤销API并设置notificationUrl来发起和接收异步通知。状态包括SUCCESS、FAILED及PROCESSING。多次调用需使用不同的merchant
- [Refund](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/modify/Refund/index.md): 退款功能允许商家在交易完成后将部分或全部金额返还给购物者。适用于已捕获的支付，支持全额及多次部分退款。通过调用申请退款API发起退款，需设置notificationUrl以处理退款状态。退款具有时效性，且根据merchantRefundId幂等，确保安全多次调用。
- [Tokenization](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/features/tokenization/overview/index.md): Tokenization技术用于安全存储购物者的支付信息，支持主要卡品牌及部分本地支付方式。通过生成令牌，可实现更快的结账、订阅支付、自动充值等功能。首次支付时收集支付信息并生成令牌，后续支付使用该令牌即可。默认按商户accId存储令牌。若未完全符合PCI DSS要求，建议使用Tokenizatio
- [NetworkToken](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/features/tokenization/networkToken/index.md): NetworkToken是在线支付模块中的一个功能，用于通过卡组token实现安全支付。适用于需要提高交易安全性与效率的场景。关键参数包括paymentMethod.type（固定为networkToken）、schemeTokenValue（卡组token）、paymentBrand（卡品牌，支持
- [CardOnFile 概览](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/features/tokenization/cardOnFileOverview/index.md): CardOnFile（CoF）允许商户在用户授权后安全存储并重复使用信用卡信息。支持Hosted收银台和Non-Hosted API两种模式，覆盖首笔绑卡、复购支付（含CVV收集）等全场景。本文提供产品介绍、整体接入流程及各子文档导航。
- [CardOnFile](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/features/tokenization/cardOnFile/index.md): CardOnFile功能支持商户在用户授权后存储并重复使用用户的支付卡信息。关键参数包括bizType、merchantUserId、createToken和token，用于标识交易类型、用户身份及卡信息标志。通过创建card token，校验卡要素（可选），展示卡列表（可选）以及使用card to
- [复购 CVV 收集收银台](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/features/tokenization/cardOnFileCVV/index.md): CardOnFile复购场景下的CVV收集收银台方案。通过内嵌收银台展示已绑卡信息并收集CVV完成支付，适用于用户复购和子账号/代练等安全校验场景。基于prePay接口cardToken参数与SDK customizeConfig配置实现。
- [复购 Non-Hosted](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/features/tokenization/cardOnFileNonHosted/index.md): CardOnFile Non-Hosted复购流程。商户服务端使用已绑定的card token调用下单并支付接口完成复购，无需收银台介入。适用于商户自行管理卡列表和支付交互的场景。
- [CodeGrant](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/features/tokenization/codeGrant/index.md): CodeGrant是PingPongCheckout在线支付模块中的授权支付方式，适用于需要用户签约后进行支付的场景。通过调用签约接口获取authUrl完成用户签约，随后使用下单并支付接口传入token、bizType（固定为'CodeGrant'）及merchantUserId完成支付。支持解约功
- [概览](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/recurring/overview/index.md): 订阅支付服务允许商家按照预设周期从用户授权账户自动扣款，适用于会员服务、定期商品消费等场景。持卡人需先授权订阅计划与支付信息，之后系统将依据既定规则自动执行扣款。首次支付成功后，后续扣款才能生效。使用前需与技术支持确认扣款及补扣策略。
- [订阅支付](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/onlinePayment/recurring/recurring/index.md): 订阅支付API允许商户实现定期自动扣款功能，适用于需要定期收费的服务。支持Hosted和Non-Hosted两种接入模式。主要流程包括持卡人授权和计划扣款。关键参数包括bizType（固定值Recurring）和primaryMerchantTransactionId（首次交易标识）。

### 开发指南

- [API 使用基本规则](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/APIUsage/index.md): API 使用基本规则介绍了PingPongCheckout支付API V4的使用规范，适用于需要集成支付功能的开发者。所有请求需通过HTTPS发送，并采用JSON格式。关键特性包括：支持UTF-8字符集、参数兼容性良好以及包含必要的公共请求与响应参数如accId、clientId等，确保安全性和数据
- [API 端点地址](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/endpoint/index.md): API端点地址文档介绍了PingPongCheckout提供的在线、终端及商户后台的API接入域名。根据业务场景和注册地选择对应站点（FRA、SG、US），支持沙箱和生产环境，提供详细的API域名配置和JS-SDK集成说明。
- [签名规约](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/sign/index.md): 签名规约定义了PingPongCheckout API v4的请求签名生成与验证规则，确保数据安全。适用于所有使用该API进行支付处理的场景。支持MD5和SHA256两种签名算法，推荐使用更安全的SHA256。详细说明了待签名字符串组装、签名值计算步骤及提供了签名工具类示例代码。
- [支付通知接入说明](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/paymentNotify/index.md): 支付通知接入说明介绍了如何配置和接收PingPongCheckOut的异步通知。开发者需提供一个支持HTTP POST的Web服务，设置有效的`notificationUrl`以接收JSON格式的通知数据，并根据约定返回HTTP状态码。文档还提供了回调通知服务器的IP信息及重试机制等关键细节。
- [LLM 文档集成](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/llms-integration/index.md): 本文档介绍如何通过 llms.txt 协议让 AI 工具（如 Cursor、Windsurf、Claude）自动获取 PingPongCheckout API 文档，实现智能代码补全和 API 调用辅助。
- [支付回调和查单实现指引](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/bestPractices/fetchStatus/index.md): 支付回调和查单实现指引介绍PingPongCheckout V4的两种同步状态方式：异步通知与交易查询。为确保订单状态准确更新，建议商户通过前端重定向至支付结果页面并调用查单接口确认状态，同时后台需有效处理异步通知，并在未收到通知时主动发起交易查询。此外，针对长时间未支付订单，系统将自动关单并通过指
- [换汇说明](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/bestPractices/currencyExchange/index.md): 换汇说明介绍在PingPongCheckout中处理不同币种交易的规范。当展示币种与实际支付币种不一致时，需进行换汇操作。文档提供了换汇请求参数示例、信用卡及APM展示示例，并解释了异步通知中的关键参数如`currency`和`exchangedCurrency`。提示开发者注意汇率波动可能导致的金
- [交易幂等](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/paystatus/index.md): 介绍交易幂等模式及状态管理。支持非失败终态和失败终态两种幂等模式，涵盖自动Capture和手动Capture的不同交易状态。文档详细描述了订单生命周期中的状态转移规则，包括异步通知机制和关单处理。此外，还强调了merchantTransactionId的全局唯一性要求以及重试窗口的使用。
- [交易挽回](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/bestPractices/rescue/index.md): 交易挽回指南介绍如何处理因账户资金不足等原因导致的失败交易。PingPongCheckout 为有成功机会的被拒绝支付提供自动重试或短期重试窗口，以提高支付成功率。商户可通过设置相同的 requestId 来避免重复支付（仅限Non-Hosted模式）。对于不在重试窗口内的交易，建议通过在订单号后添
- [APM 接入方式实践](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/bestPractices/apmDemo/index.md): 介绍APM接入方式的最佳实践，适用于需要集成如Klarna等本地支付方式的开发者。内容涵盖模拟展示支付效果的方法，强调结算页商品信息与实际支付请求参数独立，便于灵活测试和开发。
- [特殊支付方式退款说明](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/guide/bestPractices/specialRefund/index.md): 特殊支付方式退款说明介绍如何对特定支付方式进行退款操作，包括VNM QR、promptPay和VA等。每种支付方式的退款请求需遵循特定参数要求，如账户号、手机号或邮箱等，并且部分参数为必填项。在对接前请与技术支持确认。

### 接入方式

- [概览](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/overview/index.md): 介绍如何选择和配置在线支付产品的集成方式。涵盖从预构建集成到自定义结账体验的多种方案，适用于不同技术水平和需求的商户。推荐的集成方式包括跳转收银台、内嵌SDK及S2S，分别适合低技术投入、轻度定制和完全自定义场景。此外，还提供无代码集成选项如支付链，以及与各类平台和插件的兼容性支持。
- [SaaS 建站平台](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/sass/index.md): 介绍如何在主流SaaS建站平台上集成PingPongCheckout支付，适用于希望无需额外开发即可快速接入支付解决方案的商家。只需简单配置，支持Shopify、Magento等平台，覆盖全球主要市场，提供安全便捷的支付体验。
- [Plugins](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/plugin/index.md): 插件模块介绍了一系列为开源电子商务平台设计的集成解决方案，旨在优化结账流程。这些插件支持PingPongCheckout支付功能，易于安装且配置简单，适用于希望提升客户支付体验的商家。
- [支付链](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/payByLink/index.md): 支付链是PingPong提供给商户的一种快捷收单方式，适用于无需网站对接的场景。通过在PingPongCheckout后台添加支付信息，生成链接发送至用户邮箱，用户点击后进入支付页面完成交易。支持全球范围内的支付，主要特点包括操作简便、快速集成。使用前需联系运营开通权限。
- [概览](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/hosted/index.md): Hosted 模式用于快速接入 PingPongCheckout 收银台，适用于希望由 PingPong 承担支付页渲染与支付流程管理的场景。本文帮助你快速判断适用方案（JS-SDK / Redirect）、了解关键能力，并给出最短接入路径。
- [内嵌SDK（预下单）](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/sdk-v4/index.md): 内嵌SDK（预下单）提供了一种通过JavaScript-SDK快速集成支付功能的方法，适用于需要在网页中直接嵌入支付界面的场景。支持沙箱及多个生产环境部署，允许自定义支付按钮和语言设置，并提供了beforeCheckoutHook和checkoutFailedHook等钩子函数以满足特定业务需求。
- [OnePage Checkout](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/sdk-v4-2/index.md): OnePage Checkout 是适用于一页式结账场景的站内支付组件方案。商户服务端先获取 sdkAccessToken 完成组件初始化，买家点击支付后再由商户后端调用 prePay（预下单）接口创建支付订单，并将支付 token 返回给前端 SDK 提交支付。
- [PingPong Element SDK 集成指南](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/sdk-elements/index.md): PingPong Element SDK 支持下单并支付、绑定钱包等多元支付场景。采用全新架构设计,提供统一的API接口、灵活的事件模型和可扩展的支付组件。集成流程包括引入SDK脚本、初始化配置、创建支付元素、事件监听与处理,并提供营销活动集成功能。
- [Native SDK](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/native-sdk/index.md): PingPong Checkout Native SDK 是专为移动应用设计的支付收银台 SDK，提供半屏支付体验。支持 iOS 和 Android 平台，涵盖银行卡支付、Apple Pay、Google Pay 等多种支付方式。
- [Native SDK - iOS 接入指南](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/native-sdk-ios/index.md): iOS 客户端接入 PingPong Checkout Native SDK 的完整指南，涵盖环境要求、导入说明、SDK 配置、关键接入步骤及 Apple Pay 配置。
- [Native SDK - Android 接入指南](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/native-sdk-android/index.md): Android 客户端接入 PingPong Checkout Native SDK 的完整指南，涵盖环境要求、导入说明、SDK 配置及关键接入步骤。
- [合规接入总览](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/native-sdk-compliance/overview/index.md): PPCashDeskSDK Native SDK 合规接入指南，说明 SDK 对上架合规的影响及商户需完成的操作。
- [iOS App Store 上架合规](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/native-sdk-compliance/appstore/index.md): PPCashDeskSDK 对 iOS App Store 上架的合规影响说明，包含 Privacy Manifest 要求和商户需完成的操作。
- [Android Google Play 上架合规](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/native-sdk-compliance/google-play/index.md): PPCashDeskSDK 对 Android Google Play 上架的合规影响说明，包含 Data Safety 声明和权限声明要求。
- [跳转收银台](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/link/index.md): PingPong Checkout Page 是一款低代码支付页面解决方案，适合希望快速上线收银台支付功能、并接受买家跳转至 PingPong 托管收银台完成支付的团队。
- [Non-hosted 国际信用卡支付](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/non-hosted-card/index.md): Non-hosted 国际信用卡支付方案适用于具备PCI-DSS认证的商户，能够自行开发并处理持卡人信息。该方案通过SafePayGuardJs和SecureShieldJs插件收集风控参数，并在用户点击支付后提交至PingPongCheckout服务端处理。支持全球范围内的信用卡支付，提供3D安全
- [Non-hosted 本地支付](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/integrate/non-hosted-apm/index.md): Non-hosted 本地支付提供了一种无需跳转至第三方页面的支付集成方案，适用于希望在自有平台上完成交易流程的商户。主要通过调用下单并支付API创建订单，并根据返回的action对象中的参数决定展示二维码或跳转链接来引导用户完成支付。支持异步通知机制确保交易状态同步，覆盖地区广泛，包括但不限于亚洲

### 附录

- [国家代码](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/countryCode/index.md): 国家或地区代码列表提供全球各国的二字码。适用于需要标准化国家标识符的场景，如国际支付、物流和数据交换等。该列表涵盖从阿富汗到中非共和国等多个国家和地区，确保在跨国业务中准确无误地使用国家代码。
- [交易币种](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/transactionCurrency/index.md): 交易币种列表提供了全球多种货币的详细信息，包括货币名称、三字码及最小单位的小数位数。适用于需要处理多币种交易的支付系统或金融应用，确保在国际支付中准确表示货币金额。
- [Issuer Response Codes](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/actionCode/index.md): 发卡行响应码列出支付处理过程中可能遇到的各种响应代码，包括Discover、Visa和Mastercard的响应码。这些代码用于解释交易被接受、拒绝或需要进一步处理的原因，帮助商户和技术人员快速定位问题并采取相应措施。
- [换汇币种支持](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/exchange/index.md): 换汇币种支持列出可兑换的货币对。该表适用于需要进行国际货币兑换的场景，涵盖从AED到JPY等多种主要货币间的转换，帮助用户了解支持的货币种类及兑换方向，便于跨境交易和资金管理。
- [制裁国家列表](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/sanctionedCountries/index.md): 制裁国家列表提供了受国际制裁的国家和地区信息，包括中文名称和国家二字码。适用于需要遵守国际制裁规定的支付、贸易及其他业务场景。特别注意，克里米亚、顿涅茨克和卢甘斯克地区虽然属于乌克兰，但在某些情况下被单独提及。
- [状态码](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/successCodeList/index.md): 状态码文档列出了支付系统中各类操作结果的返回码及其说明，适用于请求处理、交易状态及配置校验等场景。成功状态如交易成功（000000）和请求成功（001000），异常包括商户禁用（101000）、参数错误（102000）等，帮助开发者快速定位问题并优化集成。
- [disputes API 枚举说明](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/chargebackReasonCode/index.md): 列举了与争议处理相关的枚举值，包括chargebackStatus、CBReasonCodeEnum、CBDocTypeCodeEnum和CBRequirementLevelEnum。这些枚举值定义了争议的不同状态、原因、所需证明材料类型及其是否必填属性，适用于支付争议管理和处理流程中，帮助开发者准
- [文档更新记录](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/docUpdateRecord/index.md): 文档更新记录列出了2025年各月的支付API及SDK更新详情，包括新增API端点地址、优化统一下单和面对面支付接口参数、增加微信小程序支付响应参数以及内嵌SDK功能增强等。
- [泰国退款银行列表](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/XenditRefundBankList/index.md): 泰国退款银行列表提供了支持退款服务的泰国银行代码和名称。适用于处理泰国地区的退款交易，涵盖主要商业银行及部分国际银行分支机构，确保退款流程中银行信息准确无误。
- [GpayBankCode](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/GpayBankCode/index.md): GpayBankCode提供了越南主要银行的代码表，包括银行名称、银行代码和Pin Bank代码。适用于需要在支付系统中识别或验证越南银行信息的场景。
- [美国加拿大地区各state简码表](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/stateCode/index.md): 此文档提供了美国和加拿大各州及地区的中文名称、英文名称及其对应的简码。适用于需要在支付系统中识别或验证这些地区信息的场景，如地址填写、物流配送等。
- [语言代码](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/languageCode/index.md): 语言代码列表提供了多种语言及其对应地区的Locale标识符和API传送取值，用于在多语言环境中统一语言设置。表格列出了包括德语、英语、西班牙语、法语、意大利语和日语等主要语言的地区变体及对应的API参数值，便于开发者根据用户所在地区选择合适的语言版本。
- [CodeGrant](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/appendix/codeGrant/index.md): CodeGrant是一种本地支付的Tokenization方案，通过用户身份验证授权支付，在电子商务和移动支付中广泛应用。适用于支持电子钱包绑定及后续支付操作，确保交易安全便捷。

### 术语

- [accId](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/accId/index.md): accId是PingPong商户店铺号，作为商户在PingPongCheckout平台上的唯一标识。完成PingPong商户注册后可获取该标识，已注册用户可登录商户后台查看。
- [Authorization](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/Authorization/index.md): Authorization（预授权）是信用卡支付处理的第一步，用于验证信用卡有效性并暂时冻结账户中一定金额。适用于电子商务、应用内及销售点支付场景。通过API调用实现，关键步骤包括交易发起、发送授权请求至发卡行、处理请求和返回授权响应。预授权有效期通常为7天，过期自动VOID。
- [clientId](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/clientId/index.md): clientId是PingPong商户在PingPongCheckout的唯一标识。完成PingPong商户注册后，可通过登录商户后台并访问账户中心获取该ID，用于识别和管理商户信息。
- [Capture](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/Capture/index.md): Capture（捕获）指将已授权的资金从购物者账户正式转移到商家账户。默认情况下，支付授权后立即自动完成捕获。许多支付方式支持分开的授权和捕获，允许设置捕获延时、手动捕获或部分捕获，并可取消授权。捕获与取消、退款一起归类为修改支付状态的操作。
- [Void](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/Void/index.md): Void是指预授权撤销，用于商家决定拒绝已授权但未捕获的支付。适用于检测到高风险欺诈等情况。一旦支付被成功捕获，则无法再通过VOID取消，此时需通过退款流程将款项退还给消费者。
- [groupId](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/groupId/index.md): groupId是商户后台网站管理中用于标识群组的唯一编号。在群组管理页面，通过创建或选择已有群组并查看详情，可获取群组名称下的groupId。每个群组可以关联多个accId。
- [PCI 合规导航](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/PCI/index.md): PCI 合规导航定义了支付卡行业数据安全标准(PCI DSS)，确保处理持卡人数据的公司维护安全环境。适用于所有接受信用卡或参与支付处理的实体，如商户、银行和服务提供商。获取PCI资质需遵守PCI DSS标准，完成自我评估问卷或外部审计，并进行定期安全扫描。集成方式包括使用PingPongCheck
- [salt 获取](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/salt/index.md): salt 作为PingPong商户的密钥，用于验证PingPongCheckout API调用。完成注册后，商户可登录后台，在密钥管理中查看和管理salt。若发现密钥泄漏，可通过刷新功能生成新密钥以确保安全。
- [transactionId](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/transactionId/index.md): transactionId是用于唯一标识一项交易的字符串或数字，确保在线交易和点对点转账的安全性和正确性。在PingPongCheckOut中，transactionId特指PingPong交易流水号，适用于追踪和管理交易流程。
- [持卡人](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/cardHolder/index.md): 持卡人指使用银行发行的卡进行无现金支付的购物者。该术语适用于描述在各类支付场景中，通过银行卡完成交易的个人或企业用户。理解此概念有助于更好地设计和优化支付流程及相关服务。
- [Card networks (or Card schemes)](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/CardNetworks/index.md): 支付网络定义了卡片发行与交易处理的标准，确保发卡方和收单方在同一系统内运作。全球主要的支付网络如Visa、Mastercard、American Express及银联等，不仅提供必要的技术支持，还决定了包括互换费在内的各种交易成本。
- [CardNumber（PAN）](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/CardNumber/index.md): CardNumber（PAN）是指支付卡上的唯一号码，用于识别每张卡并在交易中引用。前六位或八位数字构成银行识别号（BIN），帮助识别发卡机构。卡片还可能包含安全码以支持非现场交易的安全性。
- [CardOnFile (CoF)](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/CardOnFile/index.md): CardOnFile (CoF) 是一种将卡片详情存储以简化回头客结账过程的技术，适用于一键支付、按使用付费服务或不固定时间表的定期支付。若商家符合PCI 1级/2级合规性，则可自行存储卡片信息。
- [NetworkToken](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/networkToken/index.md): 网络令牌化是Visa、Mastercard等提供的服务，用16位数字替代主账号以增强支付安全性。使用网络令牌可提高授权率、减少购物者摩擦，并通过一次性密码保护每笔交易。即使卡片过期或丢失后重新发行，原有令牌仍有效。目前PingPongCheckout暂不支持直接收集网络令牌，但允许使用已有的令牌进行
- [Cards](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/Cards/index.md): Cards是由银行发行的塑料卡，用于实现无现金支付。包括借记卡、信用卡和预付卡，通过卡号、安全码等信息进行交易验证。卡片广泛应用于销售点、电子商务网站及移动应用内支付，并可与电子钱包关联，支持取现和线上支付。
- [Tokenization](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/Tokenization/index.md): Tokenization 是一种数据保护技术，将敏感信息如信用卡号转换为随机生成的字符串（token），用于增强支付系统的安全性。该技术在用户通过支付网关进行交易时，使用token代替真实卡号处理支付，防止敏感信息泄露。主要优势包括提高安全性、简化合规性、增强客户信任和支持多种支付场景。国际信用卡和
- [失败终态](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/FailureFinalState/index.md): 失败终态是一种交易状态流转模式，在此模式下，支付失败后订单状态为终态，无法再次支付，需更换订单号重新发起。适用于需要严格控制重复支付的场景。主要状态包括SUCCESS、CLOSED、FAILED、PROCESSING和INIT。
- [Disputes](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/disputes/index.md): 争议是指持卡人对某笔交易提出异议的过程，涉及持卡人、发卡行、收单行和商户之间的沟通与协商。争议处理阶段相对灵活，通过初步沟通解决异议；若未能解决，则可能升级为拒付，导致交易金额逆转并对商户产生较大影响。
- [Chargebacks](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/chargebacks/index.md): Chargebacks（拒付）是发卡行在争议无法通过初步沟通解决后，将交易金额从商户账户中强制扣除并退还给持卡人的正式交易逆转机制。适用于处理持卡人对交易的异议，涉及争议升级、拒付通知、商户回应和仲裁等步骤。拒付时效为持卡人发起调单拒付180天，商户回复90天。
- [拒付通知](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/NotificationOfChargeback/index.md): 拒付通知（Notification of Chargeback, NoC）是发卡银行发起的一种通知，告知商户某笔交易存在争议。NoC可以在信息请求后发起，或直接在交易状态设为已结算或已退款后发起。一旦发起NoC，争议处理流程开始，资金将从商户账户中扣除。适用于全球范围内的银行卡交易，关键步骤包括发起
- [预仲裁](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/technicalterm/PreArbitration/index.md): 预仲裁是信用卡交易争议处理过程中的关键阶段，旨在通过进一步的证据交换和沟通，在正式仲裁前解决争议。适用于商户对首次拒付结果不满意或发卡银行不认可商户证据的情况。双方可提交额外证据，发卡银行评估后决定是否撤销拒付。若无法达成一致，争议将进入正式仲裁。

### 风险管理

- [Dynamic 3D Secure](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/risk/3ds/index.md): Dynamic 3D Secure是一种安全协议，用于在线交易验证及防欺诈。适用于支持PingPongCheckout的网站或移动应用，在支付过程中增加额外的安全层。根据风险评估，系统自动决定是否启用3D认证。认证流程包括无需用户交互的Frictionless和需额外验证的Challenge两种方式
- [概览](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/risk/overview/index.md): 概述支付和银行业中的'争议'与'拒付'概念及处理流程。适用于商户理解如何应对客户发起的交易质疑，包括调单、拒付通知、预仲裁及正式仲裁等步骤。快速争议解决（RDR）机制亦被介绍，旨在通过自动化手段简化争议解决过程。
- [概览](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/risk/disputesAPI/index.md): dispute API 用于自动化处理支付争议，支持主动获取调单和拒付明细、查询与上传抗辩材料等功能。适用于在争议发起后迅速响应并管理整个流程，包括提交或放弃申诉。通过该API，商家能够更高效地应对发卡行的调单要求及拒付情况。
- [拒付通知接入说明](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/risk/disputeNotify/index.md): 拒付通知接入说明提供了商户如何接收并处理拒付相关事件的指南。适用于需要实时了解和响应拒付情况的商户，通过配置技术支持提供的回调地址，接收PingPongCheckOut以HTTP POST方式发送的JSON格式异步通知。关键特性包括支持特定eventCode识别拒付阶段，以及通过返回200 Http

### 对账服务

- [SFTP服务申请](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/reconciliation/transactionStatementDownload/index.md): SFTP对账服务用于下载交易报表，所有报告将上传至SFTP服务器并以zip格式提供。申请前需提交商户服务器IP、RSA公钥及ClientId至指定邮箱。PingPongCheckout会将IP加入白名单，公钥配置于SFTP服务中，并用ClientId生成对账单。
- [结算周期和对账单](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/reconciliation/settlementCycle/index.md): 结算周期和对账单定义了PingPongCheckout的结算规则及对账方式。支持T+(N)、指定日期和周结三种结算模式，具体周期依合同而定。对账单按结算周期分为每日、每周或每月生成，数据区间对应不同结算类型，确保准确反映交易状态。
- [对账文件在SFTP的路径规则](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/reconciliation/settlementFilePath/index.md): 对账文件在SFTP的路径规则用于指导商户在SFTP服务器上查找账单文件。每个商户的账单文件存放在以`clientId\登录名`命名的目录下，每天、每周、每月分别以`YYYYMMDD`、`YYYYMMDD-YYYYMMDD`、`YYYYMM`格式生成新的子目录存放相应周期的账单压缩文件。
- [对账单sheet说明](https://acquirer-api-docs-v4-en.pingpongx.com/notes/zh/reconciliation/settlementFileSheet/index.md): 对账单sheet说明文档介绍了PingPongCheckout的账单模板及各sheet用途，包括结算报告、交易流水、退款、拒付费用等关键数据，帮助商户进行财务核对与管理。