Improving Chargeback Protection Acceptance Rates
📈 Maximizing Chargeback Protection
To get the most out of Approvely's chargeback protection, it’s critical to pass data that clearly ties each transaction to an individual user.
Our system depends on identity signals—such as email, name, device behavior, and historical activity—to evaluate the legitimacy of each transaction and reduce chargeback risk.
🚨 999 Error Code Explained
A 999 error means our chargeback protection provider reviewed the session data but declined to approve the transaction.
This is not based on a single factor—AI models evaluate thousands of real-time signals.
These errors are most common:
- Early in an integration
- When key user data is missing or low quality
To improve approvals:
- Use the Events API to send key user events:
- Registration
- Login success/failure
- KYC verification
These signals help the system build a user risk profile before their first transaction.
🤖 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 specific users.
Before going live, we recommend sharing:
- ✅ Historical transaction data
- ✅ List of past successful customers
This allows the model to:
- Recognize returning buyers
- Learn expected behavior
- More accurately flag risky users
Without this data, the system defaults to caution, 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 the 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 historical card 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., "wallet", "bank" |
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: What Data Points to Send
| 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 |
Updated 4 months ago