When a customer sees “payment approved,” it is natural to assume the entire financial process ended at that moment. In payment infrastructure, however, approval may represent just one stage in a larger cycle.
A transaction may have been created, submitted for processing, authorized, captured, confirmed as paid, canceled, refunded, or disputed. Some of these changes happen during the initial request. Others occur seconds, hours, or days later.
Understanding this lifecycle is about more than terminology. The model determines when an order can be released, when a reservation can be confirmed, when an authorization can still be canceled, when a refund must be initiated, and how the system should respond to timeouts, delayed webhooks, and conflicting responses.
A robust payment integration should therefore ask more than whether the payment “worked.” The more useful question is: what financial state is this transaction in now, which facts are already known, and which transitions remain possible?
What is the lifecycle of a payment transaction?
A payment lifecycle is the sequence of states and operations that a charging intent passes through, from its creation to a final financial outcome or a situation requiring further handling.
In a card flow with separate authorization and capture, for example, we can think conceptually in terms of creation, processing, authorization, and capture. After capture, asynchronous confirmation, settlement, refunds, disputes, or chargebacks may still occur.
This is not a universal API vocabulary. Different PSPs, acquirers, networks, and platforms use different objects, names, and statuses. Even within one platform, different payment methods may follow different paths.
What matters architecturally is the business transitions these states represent. An authorization is not the same as a capture. A capture is not the same as settlement. Canceling an authorization before capture is not necessarily the same operation as returning funds after a charge.
This distinction may seem purely semantic until the first production incident.
What does authorizing a payment mean?
Authorization is the stage at which the infrastructure checks whether a payment attempt can proceed under the rules of the issuer, network, acquirer, and other participants involved.
For cards, an approved authorization normally indicates that the issuer accepted the transaction and that a financial commitment is associated with that amount. In many flows, this involves a temporary hold on available credit or funds, but it does not necessarily mean the charge has been completed for the merchant.
When authorization and capture are separate, there is an interval between “the transaction was authorized” and “we now want to complete the charge.” This design is useful when commercial confirmation still depends on a later event.
Hotels may authorize before checkout. Car rental companies may need to hold an amount before knowing the final cost. Marketplaces may wait for inventory or shipment confirmation. Presale operations may want to capture only when the order is ready to move forward.
The main point is that authorization is a decision about whether a transaction can proceed. It should not automatically be confused with the end of the financial lifecycle.
Does an approved authorization mean the sale is complete?
Not necessarily.
This is one of the most common modeling mistakes. With automatic capture, authorization and capture may happen so close together that they appear to be a single action to both the application and the user.
With manual capture, however, the difference becomes explicit. The system may know that the transaction was authorized but still need to decide whether to capture it.
If the merchant permanently releases a product solely because authorization succeeded, but capture never occurs, the order's commercial state may no longer match the payment's financial state.
For this reason, mature systems tend to separate at least three concepts: the customer's order, the payment intent, and the state of the attempt used to execute that intent.
Combining everything into a single Boolean field such as “paid = yes or no” works while the flow is simple. As manual capture, multiple PSPs, retries, webhooks, and refunds enter the picture, the model begins to lose important information.
What is capture?
Capture is the operation that confirms a previously authorized amount should proceed to charging under the flow supported by that provider and payment method.
Conceptually, authorization answers something like “can this transaction proceed?” Capture answers “we want to complete the authorized charge.”
In many integrations, capture is automatic. The application submits the payment, and the provider performs authorization and capture as closely connected parts of the same flow.
In others, capture is manual. This allows the merchant to wait for a business event before completing the charge.
Partial capture may also be available, depending on the provider's capabilities. Imagine a reservation authorized for R$ 1,000 whose final amount is R$ 840. If the flow allows partial capture, the merchant can charge only the amount due instead of charging the full amount and refunding the difference.
This behavior should not, however, be assumed to be identical across integrations. Some providers support partial capture, others have specific rules, and others handle the remaining amount differently.
That is why a payment layer should not pretend that all processors work in exactly the same way.
Is capture the same as settlement?
No.
Capture and settlement are related stages, but they are not synonyms.
Capturing means confirming that the authorized amount should proceed as a charge. Settlement is a later financial stage in which ecosystem participants process the movement of funds according to the payment method's rules, timelines, and arrangements.
From the user's perspective, these stages may seem like a single event. For reconciliation and financial operations, they are not.
A company may have a correctly captured payment in its transaction system and still need to confirm later whether the corresponding financial movement appeared as expected in settlement.
This difference helps explain why “payment state” and “state of the funds” should not be treated as exactly the same concepts.
What does canceling a transaction mean?
The answer depends on where it is in its lifecycle.
When an authorization has not yet been captured, cancellation normally means stopping that authorization before the charge is completed. Conceptually, the system is abandoning an operation that should not move forward financially.
After capture, the problem changes. A charge has already been completed or reached a later stage, and returning funds becomes a refund flow rather than simply canceling the original authorization.
This boundary matters because two actions that may look identical to the end user represent different infrastructure operations.
The user may say, “I want to cancel the purchase.” The system must determine its current financial state to choose the correct action.
If the authorization is still open, the action may be to cancel or void it. If the charge has already been captured, a refund may be necessary. If the result is still unknown because of a timeout, a premature action may increase the risk of duplication or inconsistency.
Are cancellation and reversal the same thing?
It depends on the terminology being used.
In everyday Brazilian usage, “estorno” can refer to several situations: an authorization that disappeared, a canceled purchase, a refund, or even a specific acquirer reversal.
For product and customer support, that general term may be sufficient. For a payment state machine, it is not.
A robust architecture must turn ambiguous terms into precise operations. The question changes from “was the payment reversed?” to “was the authorization canceled before capture, was the captured charge refunded, or did another type of reversal occur?”
This precision improves code, support, observability, and reconciliation.
It also helps prevent two teams from using the same word for different financial operations and building incompatible integrations.
What is a refund?
A refund is an operation initiated when an eligible charge exists from which some or all of the amount can be returned to the payer.
Unlike cancellation of an uncaptured authorization, the system is dealing here with a transaction that has already advanced through the financial lifecycle.
A refund also has its own lifecycle. Requesting a refund does not necessarily mean the entire process ends at that instant.
The operation may be accepted for processing and completed asynchronously. A partial refund may be possible. A failure may occur. A webhook or subsequent status check may be needed.
The application should therefore not immediately change its local state to “refunded” merely because it sent a request, unless the provider's contract guarantees that the response already represents the final outcome.
The local state must represent what the system actually knows, not what it expects to happen.
Does a partial refund change the payment's state?
It can, and this is another reason to move beyond Boolean models.
Imagine a R$ 1,000 purchase. The customer returns an item and receives R$ 200 back. The charge is no longer intact, but it has not been fully refunded either.
If the system recognizes only “paid” and “refunded,” it must choose an incomplete representation.
Richer financial models can represent a payment that was completed and later partially refunded. An implementation may use a specific state, keep refunds as separate entities, or combine both approaches.
The principle matters more than the name: the captured amount, the amount already returned, and the amount still available to refund are different pieces of information.
This distinction also supports reconciliation, customer service, and prevention of refunds exceeding the amount actually eligible.
Why aren't paid, canceled, and refunded enough?
Because payment systems also need to represent what has not yet been completed.
A request may be pending. An authorization may have been approved but not yet captured. A capture may be processing. A refund may have been requested but not confirmed. A dispute may begin long after a charge appeared to be finalized.
An attempt may also temporarily have an unknown state because the provider processed the request but the application lost the response.
Modeling only final states forces the system to guess.
Modeling intermediate states allows it to wait, reconcile, and respond to the next piece of evidence.
In payments, “I don't know yet” may be a much safer operational state than “failed.”
What happens when there is a timeout?
A timeout is one of the best tests of whether a platform's state model is truly robust.
Imagine the application sends an authorization. The PSP receives the request. The acquirer processes it. The authorization is approved. But the connection between the PSP and the application drops before the response arrives.
Financially, the authorization may exist. From the application's perspective, there was a timeout.
If the system automatically translates a timeout into a declined payment, it is asserting something it does not know.
If it immediately sends another charge, it could create a second authorization or financial effect.
The problem is not just retrying. It is a state question: what do we actually know about the transaction at that moment?
A safer architecture preserves that ambiguity until it can resolve it through available mechanisms, such as a status query, idempotency, a webhook, reconciliation, or a combination of them.
Why are webhooks part of the lifecycle?
Because a payment's lifecycle does not necessarily fit within a single HTTP connection.
Some changes happen after the original response. Capture, refunds, reviews, asynchronous payment-method confirmations, disputes, and other events can produce later updates.
Webhooks allow the application to receive these changes without continuously polling the provider.
But this introduces another challenge: events may arrive late, more than once, or out of order.
Receiving one webhook after another does not mean it represents a newer state. An old event may be retried and arrive after a more recent update.
Arrival order must therefore not be confused with business-event order.
The application must check whether the received transition makes sense given the current state and, when necessary, consult the source of truth before moving a financial object backward.
What is a valid state transition?
A valid transition is a change that makes sense given the current state and the rules of that operation.
A charge awaiting capture may allow certain actions. After capture, the set of possible operations changes. After a full refund, trying to capture that same authorization again probably makes no sense.
The state model provides a way to limit impossible or dangerous combinations.
It also reduces dependence on the interface. Whether an action came from an API, admin dashboard, webhook, automation, or AI agent, the domain must still answer the same question: is this operation valid for this object in its current state?
When that rule exists only in the interface, adding a second channel is enough for the system to start accepting inconsistent situations.
Why not copy PSP statuses directly into your business model?
Because an external status belongs to the provider's model.
Your system has its own domain.
One PSP might call a state authorized. Another might use approved. A third might combine authorization and capture into a single result for a particular method. Others might have specific states for review, asynchronous confirmation, or settlement.
A multi-PSP application that spreads all these statuses directly throughout its code forces orders, subscriptions, support, reconciliation, and other internal systems to learn each integration's vocabulary.
One alternative is to normalize external events into your own concepts.
The aim is not to erase differences between providers. It is to keep integration-specific details from leaking throughout the architecture.
If a capability genuinely changes financial behavior, it must remain explicit. A good abstraction simplifies what can be simplified and preserves what cannot be treated as equivalent.
Should a payment and a payment attempt be the same entity?
In simple operations, that may seem sufficient.
In more advanced architectures, separating the two concepts can be extremely useful.
The payment represents the commercial intent. An attempt represents a concrete effort to execute that intent through a particular route, processor, or credential.
Imagine a R$ 500 purchase. The first attempt encounters a timeout at PSP A. After investigating, the infrastructure determines that another attempt is safe. The second goes through PSP B.
If both are treated simply as “the payment,” it becomes difficult to identify which provider received which request, which authorization belongs to which attempt, and which asynchronous event is updating which operation.
This separation is fundamental to failover, Smart Routing, and observability.
It allows the commercial intent to remain unique while the system tracks distinct technical events related to it.
Should an order follow the same state as its payment?
Not necessarily.
Orders and payments are related but different domains.
An order may be awaiting stock while its payment is authorized. It may be ready to ship while capture is still processing. It may be canceled commercially and, as a consequence, trigger the financial operation appropriate to the payment's current state.
The architectural mistake occurs when a single field tries to represent both worlds.
An order status such as “paid” may be convenient initially, but it mixes fulfillment and finance.
Better modeling allows each domain to maintain its own truth and respond to relevant events from the other.
Payments report that a particular financial stage has occurred. Orders decide what that means for stock, dispatch, access, or service delivery.
Orders report that a sale has been canceled. Payments decide whether the correct action is to cancel an authorization, initiate a refund, or do nothing.
When should I release the product or service?
The answer depends on the business model and payment method.
There is no universal rule stating that every product must be released upon authorization, capture, or final confirmation.
A hotel, marketplace, SaaS business, digital-product store, and physical-goods e-commerce business have different risks and fulfillment milestones.
What matters is making the policy explicit.
The team must know which financial event is sufficient for each commercial action. Without that definition, different systems may make different decisions for the same state depending on which service received the event first.
A payment state machine does not replace business rules. It provides a reliable basis for those rules to make decisions.
What should be observed at each transition?
Storing only the current status is not enough.
To investigate payments, it is useful to reconstruct how they reached that state.
This may include the time of the change, related attempt, route, PSP, requested operation, normalized result, correlation identifiers, and the event that justified the transition.
This does not mean indiscriminately logging sensitive payloads. It means keeping enough operational evidence to answer questions without turning observability into a data leak.
When the team asks, “why is this payment in this state?”, the answer should not depend on opening several external dashboards and manually reconstructing the history.
This is the connection between state machines and observability.
How should you approach a payment state machine?
Start with the domain, not with how many statuses a PSP offers.
Ask which financial facts the application genuinely needs to distinguish.
Is there only a created intent, or is an attempt already processing? Is there a valid authorization? Has capture been requested? Has capture been confirmed? Was an authorization canceled before capture? Has a refund been requested? Was the refund completed fully or partially? Is there a subsequent dispute? Is any result still unknown?
Then define which transitions make sense between those situations.
Only then map each external integration's vocabulary to the internal model.
This order avoids building the application's financial core around the peculiarities of the first PSP integrated.
It also reduces the cost of adding providers later, because most of the business already works with a stable model.
Do all payment methods follow the same lifecycle?
No.
The authorization-and-capture model is particularly clear with cards, but it should not be designed as though every payment method were a card in disguise.
Pix, boleto, debit, wallets, transfers, and local methods have different lifecycles, confirmations, expiration rules, and capabilities.
Some have no equivalent to authorization separate from capture. Some normally rely on asynchronous confirmation. Some permit certain types of returns, while others follow different rules.
A payment abstraction therefore needs to separate shared concepts from method-specific capabilities.
The domain can share ideas such as intent, attempt, success, failure, return of funds, and events, but it should not force nonexistent operations onto a method merely to keep the API visually uniform.
A consistent interface is useful. An interface that hides relevant financial differences is dangerous.
Why does this model matter in a multi-PSP architecture?
Because multiple providers amplify every ambiguity.
There is no longer just one set of statuses; there are several. There is no longer just one timeout policy; there are several. There is no longer just one webhook; there are different formats, codes, and event orders.
An orchestration layer's job is not simply to choose PSP A or PSP B.
It must also know which operation is being executed, which attempt is being modified, which state has already been reached, and what actions remain permissible.
Stateless routing can choose a route.
Stateful routing can prevent a technically valid decision from causing an incorrect financial outcome.
This is an important distinction between connecting several providers and actually operating payments as infrastructure.
How do authorization, capture, and refunds relate to idempotency?
Each of these operations can have financial effects.
That means retries must be controlled.
If a request times out, blindly repeating it may be unsafe. Idempotency associates repeated requests with the same intent when the provider offers that mechanism.
But an idempotency key does not resolve the entire lifecycle.
Responses, webhooks, attempts, and state changes must also be correlated.
Idempotency prevents certain duplicate effects. The state machine helps determine whether an operation should still occur.
The two mechanisms complement each other.
A resilient architecture needs both repetition control and an understanding of the current financial state.
The most dangerous mistake is confusing no response with a negative response
An explicit decline contains information.
A timeout indicates a lack of sufficient information.
These situations should not automatically produce the same transition.
If the issuer declined the authorization, there is a known result. If the network stopped responding midway through the request, the system may not yet know whether the operation was processed.
Turning both into “failed” removes a distinction that may be essential to preventing duplication.
In distributed systems, intermediate states are not a weakness in the model. They represent reality more faithfully.
How does this lifecycle appear in a payment platform?
A payment platform must translate external operations into a consistent domain without pretending that all providers are the same.
At AZPay, authorization, capture, cancellation, refunds, and asynchronous updates are treated as distinct parts of a charge's lifecycle. Manual capture is a specific operation on a previously authorized charge, and subsequent state changes can be tracked through the API and webhooks.
This design matters in infrastructure integrating multiple providers, because each connector may represent external responses differently while the rest of the platform needs a consistent operational language.
The abstraction does not eliminate each acquirer's or PSP's particularities. It creates a controlled point at which to translate them.
What does an architecture gain by modeling the lifecycle correctly?
First, operational safety. Operations incompatible with the current state can be blocked before reaching the provider.
Second, support. The team can explain what happened without manually translating dozens of external codes.
Third, observability. Metrics can be organized by lifecycle stage, such as authorization, capture, refunds, latency, and technical failures.
Fourth, resilience. Timeouts and late events no longer require rushed decisions.
Fifth, portability. Adding another PSP does not force the whole application to learn a new financial language.
Finally, automation. The more decisions systems, rules, or agents execute, the more important explicit states and controlled transitions become.
Automating a poorly modeled flow simply makes errors happen faster.
What is the difference between authorization, capture, cancellation, and refunds?
Authorization checks whether the operation can proceed and, in supported card flows, establishes the commitment needed for a later capture.
Capture confirms that an authorized amount should proceed to charging.
Cancellation before capture stops an authorization or charge that has not yet completed the expected financial effect.
A refund returns some or all of the amount of a charge that has already advanced through the lifecycle.
The Brazilian term “estorno” should be used carefully because, in everyday usage, it can represent more than one of these operations.
Settlement comes later and concerns the movement of funds between ecosystem participants. It relates to the payment but is not synonymous with authorization or capture.
This distinction is small in vocabulary and enormous in architecture.
A payment's state is part of the infrastructure
A payment system's job does not end when it can send a request to an acquirer.
It must know what it sent, what happened, what may still happen, and which operations remain valid.
That is what turns an integration into infrastructure.
When states are modeled well, authorization, capture, cancellation, and refunds stop being isolated endpoints and form a coherent lifecycle.
Webhooks stop being arbitrary updates and represent transitions.
Failover stops meaning only “try another PSP” and respects what has already happened.
Observability stops showing only requests and starts showing the transaction's financial history.
And the application stops asking simply whether a payment “worked.”
It knows where the payment is, how it got there, and what may happen next.