# LLM Documentation

This file contains links to all documentation sections.

## Table of Contents

### Integration Preparation

- [Prerequisites](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/start/step/index.md): Prerequisites documentation introduces the necessary steps before using PingPongCheckout, including obtaining sandbox accounts, determining integration solutions, API authorization configuration, and production environment verification. It covers the entire process from testing to official launch, suitable for developers who wish to integrate payment solutions.
- [Sandbox Access Instructions](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/start/registerSandbox/index.md): The sandbox access instructions provide steps to enter the PingPong payment system test environment. Suitable for developers to perform functional testing and integration debugging before official launch. The process includes registering an account through the designated website, selecting merchant type and submitting information, and obtaining necessary test parameters such as accId, clientId, and salt. After completing all preparations, contact technical support to configure the environment.
- [Sandbox Constraint Limitations](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/start/limitSandbox/index.md): The sandbox environment provides developers with a secure, low-threshold testing platform that supports most core workflows and integration logic. However, please note that the sandbox is not 100% identical to the production environment, with functional limitations such as some payment methods unable to be fully tested or only able to simulate success states. Additionally, sandbox and production environment data are isolated, do not mix usage.
- [Acceptance Test Scenarios](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/start/acceptance/index.md): The acceptance test scenarios documentation details key considerations for merchant acceptance, including sandbox environment characteristics, idempotency handling requirements, and credit card 3D verification testing methods. Suitable for the final testing phase before going live, ensuring payment processes are secure and reliable.

### Quick Start

