The Conversion Rate metric tells you what percentage of your customers’ payment attempts end in a successful payment, for a given period and aggregation level.
This article covers:
Overview
At a high level, Conversion Rate answers:
“Out of all payment attempts, how many became successful payments?”
There are two versions:
Conversion Rate excluding insufficient funds
Raw Conversion Rate (including insufficient funds)
Both use the same definition of Approved Transactions.
They differ only in which attempts are included in the denominator.
The metric is calculated per merchant and per aggregation combination (for example: day + payment category + payment method + card BIN). These are the groupings exposed in reporting and APIs.
In most day‑to‑day analyses, Conversion Rate excluding insufficient funds is the main reference, because it focuses on performance factors you can influence and sets aside customers who simply didn’t have enough balance.
Conversion Rate excluding insufficient funds
What it shows
This version answers:
“Among attempts where the customer had sufficient funds, what percentage ended in a successful payment?”
It removes from the denominator all transactions declined specifically for insufficient funds, while keeping all other declines. This isolates performance that is more directly under your control (UX, routing, risk, configuration).
How it is calculated
You need three counts:
Approved Transactions – transactions that ended in a final successful “paid” outcome.
Total Transactions – all valid payment attempts in the metric universe.
Insufficient‑funds Transactions – attempts from that same universe declined for insufficient funds.
Formula:
Conversion Rate excl. insufficient funds (%)
= Approved Transactions ÷ (Total Transactions − Insufficient‑funds Transactions) × 100
The numerator is the same as in Raw Conversion Rate. Only the denominator changes.
Example
For a single day, in a given payment category and method:
Total Transactions: 1,000
Approved Transactions: 880
Insufficient‑funds Transactions: 70
Then:
Adjusted denominator = 1,000 − 70 = 930
Conversion Rate excl. insufficient funds ≈ 880 ÷ 930 × 100 ≈ 94.6%
Raw Conversion Rate
What it shows
Raw Conversion Rate keeps all attempts in the denominator, including insufficient‑funds declines. It answers:
“Out of all payment attempts, regardless of decline reason, what percentage were successful?”
This view is useful when you want the full picture of customer experience, including cases where customers tried to pay without enough funds.
How it is calculated
Using the same Approved and Total counts:
Conversion Rate (%)
= Approved Transactions ÷ Total Transactions × 100
Using the example above:
880 ÷ 1,000 × 100 = 88%
The gap between 88% (raw) and 94.6% (excluding insufficient funds) shows how much of the loss comes from insufficient‑funds cases, versus other decline reasons.
What counts as an approved transaction
For this metric, each transaction has a derived status.
A transaction is counted as approved when:
It reaches a final “paid” (or equivalent) state, based on the presence of a final approval timestamp.
For card transactions, certain cancelled cases may still be treated as approved if they correspond to flows where the payment was effectively completed and the final cancellation status is only technical.
In practice:
Approved: final “paid” outcome according to the approval‑timestamp logic.
Not approved: final rejected status, or still pending (no final outcome yet).
Only transactions that meet the approved criteria enter the Approved Transactions numerator for both metric versions.
Metric universe: which transactions are included
Before classifying transactions as approved or not approved, the system defines a metric universe:
Included:
Payins payment attempts that:
Belong to the merchant.
Have a valid invoice in the reporting universe.
Fall inside the time window and aggregation dimensions used for reporting.
Excluded:
Test traffic: transactions flagged as test are removed so the metric reflects only real production traffic.
Capture‑only rows: purely technical capture entries are removed from the base filters. They do not count in totals, approvals, or insufficient‑funds counts.
After these rules, every remaining row is a valid transaction attempt and contributes to Total Transactions.
Time window and aggregation
The same logic is used in the Reporting API and Merchant Dashboard:
Each transaction is assigned to a day based on the invoice creation date.
Data is aggregated into one row per merchant, per day, and per combination of:
Payment category
Payment method
Card BIN (for card payments)
Each aggregated row stores:
total_transactions
total_transactions_without_insufficient_funds
approved_transactions
Conversion Rate values are then derived from these counts using the formulas above.
How to use Conversion Rate in practice
Even if the UI you use exposes different filters or charts, the underlying logic is the same. Some practical patterns:
1. Compare available segments
Because the metric is aggregated by payment category, payment method, and card BIN, you can compare Conversion Rate across these dimensions where they are exposed:
Different card brands or local methods.
Card vs. APM categories.
Card BINs (first digits) to spot issuer‑level behavior.
Segments with lower Conversion Rate excluding insufficient funds are good candidates for optimization.
2. Track changes over time
Since data is stored per day, you can track trends before and after:
Checkout UX changes.
Enabling or disabling payment methods.
Risk or fraud‑rule updates.
Use:
Raw Conversion Rate to see the full picture.
Excluding insufficient funds to see the impact of changes inside your control.
3. Reconcile with other tools
If your Conversion Rate differs from another provider or your own BI:
Check how each defines a successful transaction (final “paid” vs. authorization‑based).
Confirm whether test or capture‑only events are included or excluded.
Align which date is used for grouping (creation date vs. other dates).
Once these assumptions match, numbers tend to converge.
FAQs
Why is Conversion Rate excluding insufficient funds usually higher?
Because it removes from the denominator all attempts that failed only due to insufficient funds, while keeping the same number of approved transactions. This highlights performance you can improve (flow, routing, risk, configuration), not customers’ balance issues.
Do pending transactions affect Conversion Rate?
Pending transactions are not counted as approved until they reach a final outcome. While pending, they are part of the universe and Total Transactions; once the status becomes final (paid or rejected), they move to the corresponding group and the metric updates accordingly.
Does Conversion Rate cover all payins?
Yes. Conversion Rate is defined over the payins universe anchored on payments joined to invoices. Any included payins attempt that passes the universe rules is part of Total Transactions, regardless of payment method.
Are test transactions included?
No. Transactions flagged as test are excluded from the metric universe, so Conversion Rate reflects only real production payments.