A sale does not always end with the same amount it started with.
Hotels may authorize an estimated amount and capture a different one. E-commerce businesses may ship items on different dates and want to capture payment per shipment. Mobility services may know the final price only after the ride. Marketplaces may need to divide a transaction into stages. In some scenarios, the issuer may approve only part of the requested amount.
This is where three concepts arise that seem similar but address different problems: partial authorization, partial capture, and multiple captures.
Confusing these operations leads to balance, fulfillment, reconciliation, and customer experience errors. A robust architecture must know exactly which amount was requested, which was authorized, how much has already been captured, and how much can still be captured.
What is partial authorization?
Partial authorization occurs when a transaction requests a certain amount but the issuer approves only part of it.
Imagine a R$ 300 purchase in a context that supports partial authorization. The credential has only R$ 220 available, and the issuer authorizes that amount.
The merchant must then decide what to do about the remaining R$ 80.
It can request another payment method, cancel the transaction, or follow a specific business policy.
Is partial authorization common in every checkout?
No.
Support depends on the card network, issuer, acquirer, PSP, product, and configuration.
An integration should not assume that any authorization may return a partial amount.
When this feature is used, the application needs a UX and state machine that are ready for it.
What is the difference between partial authorization and partial capture?
With partial authorization, the amount approved by the issuer is lower than the amount requested.
With partial capture, an amount has been authorized and the merchant decides to capture only part of it.
These decisions happen at different points in the lifecycle and are made by different participants.
What is partial capture?
Partial capture means capturing less than the total amount previously authorized, when the payment method and provider support this behavior.
If R$ 1,000 was authorized and the final amount is R$ 840, the merchant can capture R$ 840 instead of charging R$ 1,000 and then returning R$ 160.
This reduces unnecessary movements and better represents the amount actually owed.
What happens to the uncaptured amount?
It depends on the capture type and provider.
In some single partial capture models, the uncaptured portion is released or canceled after the partial capture.
In multiple partial capture models, the remaining balance stays available for subsequent captures under the applicable rules.
The integration must make this distinction explicit.
What are multiple captures?
They are several capture operations associated with the same authorization or authorized context, when the provider and payment scheme allow them.
A R$ 1,000 order might have R$ 600 captured when the first shipment leaves and R$ 400 when the second is sent.
The initial authorization remains the financial reference for the captures.
Why does e-commerce use multiple captures?
Because fulfillment can be split.
If an order contains three items shipped at different times, charging for each shipment when it actually leaves can better reflect the commercial process.
This also avoids capturing payment for a product that is not yet available.
Can partial authorization and multiple captures coexist?
In theory, a complex flow can involve both, but availability depends on the specific capabilities of the provider and payment scheme.
The architecture should not assume they can always be combined.
Each capability must be identified and handled explicitly.
What is preauthorization?
Preauthorization is a type of authorization used when the final amount may change or capture will happen later.
It is common in hospitality, rentals, and mobility services.
The goal is to secure an initial commitment without stating that this is necessarily the final amount.
Is preauthorization the same as a standard authorization?
The basic concept is still authorization, but some payment schemes and providers distinguish authorization types to properly support adjustments and later captures.
The integration must follow the processor's semantics.
It is not safe to treat every authorization as indefinitely adjustable.
What is an authorization adjustment?
It is a change to the authorized amount before final capture, when the flow supports it.
A hotel may authorize an estimated amount and later increase or decrease it based on the stay and additional spending.
This adjustment is not the same as creating a new, independent charge.
Can I capture more than was authorized?
Generally, not without a specific adjustment, reauthorization, or additional operation allowed by the provider.
Attempting to capture more than the authorized balance will generally fail.
The application needs to know the remaining authorized amount.
What is the remaining authorized balance?
It is the portion of the authorized amount that has not yet been captured or canceled within that flow.
If R$ 1,000 was authorized and R$ 600 captured, R$ 400 may remain available for later capture when multiple partial captures are supported.
This balance is different from the customer's bank balance.
How should amounts be modeled in the payment?
Storing only amount is not enough.
It is useful to distinguish requested_amount, authorized_amount, captured_amount, refunded_amount, and remaining_capturable_amount.
The names may vary, but the concepts must exist.
Why should captured_amount not replace amount?
Because you lose the original intent.
If a purchase requested R$ 1,000 and captured R$ 840, both facts matter.
The difference may explain a partial cancellation, an adjustment, or incomplete fulfillment.
How do refunds interact with partial capture?
A refund can only return an amount that actually progressed to a charge under the applicable flow.
If R$ 1,000 was authorized and only R$ 600 captured, it makes no sense to treat the uncaptured R$ 400 as a refund.
It belongs to the authorization's uncaptured balance.
Are authorization cancellation and refund different here?
Yes.
Canceling an amount that has not yet been captured releases or ends the authorization commitment.
A refund returns an amount already charged.
Mixing the two causes financial confusion.
How do hotels use this model?
At check-in, a hotel can obtain an estimated authorization.
During the stay, it can adjust the amount under the provider's rules.
At checkout, it captures the final amount owed and releases any difference.
This model removes the need to know the exact amount in advance.
How do rental companies use it?
Rental companies may authorize an amount that includes the daily rate, deposit, and possible extras.
They then capture the final cost.
The transaction must comply with extended authorization and adjustment rules where applicable.
How do mobility services use it?
A ride may begin without an exact final price.
The platform can preauthorize an estimate and capture later.
If the amount changes significantly, the authorization may need to be adjusted or the difference handled according to the PSP's capabilities.
How does a marketplace use multiple captures?
A marketplace order may involve different sellers or shipments.
Capturing on each fulfillment event can align charging with what has been delivered.
However, splitting funds between sellers is a separate problem and should not be confused with partial capture.
Is partial capture a split payment?
No.
Partial capture determines how much of an authorization will be charged.
A split determines how the captured amount is distributed among participants.
A transaction can use both features, but they answer different questions.
Are multiple captures multiple charges?
From the authorization lifecycle perspective, they are captures linked to the same context.
How they appear to the consumer may vary by issuer and payment scheme.
The application should not model them as independent payments if the provider treats them as modifications to the same authorization.
How do you reconcile multiple captures?
Each capture needs its own identity.
The system must preserve the amount, timestamp, external reference, and link to the original authorization.
The sum of the captures cannot exceed the permitted amount.
At settlement, each capture may produce movements that need to be reconciled.
How do you identify each capture?
Use a unique internal reference for the capture intent and preserve the PSP reference returned by the operation.
This makes retries, webhooks, and reconciliation easier.
Does capture need to be idempotent?
Yes.
If a capture times out, repeating it with a new identity may create a second capture when multiple captures are allowed.
Each capture intent should have a stable key.
Why do multiple captures increase the risk of duplication?
Because the system accepts multiple legitimate captures.
A provider cannot simply reject a “second capture” as a duplicate.
The platform needs to know whether the second operation is a legitimate new portion or a retry of the first.
Idempotency by capture_id resolves this ambiguity.
How do webhooks work in this scenario?
Each capture can generate its own event.
Events may arrive out of order or be resent.
The application must update the correct capture and recalculate the payment aggregate without moving its state backward.
Should the payment have a “partially_captured” state?
It can be useful.
If an amount is authorized and only part has been captured, a state or attribute representing that helps prevent inconsistent operations.
Another approach is to derive the state from the amounts.
What matters is that the platform can distinguish zero, partial, and full capture.
What about “partially_authorized”?
If the integration supports partial authorization, it may also need to represent that authorized_amount is lower than requested_amount.
The UX needs to act on the difference.
What should happen to the remaining amount after a partial authorization?
It depends on the customer journey.
The business can request another method to complete the total, reduce the order, or cancel the partial authorization.
It should not release a R$ 300 sale as fully paid if only R$ 220 was authorized, unless its commercial policy explicitly allows that.
What is split tender?
It means using more than one payment method to complete a purchase.
Partial authorization can be part of a split tender journey: one credential covers part of the amount, and another covers the rest.
This requires an order state machine capable of adding together multiple payments.
How do you avoid releasing an order too early?
Define the fulfillment condition in terms of the required captured or confirmed amount.
If the order requires R$ 300 and only R$ 220 has been partially authorized, it is not yet fully paid.
The order must track its total financial coverage.
How do you handle a capture larger than the final amount?
Where possible, adjust or capture only the amount owed before charging.
Overcharging and then refunding creates more movements, a worse experience, and complexity.
Partial capture exists specifically to avoid this pattern where supported.
What about tips?
Some industries authorize a base amount and add a tip or later adjustment under specific rules.
This is not universal.
The integration must use the mechanisms provided by the scheme and provider.
How should currency be handled?
Capture generally needs to use the authorization currency.
Trying to capture in a different currency may fail.
Foreign exchange should be handled in its own layer, not as a simple change to the capture amount.
Can capture expire?
Authorizations have validity windows.
The exact period varies by payment scheme, authorization type, and provider.
The application should not hard-code a universal seven-day rule or any single number without checking the specific contract.
What happens when the authorization expires?
Capture may no longer be possible and may require a new authorization.
That is why delayed fulfillment needs to account for authorization validity.
Shipping a product weeks later while relying on an old authorization can lead to a loss.
Can I reauthorize?
Some flows allow an authorization to be renewed or adjusted; others require a new attempt.
The solution depends on the provider.
The domain model should treat reauthorization as an explicit event, not an invisible process.
How do partial captures affect approval rates?
They do not necessarily change the initial authorization, but they can reduce operational failures when the final amount is lower than the estimate.
On the other hand, multiple modifications may have their own rules and risks.
Optimization needs to consider the entire lifecycle.
How do partial captures affect the customer?
The customer may see pending and charged amounts at different times.
Clear communication matters, especially in hospitality and rentals.
The experience should explain that an authorization is not necessarily the final debit.
Why does support need to understand the difference?
Because customers often ask why they saw R$ 1,000 held and R$ 840 charged.
If support calls everything a “charge,” it creates confusion.
The dashboard should display authorizations, captures, and releases separately.
How does a ledger represent partial capture?
The authorization may exist outside the financial ledger or in a reserve account, depending on the model.
Each capture generates its own movements for the amount actually charged.
The captured total is the sum of the associated journals.
How do multiple refunds relate to this?
A capture may receive subsequent partial refunds.
The platform needs to know how much of the total captured amount remains eligible for refund.
In more detailed systems, a refund may reference a specific capture.
How do chargebacks relate to this?
Disputes can involve captured amounts.
Multiple captures may generate distinct references that must be preserved for reconciliation and evidence.
This reinforces the need for an identity for each operation.
How should a capture API be modeled?
The API should accept the originating payment or authorization, the amount, and an idempotency key.
The response should return a distinct capture_id and state.
The resource must be retrievable afterward.
Does capture_id need to differ from payment_id?
Yes, especially when multiple captures are allowed.
One payment may have several capture operations.
Using only payment_id makes it difficult to distinguish retries from new captures.
How should an accepted but not yet final capture request be handled?
Model an intermediate state.
An API may accept the request and confirm the outcome later through a webhook.
“Request received” should not automatically be treated as settled money.
Can a capture fail after being accepted?
Depending on the provider and payment scheme, yes.
Some platforms document that a request initially accepted can still fail later.
The application must monitor asynchronous events and avoid assuming completion too early.
What should you do when a capture fails?
Preserve the authorization and check whether there is still a capturable balance and whether retry is allowed.
Do not create a new charge without understanding the state.
The policy depends on the reason for the failure.
How do you avoid overcapture?
Use invariants.
The sum of completed captures and those in states that reserve funds must not exceed the authorization limit defined by the provider.
The database can help with locks and transactions to prevent a race between two simultaneous captures.
Can a race condition occur?
Yes.
Two workers may each try to capture R$ 300 from a remaining balance of R$ 400.
If both read the balance before either update, they may submit R$ 600 to the PSP.
The application needs to serialize operations or reserve the amount atomically.
How do you reserve funds for a capture in progress?
One approach is to include pending captures in the remaining_capturable_amount formula.
That makes the amount temporarily unavailable to another operation until the first is resolved.
If it fails, the reservation is released.
How do you handle a capture timeout?
The capture enters an unknown state, and the amount must remain reserved until reconciliation.
Immediately releasing the balance and creating another capture can cause duplication.
How do multiple captures affect Smart Routing?
Generally, a capture must follow the original authorization context.
It is not a new, arbitrary routing decision between acquirers.
The authorization and capture belong to the same processing relationship.
Can I authorize with one PSP and capture with another?
Not as a continuation of the same standard authorization.
Each PSP has its own reference and relationship with the acquirer.
Changing routes usually means a new attempt, not capturing the previous authorization.
How does this affect portability?
An open authorization creates temporary lock-in to that route.
While a capturable amount remains, related operations need to use the original provider.
This should be considered in multi-PSP architectures.
Which metrics should you track?
Full versus partial authorization, authorized amount, capture rate, partial capture, capture failure, time to capture, expired balance, and amount discrepancies.
With multiple captures, track the average number of captures per payment and the incidence of blocked overcaptures.
How should you test?
Test zero, partial, and full capture, two concurrent captures, timeout, idempotent retry, expired authorization, refund after partial capture, and out-of-order events.
Also test a PSP that supports only single partial capture.
How should provider capabilities be documented?
Maintain an explicit matrix.
Which methods support manual capture? Partial capture? Multiple captures? Authorization adjustment? What is the window? Are there network-specific rules?
Do not scatter implicit if statements throughout the code.
How do you normalize without hiding differences?
The platform can offer common concepts such as authorization, capture, and remaining amount.
When a PSP does not support multiple captures, the capability should return false and the API should block the operation.
A good abstraction does not promise a feature that does not exist.
What is the difference between partial authorization, partial capture, and multiple captures?
Partial authorization is when the issuer approves less than the requested amount.
Partial capture is when the merchant decides to charge less than the authorized amount.
Multiple captures allow the authorized amount to be divided into more than one capture operation.
These are three distinct capabilities.
Changing amounts require an explicit domain model
When requested, authorized, and captured amounts can differ, the system needs to stop treating amount as a single number.
The architecture must preserve every amount, operation, and reference.
This improves fulfillment, support, reconciliation, refunds, and risk management.
What looks like an API nuance is actually an important change to the product's financial model.