Keep the approved capture amount separate from the payment authorisation
A valid payment authorisation does not necessarily tell an integration how much the merchant has approved for capture at the next step. If the software substitutes the authorisation's ceiling for that later instruction, it can request an amount that the business did not intend to collect at that moment.
The fictional example below concerns a merchant account whose inspected test contract supports separate authorisation and capture. It uses euro amounts to make the records easy to compare. It is not a universal description of payment methods, a tax rule or an account-eligibility claim.
Start with three separate records
An order contains items totalling €120. The merchant obtains an authorisation for that amount. A later fulfilment decision approves a partial capture of €84 for the items being supplied in the current step. The remaining commercial work is still being assessed.
The integration receives the approved instruction, but its capture request contains only the payment reference. In the example's provider model, omitting the amount requests the full eligible capturable amount. The isolated result is therefore €120, although the staff instruction was €84.
The investigation must preserve the distinction between the order total, the authorisation and the capture instruction. All three can be valid records while the outgoing operation is wrong.
| Evidence | Recorded value | What it establishes |
|---|---|---|
| Order O-76 | €120 total | The original commercial total |
| Authorisation A-76 | €120 authorised | The inspected payment has that eligible ceiling in the example |
| Approved instruction C-76 | Capture €84 | The amount approved for this operation |
| Outgoing capture request | Amount omitted | The approved amount was not passed to the operation |
| Isolated provider-model result | €120 captured | The omitted parameter triggered the model's documented default |
The problem is not a decimal separator or a major/minor-unit conversion. The approved business value never reaches the request at all.
Inspect the actual provider contract
A real investigation needs current documentation for the operation and evidence from the actual account or authorised test arrangement. It should confirm the eligible state, amount rules, supported payment method and handling of the uncaptured remainder. Those details cannot be inferred from the appearance of the checkout.
For a concrete primary reference, Stripe documents an optional amount_to_capture parameter for PaymentIntent capture and states that omission defaults to the full amount_capturable. Its documentation also distinguishes the remaining-funds behaviour associated with final capture and the availability of multicapture. Those are Stripe-specific details to verify for the implementation and account; the fictional merchant here is not presented as a Stripe customer.
The relevant lesson is to inspect the default rather than assume it matches the merchant's workflow. A technically valid request can still fail to represent the approved instruction.
Carry the instruction into the supported operation
In the corrected example, the integration requires an eligible capture instruction and passes its approved amount explicitly through the provider's supported parameter. The check relates the instruction to the intended payment and order. It also verifies that the amount falls within the limits of this example's account contract.
If the instruction is absent, ambiguous or no longer eligible, the operation is held for review. The integration does not fill the gap with the authorisation amount. Nor does it infer that any remaining balance should be captured later: the disposition of the remainder follows the provider's supported behaviour and a separate authorised business decision.
The staff view distinguishes “capture instructed,” “capture result confirmed” and an uncertain response where appropriate. A timeout cannot safely be translated into “nothing happened” without checking the provider evidence.
Verify the correction with contrasting instructions
The fictional fixture models only the stated contract. It produces these bounded outcomes:
| Test | Approved instruction | Outcome |
|---|---|---|
| Partial fulfilment | Capture €84 against eligible €120 | Explicit €84 request; €84 result recorded |
| Deliberate full capture | Capture €120 against eligible €120 | Explicit €120 request; full result recorded |
| Excess instruction | Capture €125 against eligible €120 | Blocked before the modelled capture call |
| Missing instruction | No approved amount | Held for staff review; no default amount supplied |
The full-capture control matters. The correction is not a blanket rule that every order must be captured partially. It preserves the amount the authorised person actually approved. The excess test reflects this account's stated limits, without claiming that no provider offers any other separately supported capability.
Reconcile a historical error separately
If an incorrect capture has already occurred in a real system, changing future requests does not resolve the historical record. An authorised person must compare order, provider and customer-facing evidence and decide the appropriate handling through the supported process.
Do not silently rewrite the capture history or assume a refund is automatically authorised. A refund, an order adjustment and a required accounting document may be separate operations with different responsibilities. The customer communication must describe the actual decision and result.
Review the surrounding purchase journey
The form and order summary should preserve the approved product, quantity and currency. Customer-facing wording should distinguish the known payment state from fulfilment or delivery. Staff need enough context to investigate without relying solely on a browser success page.
For Italy-facing commerce, the merchant and qualified advisers determine the applicable price, tax, document and customer-condition requirements. The software implements those approved rules; the example does not provide an accounting conclusion about the remaining €36.
Consult the current Stripe capture reference as one provider-specific illustration. The online store service explains the wider order journey, and support guidance describes the evidence useful when a result is uncertain.