A card payment is not a single event. It is a short sequence of steps that starts when a cardholder submits payment and finishes, usually hours later, when the money moves. Most support questions come down to knowing which step a payment is on, because that is what decides which action you can take on it.

This guide walks that sequence in operator terms, explains the difference between the four ways to cancel or return a payment, and covers how settlement batches work.

The journey of a card payment

Every transaction in WinkPG moves forward through a fixed series of stages. It never moves backward, and each stage is recorded, so the timeline on a transaction tells you exactly how it got where it is.

1. Created and validated. The transaction record is written and its request data is checked. Nothing has reached the card networks yet.
2. Enriched. WinkPG resolves the surrounding context: the customer, the stored payment method, the contract, the merchant configuration, and the processor that will handle the payment.
3. Screened. Fraud and policy rules run. A payment can be stopped here, before any money is requested.
4. Authorized. The processor asks the cardholder's bank to approve the amount. An approval places a hold on the cardholder's funds. It does not move any money, and the hold expires on its own if nothing further happens.
5. Finalized. The outcome is written back to the transaction: the approval code, the response codes, the receipt data.
6. Captured. The payment is marked as ready for the money to move. Depending on how the payment was submitted, this happens automatically in the same request (a sale) or as a separate step you take later (an authorization you capture once you ship).
7. Settled. The captured payment is submitted to the processor as part of a batch, and the funds are on their way to the merchant's bank account. This is the step that actually moves money.

The gap between step 6 and step 7 is the one worth internalising. Capture is bookkeeping: it tells WinkPG to include the payment in the next batch. Settlement is the money. A payment can sit captured for hours before it settles, and the cardholder's statement will show a pending charge that whole time.

Reporting reflects the transaction as it exists right now, and the stages advance in the background. A status you read immediately after submitting a payment may still be catching up.

When a payment does not go through

Three different outcomes look similar on a report and mean different things. Reading them correctly saves a lot of time.

Declined. The issuer, the processor, or a fraud or policy rule refused the payment. The request was received and answered, and the answer was no. For most declines, running the same card again unchanged produces the same answer, so the productive next step is a different payment method, or the cardholder contacting their bank. Some declines are worth another attempt, insufficient funds being the common one, since the balance can change; Retry is offered on a declined payment where a fresh attempt is worthwhile. The decline reason code, where the processor supplied one, is on the transaction and is what tells you which kind you are looking at.

Failed. WinkPG could not complete the request at all: a processor timed out, a host was unreachable, or the request could not be processed as submitted. The payment was never decided one way or the other, so no hold was placed and a retry may well succeed. Retry on the transaction re-attempts it with the same type and the same amount.

Policy rejected. One of the merchant's own address or security-code rules refused the payment. This happens in two ways, and the difference decides whether a hold ever existed. Where the processor itself applied the rule and declined outright, no hold was placed and there is nothing to release. Where the processor approved and the rule then matched the response, WinkPG releases the hold for you by issuing a reversal or a void before recording the transaction as rejected by policy. Either way there is nothing to clean up afterwards, so an absent reversal on a policy rejection is not a sign that something was missed.

There is also a state that is neither an approval nor a refusal. When a bank approves less than the requested amount, the transaction holds the smaller amount and waits for a decision: accept the lesser amount, cancel it, or collect the remainder on a second tender. It stays in that waiting state until someone decides, and if the acknowledgment deadline passes first, WinkPG voids the partial approval on your behalf so no stray hold is left on the cardholder.

The four operations

Which operation you need depends entirely on how far along the payment is. Only one of them is usually available at any moment, and WinkPG works out which one for you.

Capture marks an approved authorization as ready for the money to move, taking it from "funds held" to "included in the next batch close". On most processors this is gateway bookkeeping for the full authorized amount and no message goes out at that moment; the funds move when the batch settles. Terminal-based processors that clear at capture time are the exception, and there the capture is a real round-trip to the processor. Capture is available on an approved authorization that has not been captured yet, and it confirms in one step with no amount to enter. Once the payment has settled, Refund takes over.

Void is the full-amount cancel before settlement. The payment is excluded from the next batch close, and it is final once approved. What happens on the processor side depends on the processor and the card type: some voids are handled locally and approve immediately, while others send a message to the network to release the issuer's hold. Where a message is sent, WinkPG reports the void as successful only once the processor confirms it, so a void that the processor did not confirm is reported as a failure rather than quietly leaving a live hold behind.

Reversal is the other pre-settlement cancel, and it is the one that can be for part of an amount. It always sends a message to the processor to release the issuer's hold and pull the payment from the next clearing, so the processor can refuse it. It is offered on processors that support reversal, and only inside the reversal window that processor advertises, which is typically much shorter than the window in which the payment is still pre-settlement. Where the processor also supports partial reversals, you can release part of an amount, and the transaction stays open with the remainder still authorized until the reversed total reaches the full authorized amount.

