For credit card transactions, consumers maintain the right to initiate a dispute within 180 days of the charge date. When a dispute is filed, a dispute fee of $20 will be assessed per transaction.
Upon receiving a dispute notification, you have two options for response
First: you may accept the dispute by submitting a response to the issuing bank affirming that you do not contest the refunded amount.
Second, you may counter the dispute by completing a guided submission process that prompts you to provide relevant evidence and supporting documentation for your case.
Should you elect to counter a dispute, an additional dispute countered fee of $20 will be applied. In the event that the issuing bank does not accept your counter materials and rules in favor of the consumer, both the dispute countered fee will be deducted and the consumer’s payment will be refunded to them.
Regarding fee refunds, Haipay will return the dispute countered fee if you successfully win the dispute. However, unless explicitly stated otherwise in your Haipay contract, the initial dispute fee is non-refundable under all circumstances.
PCI Compliance: Direct violation of PCI DSS requirements
Security Risks: WebView and iframe may not provide sufficient security isolation
Man-in-the-Middle Attacks: Malicious applications may intercept or tamper with payment data
Phishing Risks: Cannot ensure users are entering sensitive information in a trusted environment
Credit card payment offers two integration modes, the key difference being who hosts the payment page:
Comparison
PayUrl Redirect Mode
JS CDN Embedded Mode
Payment Page
Redirects to HaiPay-hosted payment page
Embeds payment components in merchant’s own page
Frontend Effort
Almost zero, only handle redirect
Need to import JS script and listen to events
UI Control
Low, page style controlled by HaiPay
High, customizable theme, layout and interaction
Key Response Field
Use payUrl from response
Use clientToken from response
Use Case
Quick integration, no customization needed
Custom checkout, immersive payment experience
PayUrl Redirect Mode
JS CDN Embedded Mode
The simplest integration method. After the merchant server calls the collection application API, use the returned payUrl to redirect the user to HaiPay’s hosted payment page, where the user completes credit card information entry and payment authorization.Integration Process
1
Server calls collection application API
Merchant server sends a Collection Application request to HaiPay, passing required parameters such as transaction amount, payment method, and callback URLs.
2
Get payUrl and redirect
The API response contains a payUrl field. Merchant redirects the user’s browser to this URL.
3
User completes payment
User completes credit card information entry and payment authorization on HaiPay’s hosted page. After payment, HaiPay redirects the user back to the merchant’s callBackUrl and sends an async notification to notifyUrl.
Example Code (Frontend redirect after server obtains payUrl)
// Assume your server has called the collection application API and returned payUrl to the frontendconst payUrl = response.data.payUrl;// Redirect in current windowwindow.location.href = payUrl;// Or open in a new window// window.open(payUrl, '_blank');
Recommendations
Ideal for the fastest payment integration with minimal frontend changes.
No strong customization requirements for the payment page UI.
In mobile H5 scenarios, the redirect experience typically meets requirements.
By importing HaiPay JS scripts, payment components are embedded directly in the merchant’s page. The merchant server calls the collection application API to obtain a clientToken, and the frontend uses this token to initialize the component. Users can complete payment on the current page without redirection.The JS CDN provides the following component types. Choose based on your checkout design requirements:
Custom Combined Mode
Apple Pay / Google Pay (Deprecated Soon)
Credit Card (Deprecated Soon)
Displays Google Pay, Apple Pay, and Credit Card in a single container. Supports switching between one-time payment and subscription payment via the mode parameter. Ideal for merchants who need unified management of multiple payment scenarios.Scripthttps://cashier.haipay.top/js/composite-component_1.0.0.min.jsParameters
Parameter
Required
Description
sandbox
Yes
true for test environment, false for production
clientToken
Yes
Client token returned from collection application API
mode
Yes
Payment scenario: payment (one-time payment) or subscription (subscription payment)
showPayButton
No
Whether to display the credit card submit button. Default: false (hidden)
This component will be deprecated soon. Please use “Custom Combined Mode” instead.
Suitable for scenarios where you already have a wallet payment entry and want to quickly trigger Apple Pay / Google Pay authorization.Scripthttps://cashier.haipay.top/js/applePayGooglePay_1.0.0.min.jsParameters
Parameter
Required
Description
sandbox
Yes
true for test environment, false for production
clientToken
Yes
Client token returned from collection application API
buttonType
No
Button text type, options: plain, buy (default), check-out, subscribe, etc.
buttonTheme
No
Button theme, options: black (default), white
buttonHeight
No
Button height (px), default 50
Events
ready — Button rendered successfully, ready for interaction
error — Initialization failed or payment error occurred
paymentStatus — Payment result notification (if not listened, the component will handle result display automatically)
This component will be deprecated soon. Please use “Custom Combined Mode” instead.
Suitable for scenarios that require directly displaying a credit card payment form with merchant-controlled submission timing.Scripthttps://cashier.haipay.top/js/creditCard_1.0.0.min.jsParameters
Parameter
Required
Description
sandbox
Yes
true for test environment, false for production
clientToken
Yes
Client token returned from collection application API
cardTheme
No
Form theme, options: black, white (default)
Events
ready — Credit card form rendered successfully, ready for interaction
confirm — Form submission result (success/failure)
paymentStatus — Payment result notification (if not listened, the component will handle result display automatically)
Unique user identifier (e.g., userId), used for risk control, must be real and valid, otherwise it will affect transactions. Format requirements: digits, uppercase and lowercase letters or common symbols -~!@#$%&*()_.
paymentMethods
No
String
Supported payment method list, separated by English commas, e.g., CREDIT_CARD,GOOGLE_PAY,APPLE_PAY
Unique user identifier (e.g., userId), used for risk control, must be real and valid, otherwise it will affect transactions. Format requirements: digits, uppercase and lowercase letters or common symbols -~!@#$%&*()_.
tokenID
No
String
Payment token, not required for first transaction, required for subsequent active deductions, obtained through callback
token
No
String
Apple Pay / Google Pay Token, you can obtain and transfer the data yourself or use the HaiPay page., How to get?
loadingType
No
Integer
0 (default) – Display the current/normal payment result view; 1 – Show a loading spinner with no order information.
cancelUrl
No
String
If provided, the user can click “Back” on the payment page to return to this URL after canceling the payment.
paymentMethods
No
String
Supported payment method list, separated by English commas, e.g., CREDIT_CARD,GOOGLE_PAY,APPLE_PAY
Initiate a refund operation for the original credit card transaction order. Please pay attention to the status values returned synchronously. It is recommended to use the query interface for status checks.
URL:USD: /usd/refund/applyParameters:
Parameter Name
Required
Type
Description
appId
Yes
Long
Business ID (obtained from backend, must pass corresponding business ID based on currency in URL)
orderId
Yes
String
Merchant refund application order number (new merchant order number, cannot use original collection merchant order number)
orderNo
Yes
String
Platform order number (original collection platform order number returned)
refundAmount
No
String
Optional, will issue full refund if not provided
sign
Yes
String
Signature
Response data parameter description
Parameter Name
Type
Description
appId
String
Business ID
orderNo
String
Platform order number (original collection platform order number returned)
orderId
String
Merchant refund application order number
refundNo
String
Platform refund number for this refund
status
String
Refund status: 1 indicates refund application success, 0 indicates processing, 2 indicates failure. Initially returns processing, status needs to be checked via query interface later
8. MIT (Merchant Initiated Transaction) Mode Description
MIT (Merchant Initiated Transaction)
Refers to transactions that merchants can initiate without the user being present after the user completes a one-time payment authorization.
This mode is widely used in business scenarios such as subscription payments, installment payments, membership renewals, delayed deductions, etc.
User enters payment information during the first payment and completes necessary identity verification.
Merchant saves the user’s payment credentials for subsequent deduction requests.
Merchant-Initiated Deduction
Merchant directly uses saved payment credentials to initiate deduction requests based on agreed cycles or conditions.
Since the transaction is an offline scenario (off-session), meaning the user is not involved in the transaction, the system will complete processing based on user authorization and compliance requirements.
Authentication Requirements
In most cases, transactions will complete directly.
If the issuing bank or risk control system requires re-verification, the transaction may enter a pending user confirmation state, requiring user supplementary verification to complete.