- [Sandbox Environment Usage Guide](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/sandbox/index.md): The sandbox environment is provided for developers to perform interface development and debugging, with accounts limited to use within this environment. Access address is https://sandbox-acquirer-payment.pingpongx.com. Multiple test accounts and supported local payment methods are provided, including WeChat Pay, AlipayCN, etc., along with card numbers available for testing and their properties such as whether 3DS is supported
- [Klarna Test Resources](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/Klarna/index.md): Klarna test resources provide test accounts and payment material information for online payment integration, supporting payment simulation in regions such as the United States, Finland, Germany, and Austria. Key features include strict validation of billing and shipping address information, as well as special configuration requirements when accessing virtual industries.
- [Capture](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/modify/Capture/index.md): Capture function is used for payment methods that support separate capture such as international credit card payments, divided into two steps: authorization and capture. Supports automatic and manual capture strategies, default is automatic capture. Manual capture requires setting captureDelayHours parameter and calling CAPTURE-Pre-authorization Confirmation API. Key parameters include merchantTransactionId, merchantCapture
- [VOID](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/modify/Void/index.md): VOID operation is used to cancel an authorized but uncaptured payment, releasing reserved funds. Applicable to payment methods that support separate Capture such as international credit card payments. Initiate and receive asynchronous notifications by calling the VOID-Pre-Authorization Cancellation API and setting notificationUrl. Status includes SUCCESS, FAILED, and PROCESSING. Multiple calls require different merchant IDs.
- [Refund](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/modify/Refund/index.md): The refund function allows merchants to return partial or full amounts to shoppers after a transaction is completed. Applicable to captured payments, supports full and multiple partial refunds. Initiate refunds by calling the apply refund API, set notificationUrl to handle refund status. Refunds have time limits and are idempotent based on merchantRefundId, ensuring safe multiple calls.
- [Tokenization](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/features/tokenization/overview/index.md): Tokenization technology is used to securely store shoppers' payment information, supporting major card brands and some local payment methods. By generating tokens, faster checkout, subscription payments, auto-recharge and other functions can be achieved. Payment information is collected and a token is generated during the first payment, and subsequent payments can use this token. Tokens are stored by merchant accId by default. If not fully compliant with PCI DSS requirements, it is recommended to use Tokenization
- [NetworkToken](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/features/tokenization/networkToken/index.md): NetworkToken is a feature in the online payment module that enables secure payments through card scheme tokens. It is suitable for scenarios that require improved transaction security and efficiency. Key parameters include paymentMethod.type (fixed as networkToken), schemeTokenValue (card scheme token), paymentBrand (card brand, supports
- [CardOnFile Overview](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/features/tokenization/cardOnFileOverview/index.md): CardOnFile (CoF) enables merchants to securely store and reuse credit card information after user authorization. Supports both Hosted checkout and Non-Hosted API modes, covering first-time binding, repeat purchases (including CVV collection), and more. This page provides product introduction, overall integration flow, and navigation to sub-documents.
- [CardOnFile](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/features/tokenization/cardOnFile/index.md): The CardOnFile feature supports merchants to store and reuse user's payment card information after user authorization. Key parameters include bizType, merchantUserId, createToken and token, used to identify transaction type, user identity and card information flag. By creating card token, verifying card elements (optional), displaying card list (optional) and using card token
- [Repeat Purchase CVV Collection Checkout](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/features/tokenization/cardOnFileCVV/index.md): CVV collection checkout solution for CardOnFile repeat purchase scenarios. Display stored card information and collect CVV through the embedded checkout. Suitable for user repeat purchases and sub-account/delegate security verification scenarios. Implemented via prePay API cardToken parameter and SDK customizeConfig settings.
- [Repeat Purchase Non-Hosted](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/features/tokenization/cardOnFileNonHosted/index.md): CardOnFile Non-Hosted repeat purchase flow. Merchant server uses the stored card token to call the order-and-pay API for repeat purchases without checkout page involvement. Suitable for merchants managing their own card list and payment interaction.
- [CodeGrant](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/features/tokenization/codeGrant/index.md): CodeGrant is an authorized payment method in the PingPongCheckout online payment module, suitable for scenarios where users need to sign up before making payments. Obtain the authUrl through the binding interface to complete user sign-up, then use the order and payment interface to pass in the token, bizType (fixed as 'CodeGrant'), and merchantUserId to complete the payment. Supports unbinding functionality.
- [Overview](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/recurring/overview/index.md): Subscription payment service allows merchants to automatically deduct funds from user authorized accounts according to preset cycles, suitable for membership services, regular product consumption and other scenarios. Cardholders need to first authorize the subscription plan and payment information, after which the system will automatically execute deductions based on established rules. Subsequent deductions can only take effect after the initial payment is successful. Please confirm deduction and retry policies with technical support before use.
- [Recurring Payment](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/recurring/recurring/index.md): The Recurring Payment API allows merchants to implement regular automatic deduction functions, suitable for services that require periodic charging. Supports both Hosted and Non-Hosted integration modes. The main process includes cardholder authorization and scheduled deductions. Key parameters include bizType (fixed value Recurring) and primaryMerchantTransactionId (first transaction identifier).

### Development Guide

- [Basic Rules for API Usage](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/APIUsage/index.md): The basic rules for API usage introduce the usage specifications of PingPongCheckout payment API V4, suitable for developers who need to integrate payment functionality. All requests must be sent via HTTPS and use JSON format. Key features include: support for UTF-8 character set, good parameter compatibility, and inclusion of necessary public request and response parameters such as accId, clientId, etc., ensuring security and data integrity
- [API Endpoint Addresses](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/endpoint/index.md): API endpoint address documentation introduces the online, terminal, and merchant backend API access domains provided by PingPongCheckout. Choose the corresponding site (FRA, SG, US) based on business scenarios and registration location, supporting sandbox and production environments, providing detailed API domain configuration and JS-SDK integration instructions.
- [Signature Convention](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/sign/index.md): The signature convention defines the request signature generation and verification rules for PingPongCheckout API v4 to ensure data security. Applicable to all scenarios using this API for payment processing. Supports both MD5 and SHA256 signature algorithms, with the more secure SHA256 recommended. Details the assembly of the string to be signed, signature value calculation steps, and provides example code for signature utility classes.
- [Payment Notification Integration Guide](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/paymentNotify/index.md): The payment notification integration guide introduces how to configure and receive asynchronous notifications from PingPongCheckOut. Developers need to provide a web service that supports HTTP POST, set an effective `notificationUrl` to receive JSON formatted notification data, and return HTTP status codes according to the agreement. The document also provides key details such as IP information for callback notification servers and retry mechanisms.
- [LLM Documentation Integration](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/llms-integration/index.md): This document explains how to enable AI tools (Cursor, Windsurf, Claude) to automatically fetch PingPongCheckout API documentation through the llms.txt protocol for intelligent code completion and API call assistance.
- [Payment Callback and Order Status Inquiry Implementation Guide](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/bestPractices/fetchStatus/index.md): The payment callback and order status inquiry implementation guide introduces two methods for synchronizing transaction status in PingPongCheckout V4: asynchronous notifications and transaction queries. To ensure accurate order status updates, merchants are advised to redirect users to the payment result page via frontend redirection and call the order inquiry API to confirm status, while the backend should effectively handle asynchronous notifications and proactively initiate transaction queries when notifications are not received. Additionally, for orders that remain unpaid for extended periods, the system will automatically close the order and notify through designated channels.
- [Currency Exchange Guide](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/bestPractices/currencyExchange/index.md): The Currency Exchange Guide introduces the specifications for handling transactions in different currencies in PingPongCheckout. When the displayed currency differs from the actual payment currency, a currency exchange operation is required. The document provides currency exchange request parameter examples, credit card and APM display examples, and explains key parameters in asynchronous notifications such as `currency` and `exchangedCurrency`. Developers are reminded that exchange rate fluctuations may cause amount discrepancies.
- [Transaction Idempotency](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/paystatus/index.md): Introduces transaction idempotency patterns and status management. Supports two idempotency modes: non-failure final state and failure final state, covering different transaction states for automatic Capture and manual Capture. The document details state transition rules during the order lifecycle, including asynchronous notification mechanisms and order closure handling. Additionally, it emphasizes the global uniqueness requirement of merchantTransactionId and the use of retry windows.
- [Transaction Recovery](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/bestPractices/rescue/index.md): Transaction recovery guide introduces how to handle failed transactions due to reasons such as insufficient account funds. PingPongCheckout provides automatic retries or short-term retry windows for rejected payments that have a chance of success, to improve payment success rates. Merchants can avoid duplicate payments by setting the same requestId (Non-Hosted mode only). For transactions outside the retry window, it is recommended to add a suffix to the order number
- [APM Integration Practice](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/bestPractices/apmDemo/index.md): Introduces best practices for APM integration methods, suitable for developers who need to integrate local payment methods such as Klarna. The content covers methods for simulating payment effects, emphasizing that checkout page product information is independent from actual payment request parameters, facilitating flexible testing and development.
- [Special Payment Methods Refund Instructions](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/guide/bestPractices/specialRefund/index.md): Special payment methods refund instructions introduce how to perform refund operations for specific payment methods, including VNM QR, promptPay and VA, etc. Each payment method's refund request must follow specific parameter requirements such as account number, mobile phone number or email address, and some parameters are mandatory. Please confirm with technical support before integration.

### Integration Methods

- [Overview](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/overview/index.md): Introduction to selecting and configuring integration methods for online payment products. Covers multiple solutions from pre-built integrations to custom checkout experiences, suitable for merchants with different technical levels and requirements. Recommended integration methods include redirect checkout, embedded SDK, and S2S, which are respectively suitable for low technical investment, light customization, and fully custom scenarios. Additionally, provides no-code integration options such as Payment Link, as well as compatibility support with various platforms and plugins.
- [SaaS Website Building Platform](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/sass/index.md): Introduces how to integrate PingPongCheckout payments on mainstream SaaS website building platforms, suitable for merchants who want to quickly access payment solutions without additional development. With simple configuration, supports platforms like Shopify, Magento, etc., covering major global markets and providing secure and convenient payment experiences.
- [Plugins](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/plugin/index.md): The plugin module introduces a series of integration solutions designed for open-source e-commerce platforms, aimed at optimizing the checkout process. These plugins support PingPongCheckout payment functionality, are easy to install and simply configured, suitable for merchants looking to enhance customer payment experiences.
- [Pay by Link](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/payByLink/index.md): Pay by Link is a quick payment solution provided by PingPong for merchants, suitable for scenarios that do not require website integration. By adding payment information in the PingPongCheckout backend, a link is generated and sent to the user's email. Users click the link to enter the payment page and complete the transaction. It supports global payments with main features including simple operation and fast integration. Contact operations to enable permissions before use.
- [Overview](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/hosted/index.md): This document introduces payment integration methods and configurations, including re-payment, card saving features, and embedded SDK characteristics. It is suitable for optimizing user payment experience, supporting re-payment of orders that failed to pay within 48 hours, and providing card saving to simplify the next payment process. The embedded SDK is based on Web Component technology and ES2021 standards, lightweight and fast, compatible with modern mainstream browsers, customizable skin, and payment settings
- [Embedded SDK (Pre-order)](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/sdk-v4/index.md): Embedded SDK (Pre-order) provides a method to quickly integrate payment functionality through JavaScript-SDK, suitable for scenarios that require directly embedding payment interface in web pages. Supports sandbox and multiple production environment deployments, allows custom payment buttons and language settings, and provides hook functions such as beforeCheckoutHook and checkoutFailedHook to meet specific business needs.
- [OnePage Checkout](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/sdk-v4-2/index.md): This solution is specifically designed for merchants who have adopted the OnePage Checkout model, providing embeddable payment components that seamlessly integrate into your existing checkout page. Without changing the original checkout flow, you can quickly access PingPong payment capabilities, supporting multiple mainstream payment methods covering regions such as Europe and Singapore.
- [PingPong Element SDK Integration Guide](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/sdk-elements/index.md): PingPong Element SDK supports diverse payment scenarios such as order placement and payment, wallet binding. Adopting a new architecture design, it provides unified API interfaces, flexible event models, and extensible payment components. The integration process includes importing SDK scripts, initialization configuration, creating payment elements, event listening and handling, and provides marketing campaign integration functionality.
- [Native SDK](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/native-sdk/index.md): PingPong Checkout Native SDK is a native checkout SDK for mobile applications, providing a bottom-sheet payment experience. Supports iOS and Android platforms with credit/debit card payments, Apple Pay, Google Pay, and more.
- [Native SDK - iOS Integration Guide](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/native-sdk-ios/index.md): Complete guide for integrating PingPong Checkout Native SDK on iOS, covering environment requirements, import instructions, SDK configuration, key integration steps, and Apple Pay configuration.
- [Native SDK - Android Integration Guide](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/native-sdk-android/index.md): Complete guide for integrating PingPong Checkout Native SDK on Android, covering environment requirements, import instructions, SDK configuration, and key integration steps.
- [Compliance Overview](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/native-sdk-compliance/overview/index.md): PPCashDeskSDK Native SDK compliance guide. Describes the SDK's impact on store compliance and the actions merchants need to take.
- [iOS App Store Compliance](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/native-sdk-compliance/appstore/index.md): PPCashDeskSDK compliance impact on iOS App Store submission, including Privacy Manifest requirements and merchant actions.
- [Android Google Play Compliance](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/native-sdk-compliance/google-play/index.md): PPCashDeskSDK compliance impact on Android Google Play submission, including Data Safety declaration and permission requirements.
- [Redirect to Checkout](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/link/index.md): Redirect to Checkout is a payment integration method that completes payment by redirecting to the checkout page after obtaining the paymentUrl from the order response. Supports multi-language settings, defaulting to English; if other languages are specified, the passed values will be used. Suitable for scenarios requiring quick payment function integration, ensuring users can smoothly complete the payment process in a familiar language environment.
- [Non-hosted International Credit Card Payment](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/non-hosted-card/index.md): Non-hosted international credit card payment solution is suitable for merchants with PCI-DSS certification who can develop and process cardholder information independently. This solution collects risk control parameters through SafePayGuardJs and SecureShieldJs plugins, and submits them to PingPongCheckout server for processing after the user clicks payment. Supports credit card payments worldwide and provides 3D security
- [Non-hosted Local Payment](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/integrate/non-hosted-apm/index.md): Non-hosted local payment provides a payment integration solution that does not require redirection to third-party pages, suitable for merchants who want to complete transaction processes on their own platform. It mainly creates orders by calling the order creation and payment API, and decides whether to display QR codes or redirect links based on parameters in the returned action object to guide users to complete payments. Supports asynchronous notification mechanism to ensure transaction status synchronization, covering extensive regions including but not limited to Asia

### Appendix

- [Country Codes](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/countryCode/index.md): The country or region code list provides two-letter codes for countries worldwide. It is suitable for scenarios requiring standardized country identifiers, such as international payments, logistics, and data exchange. The list covers multiple countries and regions from Afghanistan to the Central African Republic, ensuring accurate use of country codes in cross-border business.
- [Transaction Currency](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/transactionCurrency/index.md): The transaction currency list provides detailed information about multiple global currencies, including currency names, three-letter codes, and decimal places for minimum units. Suitable for payment systems or financial applications that need to handle multi-currency transactions, ensuring accurate representation of currency amounts in international payments.
- [Issuer Response Codes](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/actionCode/index.md): Issuer response codes list various response codes that may be encountered during payment processing, including response codes from Discover, Visa, and Mastercard. These codes are used to explain why transactions are accepted, rejected, or require further processing, helping merchants and technical personnel quickly identify issues and take appropriate actions.
- [Currency Exchange Support](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/exchange/index.md): Currency exchange support lists the available currency pairs for conversion. This table applies to scenarios requiring international currency exchange, covering conversions between various major currencies from AED to JPY, helping users understand supported currency types and exchange directions, facilitating cross-border transactions and fund management.
- [Sanctioned Countries List](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/sanctionedCountries/index.md): The sanctioned countries list provides information about countries and regions under international sanctions, including Chinese names and two-letter country codes. It is applicable to payment, trade, and other business scenarios that need to comply with international sanctions regulations. Please note that the regions of Crimea, Donetsk, and Luhansk, although part of Ukraine, are sometimes mentioned separately.
- [Status Codes](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/successCodeList/index.md): The status code documentation lists return codes and their descriptions for various operations in the payment system, applicable to scenarios such as request processing, transaction status, and configuration validation. Success statuses include transaction success (000000) and request success (001000), while exceptions include merchant disabled (101000), parameter errors (102000), etc., helping developers quickly identify issues and optimize integration.
- [disputes API Enumerations Description](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/chargebackReasonCode/index.md): Lists enumerations related to dispute handling, including chargebackStatus, CBReasonCodeEnum, CBDocTypeCodeEnum, and CBRequirementLevelEnum. These enumeration values define different states, reasons, required supporting material types, and their mandatory attributes for disputes, applicable in payment dispute management and handling processes, helping developers accurately
- [Document Update Record](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/docUpdateRecord/index.md): The document update record lists the payment API and SDK updates for each month of 2025, including new API endpoint addresses, optimized unified order and face-to-face payment interface parameters, additional WeChat Mini Program payment response parameters, and enhanced embedded SDK functionality.
- [Thailand Refund Bank List](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/XenditRefundBankList/index.md): The Thailand Refund Bank List provides bank codes and names that support refund services in Thailand. It is applicable for processing refund transactions in the Thailand region, covering major commercial banks and some international bank branches, ensuring accurate bank information in the refund process.
- [GpayBankCode](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/GpayBankCode/index.md): GpayBankCode provides a code table of major Vietnamese banks, including bank names, bank codes, and Pin Bank codes. Suitable for scenarios that require identifying or validating Vietnamese bank information in payment systems.
- [State Code Table for United States and Canada Regions](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/stateCode/index.md): This document provides Chinese names, English names, and corresponding codes for states and regions in the United States and Canada. It is applicable to scenarios requiring identification or validation of these regional information in payment systems, such as address entry, logistics delivery, etc.
- [Language Codes](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/languageCode/index.md): The language code list provides multiple languages and their corresponding regional locale identifiers and API transmission values, used to unify language settings in multilingual environments. The table lists regional variants of major languages including German, English, Spanish, French, Italian, and Japanese, along with their corresponding API parameter values, making it convenient for developers to select appropriate language versions based on user location.
- [CodeGrant](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/appendix/codeGrant/index.md): CodeGrant is a local payment Tokenization solution that authorizes payments through user identity verification, widely used in e-commerce and mobile payments. It is suitable for supporting e-wallet binding and subsequent payment operations, ensuring secure and convenient transactions.

### Technical Terms

- [accId](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/accId/index.md): accId is the PingPong merchant shop number, serving as the unique identifier for merchants on the PingPongCheckout platform. This identifier can be obtained after completing PingPong merchant registration, and registered users can view it by logging into the merchant backend.
- [Authorization](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/Authorization/index.md): Authorization (pre-authorization) is the first step in credit card payment processing, used to verify credit card validity and temporarily freeze a certain amount in the account. Applicable to e-commerce, in-app, and point-of-sale payment scenarios. Implemented through API calls, key steps include transaction initiation, sending authorization requests to the issuing bank, processing requests, and returning authorization responses. Pre-authorization is typically valid for 7 days and automatically VOIDs upon expiration.
- [clientId](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/clientId/index.md): clientId is the unique identifier for PingPong merchants in PingPongCheckout. After completing PingPong merchant registration, you can obtain this ID by logging into the merchant backend and accessing the account center, which is used to identify and manage merchant information.
- [Capture](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/Capture/index.md): Capture refers to the formal transfer of authorized funds from the shopper's account to the merchant's account. By default, payment authorization is automatically captured immediately after authorization. Many payment methods support separate authorization and capture, allowing for delayed capture, manual capture, or partial capture, and authorization can be canceled. Capture, along with void and refund, is classified as operations that modify payment status.
- [Void](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/Void/index.md): Void refers to pre-authorization cancellation, used when merchants decide to reject an authorized but uncaptured payment. Applicable in cases such as detecting high-risk fraud. Once a payment has been successfully captured, it can no longer be canceled through VOID, and refunds must be processed to return the funds to the consumer.
- [groupId](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/groupId/index.md): groupId is the unique identifier for groups in the merchant backend website management. In the group management page, you can obtain the groupId under the group name by creating or selecting an existing group and viewing details. Each group can be associated with multiple accIds.
- [PCI Compliance Navigation](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/PCI/index.md): PCI compliance navigation defines the Payment Card Industry Data Security Standard (PCI DSS), ensuring that companies processing cardholder data maintain secure environments. Applies to all entities accepting credit cards or participating in payment processing, such as merchants, banks, and service providers. Obtaining PCI certification requires compliance with PCI DSS standards, completing self-assessment questionnaires or external audits, and conducting regular security scans. Integration methods include using PingPongCheck
- [salt Retrieval](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/salt/index.md): salt serves as the merchant key for PingPong, used to verify PingPongCheckout API calls. After registration is completed, merchants can log in to the backend to view and manage their salt in Key Management. If a key leak is discovered, a new key can be generated using the refresh function to ensure security.
- [transactionId](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/transactionId/index.md): transactionId is a string or number used to uniquely identify a transaction, ensuring the security and correctness of online transactions and peer-to-peer transfers. In PingPongCheckOut, transactionId specifically refers to the PingPong transaction serial number, suitable for tracking and managing transaction processes.
- [Card Holder](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/cardHolder/index.md): A card holder refers to a shopper who uses cards issued by banks for cashless payments. This term applies to individuals or business users who complete transactions through bank cards in various payment scenarios. Understanding this concept helps in better designing and optimizing payment processes and related services.
- [Card networks (or Card schemes)](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/CardNetworks/index.md): Payment networks define the standards for card issuance and transaction processing, ensuring that card issuers and acquirers operate within the same system. Major global payment networks such as Visa, Mastercard, American Express, and UnionPay not only provide necessary technical support, but also determine various transaction costs including interchange fees.
- [CardNumber (PAN)](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/CardNumber/index.md): CardNumber (PAN) refers to the unique number on a payment card used to identify each card and reference it in transactions. The first six or eight digits form the Bank Identification Number (BIN), which helps identify the issuing institution. Cards may also contain security codes to support the security of off-site transactions.
- [CardOnFile (CoF)](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/CardOnFile/index.md): CardOnFile (CoF) is a technology that stores card details to simplify the checkout process for returning customers, suitable for one-click payments, pay-per-use services, or recurring payments on irregular schedules. If merchants meet PCI Level 1/2 compliance, they can store card information themselves.
- [NetworkToken](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/networkToken/index.md): Network tokenization is a service provided by Visa, Mastercard, etc., that replaces primary account numbers with 16-digit tokens to enhance payment security. Using network tokens can improve authorization rates, reduce shopper friction, and protect each transaction with one-time passwords. Even if cards are reissued after expiration or loss, the original tokens remain valid. Currently PingPongCheckout does not support direct collection of network tokens, but allows using existing tokens for
- [Cards](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/Cards/index.md): Cards are plastic cards issued by banks to enable cashless payments. Including debit cards, credit cards, and prepaid cards, transactions are verified through information such as card numbers and security codes. Cards are widely used for point-of-sale transactions, e-commerce websites, and in-app payments, and can be linked to digital wallets to support cash withdrawals and online payments.
- [Tokenization](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/Tokenization/index.md): Tokenization is a data protection technology that converts sensitive information such as credit card numbers into randomly generated strings (tokens) to enhance the security of payment systems. This technology uses tokens instead of real card numbers to process payments when users make transactions through payment gateways, preventing the leakage of sensitive information. Main advantages include improved security, simplified compliance, enhanced customer trust, and support for multiple payment scenarios. International credit cards and
- [Failure Final State](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/FailureFinalState/index.md): Failure Final State is a transaction status flow pattern where the order status becomes final after payment failure and cannot be paid again. A new order number is required to initiate payment again. Suitable for scenarios requiring strict control of duplicate payments. Main states include SUCCESS, CLOSED, FAILED, PROCESSING, and INIT.
- [Disputes](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/disputes/index.md): A dispute refers to the process where a cardholder raises an objection to a transaction, involving communication and negotiation between the cardholder, issuing bank, acquiring bank, and merchant. The dispute handling stage is relatively flexible, resolving objections through initial communication; if unresolved, it may escalate to a chargeback, resulting in transaction reversal and significant impact on the merchant.
- [Chargebacks](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/chargebacks/index.md): Chargebacks are a formal transaction reversal mechanism where the issuing bank forcibly deducts the transaction amount from the merchant's account and refunds it to the cardholder after disputes cannot be resolved through initial communication. Used for handling cardholder objections to transactions, involving dispute escalation, chargeback notifications, merchant responses, and arbitration steps. The chargeback timeline is 180 days for cardholders to initiate chargebacks and 90 days for merchants to respond.
- [Notification of Chargeback](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/NotificationOfChargeback/index.md): Notification of Chargeback (NoC) is a notification initiated by the issuing bank to inform the merchant that there is a dispute regarding a transaction. The NoC can be initiated after an information request, or directly after the transaction status is set to settled or refunded. Once the NoC is initiated, the dispute resolution process begins and funds will be deducted from the merchant's account. This applies to card transactions worldwide, with key steps including initiation.
- [Pre-Arbitration](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/technicalterm/PreArbitration/index.md): Pre-arbitration is a critical stage in the credit card transaction dispute resolution process, designed to resolve disputes through further evidence exchange and communication before formal arbitration. It applies when merchants are dissatisfied with the initial chargeback result or when issuing banks do not accept merchant evidence. Both parties can submit additional evidence, and the issuing bank evaluates it to decide whether to reverse the chargeback. If no agreement is reached, the dispute proceeds to formal arbitration.

### Risk Management

- [Dynamic 3D Secure](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/risk/3ds/index.md): Dynamic 3D Secure is a security protocol used for online transaction verification and fraud prevention. It applies to websites or mobile applications that support PingPongCheckout, adding an additional security layer during the payment process. The system automatically determines whether to enable 3D authentication based on risk assessment. The authentication process includes two methods: Frictionless, which requires no user interaction, and Challenge, which requires additional verification.
- [Overview](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/risk/overview/index.md): Overview of 'Disputes' and 'Chargebacks' concepts and processing workflows in payments and banking. Suitable for merchants to understand how to handle transaction disputes initiated by customers, including retrieval requests, chargeback notifications, pre-arbitration, and formal arbitration processes. The Rapid Dispute Resolution (RDR) mechanism is also introduced, designed to simplify dispute resolution through automation.
- [Overview](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/risk/disputesAPI/index.md): dispute API Used for automated processing of payment disputes, supporting proactive retrieval of transaction information and chargeback details, querying and uploading defense materials, and other functions. Suitable for rapid response and management of the entire process after dispute initiation, including submitting or abandoning appeals. Through this API, merchants can more efficiently handle issuer's retrieval requests and chargeback situations.
- [Dispute Notification Integration Guide](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/risk/disputeNotify/index.md): The dispute notification integration guide provides merchants with instructions on how to receive and process dispute-related events. Suitable for merchants who need real-time awareness and response to dispute situations, by configuring the callback address provided by technical support to receive JSON format asynchronous notifications sent by PingPongCheckOut via HTTP POST. Key features include support for specific eventCode to identify dispute stages, and returning HTTP 200

### Reconciliation Service

- [SFTP Service Application](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/reconciliation/transactionStatementDownload/index.md): SFTP reconciliation service is used to download transaction reports, all reports will be uploaded to the SFTP server in zip format. Before applying, you need to submit merchant server IP, RSA public key and ClientId to the designated email.
- [Settlement Cycle and Reconciliation Statement](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/reconciliation/settlementCycle/index.md): The settlement cycle and reconciliation statement define the settlement rules and reconciliation methods for PingPongCheckout. Supports three settlement modes: T+(N), specified date, and weekly settlement, with specific cycles determined by contract. Reconciliation statements are generated daily, weekly, or monthly according to the settlement cycle, with data intervals corresponding to different settlement types to ensure accurate reflection of transaction status.
- [Settlement File Path Rules on SFTP](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/reconciliation/settlementFilePath/index.md): The settlement file path rules on SFTP are used to guide merchants in finding billing files on the SFTP server. Each merchant's billing files are stored in directories named after `clientId\loginName`, with new subdirectories generated daily, weekly, and monthly in formats of `YYYYMMDD`, `YYYYMMDD-YYYYMMDD`, and `YYYYMM` respectively to store compressed files for corresponding periods.
- [Settlement File Sheet Description](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/reconciliation/settlementFileSheet/index.md): The settlement file sheet description document introduces the billing template of PingPongCheckout and the purpose of each sheet, including key data such as settlement reports, transaction records, refunds, chargeback fees, etc., to help merchants perform financial verification and management.

### Recurring Payment

- [Overview](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/recurring/overview/index.md): Subscription payment service allows merchants to automatically deduct funds from user authorized accounts according to preset cycles, suitable for membership services, regular product consumption and other scenarios. Cardholders need to first authorize the subscription plan and payment information, after which the system will automatically execute deductions based on established rules. Subsequent deductions can only take effect after the initial payment is successful. Please confirm deduction and retry policies with technical support before use.
- [Recurring Payment](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/onlinePayment/recurring/recurring/index.md): The Recurring Payment API allows merchants to implement regular automatic deduction functions, suitable for services that require periodic charging. Supports both Hosted and Non-Hosted integration modes. The main process includes cardholder authorization and scheduled deductions. Key parameters include bizType (fixed value Recurring) and primaryMerchantTransactionId (first transaction identifier).

### Services

- [Hosted](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/services/checkout/hosted/hosted/index.md): Hosted mode provides a solution for embedding PingPong Checkout cash register into merchant websites. Suitable for scenarios requiring quick integration of payment functions, it supports both JS-SDK initialization and redirect methods for rendering the cash register. The main process includes order submission, cash register initialization, buyer payment information filling and confirmation steps. Additionally, it provides 3DS verification options to enhance transaction security.

### 3D Secure

- [3D Secure Authentication Integration](https://acquirer-api-docs-v4-en.pingpongx.com/en/notes/threeDS/3ds/index.md): 3D Secure is an online transaction verification protocol designed to prevent fraud in e-commerce. By requiring cardholders to enter passwords or one-time codes, it provides additional security for the payment process. PingPongCheckout supports three 3ds decision schemes: enforcement, risk control decision, and external execution. The authentication process includes frictionless and challenge modes, where the former completes authentication without further user interaction, while the latter requires