# Decision guide: Void vs refund
> Choose the correct method to cancel Pay In transactions with an interactive decision tree. Learn when to use void for same-day cancellations or refund for settled transactions
When you need to cancel a transaction, choosing between void and refund affects both timing and costs. Void cancels unsettled transactions before funds are transferred, while refund returns funds after settlement. This guide helps you determine which method to use based on transaction status and timing.
## Decision tree
Use this interactive decision tree to determine whether to void or refund a transaction based on its current status.
## Recommended strategy by use case
Choose the right cancellation method based on transaction timing and status. Here's a quick reference:
| **Use case** | **Method** | **Key requirement** |
| ----------------------------------------- | ---------- | ------------------------------------------------------------- |
| Same-day cancellation before batch closes | Void | Current time \< Batch cutoff (default 5 PM ET) |
| Cancel authorized transaction | Void | TransStatus = 11 (Authorized), SettlementStatus = 0 (Pending) |
| Cancel captured transaction same-day | Void | TransStatus = 1 (Captured), SettlementStatus = 0 (Pending) |
| Cancel after batch closes | Refund | SettlementStatus = 1 (In Transit) or higher |
| Return funds after settlement | Refund | SettlementStatus = 2 (Transferred) or 3 (Funded) |
| Partial amount return | Refund | Any settled transaction |
| Customer requested cancellation next day | Refund | Batch already closed |
## Void
Void immediately cancels a transaction before the batch closes and before funds are transferred. This is the preferred method for same-day cancellations because it avoids interchange fees and ensures funds never leave the customer's account.
Use void when:
* The transaction is still in an open batch before the cutoff time
* You need to cancel an authorized or captured transaction same-day
* You want to avoid interchange fees on the cancelled transaction
* The customer requests cancellation before end of business day
Void is available when:
* `TransStatus` is 11 (Authorized) or 1 (Captured)
* `SettlementStatus` is 0 (Pending)
* Current time is before batch cutoff (default 5 PM ET, configurable per merchant)
* `BatchStatus` is 0 (Open)
### Void implementation
Call the void endpoint with the transaction ID to immediately cancel the transaction:
```bash
// V1 endpoint
GET /MoneyIn/void/{transId}
// V2 endpoint
POST /v2/MoneyIn/void/{transId}
```
The transaction will be marked as voided and removed from the settlement batch. No funds will be transferred from the customer's account.
### Void best practices
Follow these best practices when implementing void functionality:
* Check transaction status before attempting void to verify eligibility
* Implement void functionality in your customer service or admin interfaces
* Set up monitoring for batch cutoff times to alert staff of void deadlines
* Log all void attempts including successes and failures for audit trails
* Display clear messaging to users about void vs refund timing differences
## Refund
Refund creates a new offsetting transaction that returns funds to the customer after settlement has begun or completed. Use refunds for any transaction that can no longer be voided due to batch closure or settlement status.
Use refund when:
* The batch has closed and transaction is in transit for settlement
* The transaction has already settled and funds were transferred
* You need to return a partial amount to the customer
* The customer requests a return after the void window has passed
Refund is required when:
* `SettlementStatus` is 1 (In Transit), 2 (Transferred), or 3 (Funded)
* The batch cutoff time has passed
* Any transaction that can't meet void eligibility criteria
### Refund implementation
Call the refund endpoint with the transaction ID and amount to process the refund:
```bash
// V1 endpoint
GET /MoneyIn/refund/{transId}/{amount}
// V2 endpoint
POST /v2/MoneyIn/refund/{transId}/{amount}
```
Parameters:
* `transId` - Original transaction ID to refund
* `amount` - Refund amount in cents (can be less than original for partial refunds)
The refund creates a new transaction that offsets the original payment. Funds typically return to the customer's account in 2 to 3 business days, though it may take up to 5 to 7 business days depending on the customer's bank.
### Refund best practices
Follow these best practices when implementing refund functionality:
* Store original transaction IDs to enable easy refund processing
* Implement partial refund support for flexible customer service
* Set up webhooks to track refund processing status and completion
* Communicate refund timeline clearly to customers (2-3 business days typical)
* Log all refund transactions with reasons for audit and reporting purposes
* Consider implementing refund approval workflows for large amounts
## Status field reference
Understanding transaction and settlement status codes helps you determine void or refund eligibility programmatically.
### Transaction status
Use the `TransStatus` to help determine if a transaction can be voided.
| Code | Status | Description |
| ---- | ---------- | --------------------------------------------------------------------------- |
| 11 | Authorized | Payment authorized but not yet captured, eligible for void if in open batch |
| 1 | Captured | Payment captured and will be settled, eligible for void if in open batch |
### Settlement status
Use the `SettlementStatus` to understand if a transaction has been settled and how to handle canceling it.
| Code | Status | Description | Void eligible? | Refund required? |
| ---- | ----------- | ----------------------------------------------- | ---------------------- | ---------------- |
| 0 | Pending | Transaction in open batch awaiting settlement | Yes (if before cutoff) | No |
| 1 | In Transit | Batch closed, transaction locked for processing | No | Yes |
| 2 | Transferred | Transaction settled to merchant account | No | Yes |
| 3 | Funded | Funds available in merchant account | No | Yes |
### Batch status
Use `BatchStatus` to determine if the batch is still open for voids.
| Code | Status | Description |
| ---- | ------ | ----------------------------------------------------- |
| 0 | Open | Batch accepting transactions, void still possible |
| 1 | Closed | Batch closed for processing, void no longer available |
## Timing considerations
Batch cutoff time is critical for void eligibility. Understanding your merchant's cutoff schedule ensures you use the correct cancellation method. Here are key timing considerations:
* **Default cutoff**: 5 PM ET
* **Configurable**: Per merchant account settings
* **Timezone**: Always Eastern Time regardless of merchant location
* **Weekend/holiday**: Batches may close earlier or follow modified schedules
Processing timelines differ significantly between voids and refunds:
**Void timeline:**
* Immediate cancellation when executed
* Funds never leave customer account
* No return timeline needed
* Must be executed before batch cutoff
**Refund timeline:**
* Refunds are initiated immediately
* Settlement completes in 1 business day (if transaction was in transit)
* Funds are typically returned to customer in 2 to 3 business days
* May take up to 5 to 7 business days for the funds to be returned depending on customer's bank
**Implementation tips for timing**
Implement these features to handle timing correctly:
* Query current batch status before presenting void option to users
* Display countdown timer showing time remaining until batch cutoff
* Automatically switch UI from void to refund option after cutoff passes
* Store merchant-specific cutoff times if they differ from defaults
* Account for timezone conversions when displaying cutoff times to users
## Quick reference
This section provides quick links to relevant API endpoints and integration guides mentioned in the decision tree and throughout this guide.
**API References:**
* [Void transaction API (v1)](/developers/api-reference/moneyin/void-a-transaction)
* [Refund transaction API (v1)](/developers/api-reference/moneyin/refund-a-settled-transaction)
* [Void transaction API (v2)](/developers/api-reference/moneyinV2/void-a-transaction)
* [Refund transaction API (v2)](/developers/api-reference/moneyinV2/refund-a-settled-transaction)
* [Get transaction details API](/developers/api-reference/moneyin/get-details-for-a-processed-transaction)
* [Query Batch status API (org)](/developers/api-reference/query/get-list-of-batches-for-an-organization)
* [Query Batch status API (paypoint)](/developers/api-reference/query/get-list-of-batches-for-an-entrypoint)
**Integration Guides:**
* [Make a sale transaction](/guides/pay-in-developer-transactions-create)
* [Cancel a transaction overview](/guides/pay-in-developer-transactions-cancel)
* [Transaction statuses](/guides/pay-in-status-reference#money-in-transaction-status)
* [Settlement status codes](/guides/pay-in-status-reference#payment-funding-status)
**API References:**
* [List transactions for paypoint](/developers/api-reference/query/get-list-of-transactions-for-an-entrypoint)
**Integration Guides:**
* [Reporting overview](/guides/pay-ops-reporting-overview)