Payment approval percentage measures how many attempted orders clear issuer authorization and merchant approval. Capture rate measures how many approved payments are actually settled. Approval percentage is therefore a decisioning metric, while capture rate is a settlement metric, and they can diverge when routing, review, or post-approval processing fails.
How approval percentage and capture rate differ in the payment lifecycle
These metrics sit at different points in the payment flow. Approval percentage is about authorisation success at the front of the transaction, while capture rate is about whether an already approved payment is actually completed downstream. That distinction matters because a high approval rate can still produce weak realised revenue if capture breaks after approval.
For operators, the practical question is not just whether the issuer said yes, but whether the merchant successfully turned that yes into a settled transaction. The two metrics therefore diagnose different failure points, and you should not treat them as interchangeable proxies for checkout health.
Why the gap between approval and capture appears
The gap usually comes from post-approval friction rather than initial payment decisioning. Common causes include delayed or failed capture jobs, order-management mismatches, expired authorisations, partial fulfilment logic, retry failures, or integration defects between the commerce stack and the payment gateway. A checkout can look healthy on the approval side while still leaking revenue later in the process.
Because capture depends on downstream processing, it is especially sensitive to orchestration reliability. If the authorisation window closes before capture is submitted, or if business rules prevent capture from being triggered, the payment may never settle even though the original payment decision was successful.
How to read the metrics together
Use approval percentage to judge issuer response quality, fraud filtering, route selection, and the effectiveness of the initial payment request. Use capture rate to judge whether operational execution, settlement workflows, and payment lifecycle controls are functioning. When approval is strong but capture is weak, the issue is rarely card acceptance, it is usually a process, timing, or system integration problem.
For payment teams, the most useful comparison is to segment both metrics by payment method, issuer, region, gateway, and fulfilment path. That makes it easier to see whether the loss is concentrated in one route, one processor, or one post-approval workflow.
Risk and Threat Considerations
When approval and capture diverge, the business risk is usually hidden revenue loss, false confidence in checkout performance, and weaker operational visibility. In payment environments, missed captures can also create reconciliation errors, duplicate recovery work, and disputes about whether an order was really completed.
Failure mechanism: The authorisation succeeds, but the later capture step fails because of expired holds, workflow breakage, message loss, or a downstream system that never submits the capture request.
Impact: Approved orders fail to settle, revenue is deferred or lost, and teams may misdiagnose the problem if they only watch approval percentage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | Payment capture depends on a protected business flow completing correctly. |
| Recommendation — Protect capture endpoints and workflow steps from bypass or misuse. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Failed capture often stems from integration or workflow defects needing operational control. |
| Recommendation — Monitor payment integrations for defects that block authorized captures. | ||
| NIST CSF 2.0 | PR.AA-05 — Least privilege | Payment systems need constrained access to capture and settlement actions. |
| Recommendation — Restrict capture actions to approved payment services and roles. | ||
Practitioner Guidance
What to verify: Reconcile approval and capture by payment method and by lifecycle stage, then check whether the capture failure is systemic or isolated to one processor, queue, or order state. If the approval rate is stable but capture drops, treat it as an operational defect, not a payment acceptance issue.
What good looks like: The approval percentage and capture rate should track closely enough that any gap is explainable by known business rules such as delayed fulfilment or intentional delayed capture. A widening unexplained gap is the clearest signal that the payment lifecycle has broken somewhere after authorisation.
Practitioner takeaway: Approval tells you whether the payment was accepted; capture tells you whether the business actually got paid. Track them separately, then investigate the handoff between them whenever realised revenue falls below expectation.
Related resources from NHI Mgmt Group
- What is the difference between payment fraud attack rate and fraudulent chargeback rate?
- What is the difference between OAuth consent and access approval?
- What is the difference between access approval and access control evidence?
- What is the difference between AI app approval and AI identity governance?