Void and Reversal overlap, so WinkPG evaluates each payment and normally offers just one of them. Which one you get is driven by the processor's capabilities and the payment's type: some payments offer Reverse as the cancel, others offer Void, and a few offer both. All three presentations are working as intended, and the next section explains how to read each.

Refund is the post-settlement return. Once a payment has settled, the money has moved and there is nothing left to cancel, so a refund creates a new transaction of its own, linked back to the original, and that new transaction runs through the normal authorization and settlement pipeline just like any other payment. That means a refund is not instant: it settles in a later batch. WinkPG tracks refund capacity against the original payment, so several partial refunds issued at once can never add up to more than the original amount.

	Reaches the processor	Available when	Result
Capture	Depends on the processor	Approved, not yet captured	Payment joins the next batch, in full
Void	Depends on the processor and card type	Before settlement, when reversal is not the offered cancel	Payment is excluded from the batch, in full
Reversal	Yes	Before settlement, within the processor's reversal window	Hold released at the issuer, in full or in part
Refund	Yes	After settlement	New linked return transaction

Two more actions appear alongside these on approved payments. Repeat charges the same payment method again as a new transaction, which is how you re-bill a card on file, and it accepts a different amount. Retry re-attempts a declined or failed payment with the same type and amount.

Reading the cancel buttons

WinkPG decides which cancel operations a payment is eligible for and labels them to match, so the buttons on screen tell you what you are getting.

• Reverse on its own means reversal is the cancel operation for this payment, and it covers the full amount.
• Void and Partial Reversal shown together means the processor takes Void as the full-amount cancel for this payment type and also supports reversing part of an amount. Use Void for the full amount and Partial Reversal when you want to release only part of it. The amount prompt names whichever one you chose.

Where the actions live

The Transaction Explorer at /Transactions/Reports is the working list. Each row carries View, Capture, Reverse, Partial Reversal, Void, Refund, Repeat, and Retry. The set is evaluated per transaction on the server, so a row only offers what that specific payment is eligible for right now, given its stage and its processor's capabilities. Filter chips, sort presets, and saved column layouts let you narrow the list to the payments you are working on.

The transaction detail page at /transactions/{id} carries the same actions plus the full record: amounts, payment method, response and decline codes, custom fields, and a Timeline showing every stage the payment passed through and when. When a payment did something unexpected, the timeline is the fastest place to see what happened.

Quick View opens a summary panel over the list without navigating away, and offers Capture, Refund, Reverse, and Void for the common single-payment follow-ups. Each one asks for confirmation before it runs.

Two things decide what an operator sees on a payment: whether the payment is eligible for the action, which WinkPG evaluates on the server, and the permissions the operator's role holds. Working through the surfaces above rather than a fixed mental rule is the reliable approach, because the eligible set is recomputed per payment.

Settlement

Settlement is the batch process that turns captured payments into money in the bank.

The open batch

Every merchant has an open batch per processor: the running collection of captured payments waiting to settle. As payments are authorized and captured they are stamped with the current open batch. When settlement runs, that batch is closed and submitted to the processor, and a fresh batch opens to collect the next set.

/Transactions/settlement/open-batch shows the open batch for the merchants in your scope, broken out by processor and payment type, with a live count and total of what is waiting. It refreshes on its own while you have it open, and there is a Refresh button and a View History link in the page toolbar.

Automatic settlement

Auto-settlement is configured per merchant, in the merchant's processing settings:

• Enable turns automatic settlement on for the merchant. On processors that capture at the terminal, this is what makes those transactions capture automatically.
• Settlement time is the time of day the batch should close, expressed in UTC. Store the UTC equivalent of the local time you want; if you want a 5:00 PM Central close, enter the matching UTC time.
• Summary email settings sit alongside these and record who a settlement summary is addressed to: the primary merchant user or all merchant users, plus any additional addresses you list.

A settlement worker runs on a schedule in the background. On each pass it picks up the merchants whose configured settlement time falls inside that pass's window and settles them. So the settlement time you configure determines which pass a merchant settles on, and settlement happens shortly after the time you set rather than exactly on it.

Settlement can also be triggered on demand for a merchant, which is what you want for a manual close outside the normal schedule.

Reading a batch outcome

Each settlement run records a result per merchant and processor. The statuses mean:

