CheckoutFraud ProtectionChargeback Protection

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

FieldDescription
paymentAmountTotal transaction amount
paymentMethod"card" (or other method)
last4Last 4 digits of card
binBank Identification Number
pan (optional)Full card number (if securely stored)
firstNameCardholder’s first name
lastNameCardholder’s last name
emailEmail used at time of transaction

Helps the model match identity to past payment behavior.


✅ If You Have User & Payment Data (No Card Info)

FieldDescription
firstNameUser’s first name
lastNameUser’s last name
emailUser’s email address
paymentAmountTransaction amount
paymentMethode.g., "wallet", "bank"

Enables modeling of expected users and flows.


✅ If You Have No Transaction History

FieldDescription
firstNameLikely transactor’s first name
lastNameLikely transactor’s last name
emailEmail 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 SituationRequired Data Fields
Have card transaction historypaymentAmount, paymentMethod, last4, bin, pan (opt), firstName, lastName, email
No card, but payment historypaymentAmount, paymentMethod, firstName, lastName, email
No history availablefirstName, lastName, email