A monthly payment health review helps a merchant find settlement mismatches, rising declines, fraud signals, refund leakage, webhook failures, and unexpected fees before they become recurring losses. This guide provides a repeatable monitoring checklist, practical formulas, a sample audit for a small e-commerce business, and a simple escalation workflow that can be reused each month or before a major sales period.
Overview
Online payment processing produces several versions of the same commercial event. Your storefront records an order, the payment gateway records an authorization, the processor records a capture or refund, and the bank statement records a settlement. These records do not always arrive at the same time or use the same identifiers. A monthly payments audit brings them together.
The objective is not to inspect every transaction manually. It is to compare expected results with actual results, identify meaningful changes from the previous period, and assign an owner to each exception. A useful review covers eight areas:
- Settlement and accounting reconciliation
- Gateway availability and payment error rates
- Authorization and decline trends
- Chargebacks, fraud signals, and dispute handling
- Refunds, voids, and duplicate-payment leakage
- Currency conversion and cross-border costs
- Webhook delivery and payment API reliability
- Processor, gateway, network, and other third-party fees
Use the same definitions every month. For example, decide whether your approval rate is based on all attempted payments or only technically valid authorizations, and record whether fees are measured per transaction, per settlement, or as a percentage of payment volume. Consistent definitions make trend comparisons more valuable than isolated monthly totals.
For related implementation controls, see the Payment API Integration Checklist and the guide to payment gateways and processors.
How to estimate
Start by creating a monthly control sheet with one row per payment method, currency, legal entity, or processor account. Smaller merchants can begin with one row for cards and another for ACH or alternative methods. Larger operations should separate channels when their settlement timing, fee structure, or risk profile differs.
Use these core calculations:
- Settlement variance: expected net settlement minus actual bank settlement. Expected net settlement is captured sales minus refunds, chargebacks, adjustments, and recorded fees, subject to the processor's settlement rules.
- Gateway error rate: failed technical payment attempts divided by total payment attempts. Exclude ordinary customer declines if the purpose is to measure system reliability.
- Approval rate: approved authorizations divided by valid authorization attempts. Track soft and hard declines separately where the data allows.
- Refund leakage: refunds issued outside the expected policy, duplicate refunds, refunds without a matching order, and refunds sent to an incorrect or unintended payment reference.
- Chargeback rate: chargebacks divided by the transaction population used by your processor or card network reporting. Keep the denominator consistent and label it clearly.
- Effective payment cost: total processing-related fees divided by processed payment volume. Include fixed fees, percentage fees, currency conversion charges, gateway fees, and other relevant deductions.
- Webhook success rate: successfully acknowledged webhook deliveries divided by total deliveries. Also record delayed events, retries, and events rejected because of signature or schema problems.
Set alert thresholds as internal starting points rather than universal industry rules. A practical method is to compare the current month with the previous three months, then investigate any large unexplained movement. You can also define operational limits such as “any non-zero settlement variance after reconciliation,” “any unplanned fee category,” or “any unresolved payment event older than one business day.” A threshold should trigger review, not automatically prove that a provider or customer is at fault.
For a repeatable spreadsheet, create columns for metric, current period, prior period, change, threshold, status, owner, root cause, action, due date, and evidence link. Add formulas for percentage change and variance. Protect formula cells and retain a read-only copy of each completed month.
Inputs and assumptions
Gather source files before calculating results. Typical inputs include the order export, gateway transaction report, processor settlement report, bank statement, refund and chargeback report, fraud-tool output, fee statement, currency report, and application or webhook logs. Record the reporting period and the timezone used by each system; a transaction captured near midnight may appear in different periods across platforms.
Confirm these assumptions before reviewing the numbers:
- Whether the audit uses order date, authorization date, capture date, refund date, or settlement date.
- Which transaction identifier connects the storefront, gateway, processor, and bank records.
- Whether taxes, shipping, tips, discounts, and gift cards are included in payment volume.
- How partial captures, partial refunds, reversals, voids, and asynchronous payment methods are treated.
- Whether fees are shown gross, net of adjustments, or across multiple statements.
- Which currency is used for the management report and how exchange rates are sourced.
- Who owns each exception and where supporting evidence is stored.
Do not place full card numbers or sensitive authentication data in the audit sheet. Use token references, masked identifiers, and access controls appropriate to your environment. Review the PCI DSS compliance checklist when changing data flows, integrations, or reporting access.
Worked examples
Consider a small online merchant with a monthly card volume of 1,200 payment attempts. The payment dashboard shows 1,080 approvals, 72 customer declines, 30 technical failures, and 18 duplicate or retried attempts that were excluded from the approval calculation under the merchant's documented rules. The resulting approval rate is 1,080 divided by 1,170 valid attempts, or approximately 92.3%. The technical error rate is 30 divided by 1,200 attempts, or 2.5%.
The merchant should not treat the 92.3% approval rate as a complete diagnosis. The next step is to group declines by reason and compare them with the prior month. If expired-card declines increased after a subscription renewal change, the remediation may be clearer customer messaging or account-updater configuration. If all decline categories rose at the same time, inspect the gateway, acquirer, 3D Secure flow, routing rules, and incident logs. For implementation considerations, consult the 3D Secure 2 and Strong Customer Authentication guide.
Suppose the same merchant expected a net settlement of 48,420 in its reporting currency but received 47,980. The initial variance is 440. The reconciliation should classify that amount rather than simply mark it as missing. The difference might consist of a 250 fee deduction, a 120 refund processed after the sales export closed, and a 70 currency conversion adjustment. If those items appear in processor records and the bank deposit, the variance is explained. If 100 remains unmatched, it becomes an open exception with an owner and follow-up date.
A compact spreadsheet template can use the following headings:
period,channel,volume,attempts,approved,technical_errors,approval_rate,error_rate,expected_settlement,actual_settlement,variance,refunds,chargebacks,fees,webhook_success_rate,status,owner,action,due_date
One sample row might read:
2026-10,card,48200,1200,1080,30,92.3%,2.5%,48420,47980,440,120,65,250,99.1%,Investigate,Payments Ops,Match fee and FX adjustments,2026-11-05
Use a status such as “Pass,” “Watch,” “Investigate,” or “Escalated.” Attach the settlement report, fee statement, relevant log excerpt, and any provider case number to the row rather than relying on informal messages.
One-page incident escalation flow
- Detect: confirm the alert using raw transaction, settlement, or log data.
- Classify: label the issue as financial, technical, fraud-related, compliance-related, or provider-performance related.
- Contain: pause an affected payment method, route traffic elsewhere, disable a faulty promotion, or hold a risky refund process when authorized by your controls.
- Notify: alert the payments owner, finance owner, customer-support lead, and provider contact according to severity.
- Investigate: identify the first affected event, scope, customer impact, and whether data or funds are at risk.
- Resolve: apply the fix, reconcile financial impact, and communicate customer or accounting actions.
- Close: document root cause, evidence, preventive control, and a due date for verification.
When to recalculate
Run the full audit monthly and a shortened review before peak campaigns, product launches, or major billing runs. Recalculate immediately after changing a payment gateway, processor, payment API, payment method, routing rule, recurring billing logic, fraud tool, or currency configuration. A new integration can alter error categories, settlement timing, identifiers, and fee reporting even when customer-facing checkout appears unchanged.
Refresh thresholds when your transaction mix, geography, average order value, or risk controls change. Revisit the template after provider API changes, updates to PCI DSS or applicable strong customer authentication requirements, material pricing changes, or a new fraud pattern. Keep previous definitions alongside new ones so a trend break is not mistaken for a business improvement.
At the end of each month, complete three actions: close or reassign every open exception, compare the current audit with the prior period, and record one preventive improvement. That routine turns payment monitoring from a retrospective exercise into an operating control for healthier online payment processing.