Badge	What it means
Pending	The batch has been created and is waiting to be submitted to the processor.
Completed	The batch settled with the processor. The funds are on their way.
Partial	Some transactions in the batch settled and others were rejected by the processor. The badge carries an "N of M settled" line, and the batch detail shows which.
Failed	The batch did not settle. This is treated as a transient fault, so the next scheduled run tries again automatically. The reason appears under the badge and in full on the batch detail.
Nothing to Settle	There was nothing eligible to settle for that merchant and processor on this pass. A successful no-op, not a problem.
Action Required	The batch is deliberately parked and excluded from automatic retries, because re-submitting it as-is would fail the same way. The usual cause is a batch number the processor has already seen. An administrator resolves it by retrying the batch with the batch number bumped.
TerminalContention	Another settlement run already held the processor terminal for this merchant, so this run stood aside. The processor works one batch at a time per terminal. The next run settles it normally.

Per-transaction settlement status

Individual payments carry their own settlement status, shown in the Transaction Explorer's Settlement Status column. Four values have a short label of their own:

• Pending: on a card payment, captured and sitting in the open batch waiting for the next close. An ACH payment also reads Pending, for a different reason: its processor has the payment and is working it. See the ACH section below.
• Settled: settled. The money has moved.
• Failed: the settlement attempt failed and will be retried.
• Not Eligible: not part of a card batch, because the payment was voided or reversed, or was never captured.

The remaining values are less common and appear under their own names:

• SettlementInProgress: part of a batch currently being submitted.
• SettlementOnHold: parked with its batch and not retried automatically, pending operator action on the batch.
• SettlementRolledBack: previously settled, then rolled back by an administrator. It can settle again in a later batch.
• ReversalFailed: a reversal was attempted and the processor did not confirm that the hold was released. Confirm the hold's state with the processor and release it manually if it is still in place. This is the one status that needs someone to act on it directly.

Settlement pages and access

Page	Route	Permission
Open batch	/Transactions/settlement/open-batch	Transactions.Settlement.View
Settlement history	/Transactions/settlement/history	Transactions.Settlement.ViewHistory
Batch detail	/Transactions/settlement/history/{id}	Transactions.Settlement.ViewHistory

Settlement history lists past runs with their outcomes, and each row opens the batch detail with the transactions that were in it.

The remaining settlement capabilities are administrative: overriding a transaction's settlement status, managing the processor batch number, and retrying a specific failed batch. By default WinkPG grants these to administrator roles only, while merchant and reseller roles are given the view permissions and, for merchants, the ability to trigger settlement. Permission grants are editable, so check the roles in your own environment to confirm who holds what.

ACH works differently

ACH payments do not follow the card lifecycle described above, and the differences are not cosmetic:

• There is no hold. ACH has no authorization step that reserves funds, so there is nothing to capture, void, or reverse in the card sense.
• They never enter a card batch. ACH payments are kept out of the card settlement pipeline, so their absence from the open batch is expected and correct.
• The processor owns the status. ACH clears on the ACH processor's side. The payment sits at Pending while the processor works it, and a synchronisation job advances it as the processor reports back: to Settled when it clears, to Failed when the processor rejects it, and to SettlementRolledBack when it is returned. So an ACH payment's status moves over hours and days rather than in the moment, and a long-running Pending is normal for ACH in a way it would not be for a card.
• Returns come back as NACHA return codes. When a receiving bank refuses a debit, it returns it with a standard NACHA return code (R01 for insufficient funds, for example) and a reason, both recorded on the transaction.
• Returns can arrive late. An ACH debit that has already settled can still be returned afterwards, and the synchronisation job moves the payment to SettlementRolledBack when that happens. So treat ACH settlement as durable rather than instantaneous when you decide to fulfil an order.

If you subscribe to event notifications, ACH status changes and returns arrive as Transaction.AchStatusChanged and Transaction.Returned rather than through the card settlement events.

Watching the lifecycle from your own systems

If you need your own systems to react to these transitions rather than watching a screen, subscribe to the card lifecycle events: Transaction.Authorized, Transaction.Declined, Transaction.Captured, Transaction.Voided, Transaction.Reversed, Transaction.Failed, and Transaction.Settled.

The distinction that matters most in code is the same one as above. Transaction.Captured means the payment joined the batch; Transaction.Settled means the funds moved, and it arrives hours later, carrying the batch identifiers you need to reconcile against a processor statement. Fulfilment logic that keys on capture is deciding on a hold, not on money.

See also

• ACH Payments for the bank-debit lifecycle summarised above, in full: where to take an ACH payment, how its status advances, and how returns arrive.
• Webhook Integration for receiving these lifecycle events at your own endpoint, including the signature scheme and deduplication.
• How Timezones Are Handled for how times are stored and displayed, which is worth reading before setting a settlement time.
• Transaction Custom Fields for attaching your own business data, such as an order number, to the transactions described here.