Improving Chargeback Protection Acceptance Rates
To get the most out of Coinflow’s chargeback protection, it’s critical to pass data that clearly ties each transaction to the individual user. Our system depends on identity signals—such as email, name, device behavior, and prior activity—to evaluate the legitimacy of each transaction and reduce chargeback risk.
📘 Use this data template to ensure you’re passing the right signals to maximize approval rates.
999 Error Code Explained
A 999 error means our chargeback protection provider reviewed the session data but declined to approve the transaction. This decision is not based on a single factor—AI models evaluate thousands of real-time signals.
These errors are most common early in an integration or when key user data is missing or low quality.
To improve approvals, merchants can use the Events API to send key user events—such as registration, login success/failure, or KYC verification. Our provider uses these signals to build a risk profile for the user before their first transaction, increasing the likelihood of approval.
Why This Data Matters
The provider’s models evaluate:
- Average transaction size
- Behavioral patterns in your vertical
- Card and identity history
To optimize approval rates, the model should be trained on your users. Before going live, share:
- Historical transaction data
- A list of past successful customers
This helps the model:
- Recognize returning buyers
- Learn expected payment behavior
- More accurately flag risk
Without this data, the model defaults to a cautious stance, which may reduce initial approvals.
Best Practices by Customer Type
✅ If You Have Card Transaction History
| Field | Description |
|---|---|
paymentAmount |
Total transaction amount |
paymentMethod |
"card" (or other method) |
last4 |
Last 4 digits of card |
bin |
Bank Identification Number |
pan (optional) |
Full card number (if securely stored) |
firstName |
Cardholder’s first name |
lastName |
Cardholder’s last name |
email |
Email used at time of transaction |
Helps the model match identity to past payment behavior.
✅ If You Have User & Payment Data (No Card Info)
| Field | Description |
|---|---|
firstName |
User’s first name |
lastName |
User’s last name |
email |
User’s email address |
paymentAmount |
Transaction amount |
paymentMethod |
e.g., "bank", "card" |
Enables modeling of expected users and flows.
✅ If You Have No Transaction History
| Field | Description |
|---|---|
firstName |
Likely transactor’s first name |
lastName |
Likely transactor’s last name |
email |
Email address |
Start building buyer profiles early. If available, share lists of:
- Returning buyers
- Whitelisted/safe users
- Marketing or newsletter recipients
Summary of What Data Points to Send
Merchants can use this template to understand which data points to share during onboarding to help configure the risk model and optimize approval rates.
| Your Situation | Required Data Fields |
|---|---|
| Have card transaction history | paymentAmount, paymentMethod, last4, bin, pan (opt), firstName, lastName, email |
| No card, but payment history | paymentAmount, paymentMethod, firstName, lastName, email |
| No history available | firstName, lastName, email |