---
title: "Unresolved Card Payments: Payment Attempts"
description: Card payments do not always end in a clean yes or no. A bank can hold a payment for review, a gateway can time out after taking the money, or a customer can close the browser between the charge and…
url: "https://rackhelm.com/documentation/payment-attempts/"
updated: "2026-09-24"
category: "Billing & Payments"
---

# Unresolved Card Payments: Payment Attempts

Card payments do not always end in a clean yes or no. A bank can hold a payment for review, a gateway can time out after taking the money, or a customer can close the browser between the charge and the order. **Billing → Payment Attempts** is where those land. Nothing on this screen is automatic: every outcome is decided by a person, which is precisely what stops a customer being charged twice. It is written for operators.

## Why this screen exists

The alternative to holding an unclear payment is guessing. Guess "it failed" and you retry a charge the bank actually took. Guess "it worked" and you provision a service nobody paid for. RackHelm freezes anything it cannot be certain about and waits.

While an attempt is unresolved:

- Its invoice is frozen — no renewal charge is retried against it.
- If it is a checkout hold, **every paid checkout by that customer is blocked** until it is resolved.

> **Warning:** None of the actions on this screen marks anything paid or creates an order. They record what you established at the gateway. Settling the invoice, if it needs settling, is a separate step.

## The three tabs

| Tab | What is in it |
| --- | --- |
| **Held** | Payments the gateway is holding for review, or whose outcome never came back. Listed against the invoice, with how long they have been held. |
| **Holds** | Checkout holds, listed per customer. These block that customer's paid checkouts. |
| **Blocks** | Accounts currently blocked, and what is blocking them. |

> **Note:** The list shows the oldest first and is capped. "Showing the … oldest. Resolve these to see the rest." means exactly that — work down the list and more appear.

## Before you resolve anything: check the gateway

Every action here is a statement about what you found in the gateway's own dashboard. Open Stripe, PayPal, Square or the Authorize.net Merchant Interface, find the transaction by its id from the Transaction column, and establish one thing: **did money move?**

## Resolving a held payment

| Action | Use it when | What it does |
| --- | --- | --- |
| **Charge found — void it now** | The gateway shows a charge you do not want to keep. | Voids that transaction at the gateway, then releases the hold. |
| **Reversed manually** | You already voided or refunded it yourself in the gateway's dashboard. | Records that it is reversed and releases the hold. Nothing is sent to the gateway. |
| **Release the hold** | The gateway shows no charge at all for this attempt. | Clears the hold and unblocks the customer. |
| **Charge kept — order created manually** | The money was taken and you have raised the order by hand. | The documented alternative to voiding: keeps the charge and clears the hold. |

## Release all

**Release all** clears the listed holds in one go. It is for the case where you have checked the gateway, found no charges, and simply need the queue cleared — for example after a provider outage that timed out a batch of attempts.

> **Warning:** Release all does not check anything on your behalf. If any of those attempts did take money, releasing them hides the evidence and the customer keeps the charge with nothing to show for it. Check the gateway first, every time.

## A worked example

1. A renewal charge through Square gets no answer. RackHelm freezes the invoice and the attempt appears under **Held**.
2. You open Square, search the transaction id, and find the payment completed.
3. The customer should keep the service, so you settle the invoice as normal and then use **Charge kept — order created manually** to clear the hold.

Had Square shown no payment, the right action would be **Release the hold** — and the next scheduled run would charge the renewal properly.

## Which gateways use this

All of them, but it matters most for Authorize.net, which has no webhook: a held or unknown Authorize.net payment has no other way to be resolved. Stripe's webhook settles most of its own uncertainty, so its entries here are rarer.

## Keeping the queue short

- Check it on a schedule. A hold blocks a paying customer from checking out, and they will not necessarily tell you.
- Resolve oldest first — that is the order the screen gives you, and the oldest holds are the ones costing you orders.
- If entries keep appearing for one gateway, the cause is usually upstream: an expiring API credential, or a gateway account under review.

## Permissions

Resolving attempts moves money at the gateway and is restricted to staff with invoice-editing rights. See **Roles and Permissions**.