What This Does
Every payment your association receives creates a record you can find later. You can search by payment number, amount, date, processor transaction reference, customer, batch, or order. Rhythm also keeps reference records for money received outside Rhythm processing, such as payments migrated from an earlier system, so staff and customers can still see that the money was received.
If you need to check whether a customer was charged twice, search the full date range first. If you find only the later payment, with no earlier payment or processor transaction on the original date, that is good evidence there was no duplicate charge. You can confirm by checking the same date range in the payment gateway’s transaction history. If Rhythm and the gateway both show only one matching transaction, there is no evidence of a second Rhythm-managed charge, and the customer should continue tracing the charge with the gateway or card issuer.
When to Use It (and Not)
Use this when you need to find a payment so you can review, correct, refund, or reference it from another record. To take a new payment, see Receive a Payment instead.
Prerequisites
- You have permission to view payments in Finance & Billing.
- Rhythm Payments processes card and bank transactions separately from the Console. You may need separate access to verify a transaction, decline reason, refund, or disbursement; ask your administrator if you do not have it.
- If you plan to ask Support to investigate a specific payment attempt, have the payment processor’s transaction ID ready. Support needs that ID to review the attempt; the date, time, or screen details usually are not enough on their own.
Steps
- Go to Finance & Billing › Transactions.
- Search by the payment’s number, amount, date, the customer’s name, the card type, or the payment processor’s transaction reference.
- Select a result to open its payment page.
Tip
The card type on a payment is the card brand, such as Visa or Mastercard. It does not show whether the card was debit or credit, so you cannot use it to confirm whether a card processing fee should have applied to that payment.
On the payment page, you can review more detail than the transaction list shows, including the transaction’s current status. The payment may include a processor transaction reference you can look up in Rhythm Payments for details Rhythm does not show, such as returned messages from the processor. If your account gives you access to Rhythm Payments, open the same transaction there and check the Alerts area for the processor’s decline reason, such as a billing ZIP mismatch. That detail can be more specific than the short message Rhythm displays. You can use the same reference to confirm whether a refund went through or, for an electronic check or ACH payment, to check its funding date and settlement status.
Variants
Every payment a customer has made. Open the customer’s contact or organization page and review their transactions. Their payments appear with their invoices and credits.
The payments in one batch. Open the batch and review the payments listed there, especially before you post or close a period.
The payments tied to an order. Open the order in the application that sells it, such as Membership or Events, to see the payments that paid its invoices.
A payment made outside Rhythm. If your association migrated payment history from an earlier system, or has another record of money received outside Rhythm processing, that record appears in transaction search as an external payment. Open it to see its amount, date, description, and, when recorded, the payment method, card type, processor transaction reference, and payee. An external payment is for reference only; it does not apply to an invoice, affect a balance, or allow staff to create or edit it directly in the Console. After it is imported, it also cannot be transferred from one contact or customer record to another.
The payments tied to an order. Open the order in the application that sells it, such as Membership or Events, to see the payments that paid its invoices. If you are chasing a reference like an order number instead of a payment number, it may point to an order record rather than a payment transaction. Searching Transactions for that reference can come up empty, so look for it in the order’s own application, such as Orders and Inventory, instead. For a payment processed externally, you cannot open its order directly from the transaction. Open the contact’s or organization’s Purchases or Orders tab and find the order there.
A payment made outside Rhythm. If your association migrated payment history from an earlier system, or has another record of money received outside Rhythm processing, that record appears in transaction search as an external payment. Open it to see its amount, date, description, and, when recorded, the payment method, card type, processor transaction reference, and payee. An external payment is for reference only; it does not apply to an invoice, affect a balance, or allow staff to create or edit it directly in the Console. Historical external payment transactions also cannot be deleted from transaction history, for audit and data-integrity reasons. An external payment with no batch and no subledger entries does not drive any reportable value, so it does not appear in financial reporting even though the record stays visible in transaction history. If a search by gateway transaction ID, amount, contact, or organization does not find a payment you are sure exists, check whether it happened before your association started using Rhythm. A charge from before that point was never recorded in Rhythm and has no payment record to find.
A member's own payment history. In the Portal, members and organization contacts can see their own recent payments and open a payment to review it or download its receipt.
Reconciling a bank deposit or payout. A single deposit in your bank account can combine many individual payments, which Rhythm Payments calls a disbursement. To trace a specific payment into a deposit, open Rhythm Payments and check the Withdraw section for the disbursement’s status. You can also use the Payouts view, filtered by date range, to see which deposits relate to which payment dates. Searching by the trace ID from your bank’s deposit detail, or matching individual transaction IDs to a disbursement date, can also tie a deposit back to its underlying transactions. Rhythm Payments can send email alerts about disbursement activity, so you learn about items that need attention without checking manually. Rhythm does not currently have one report or shared identifier that ties your Rhythm batch or subledger activity directly to the matching Payrix disbursement. Reconciling a deposit against your accounting allocations usually means cross-referencing the two manually, such as by order number. For final confirmation that a rolled-forward or delayed disbursement reached your account, you may need to check Payrix directly. The payout or disbursement report you download from the gateway can change format from time to time. If columns you rely on, such as cardholder name or email, are temporarily missing, that is usually a gateway-side formatting change rather than a Rhythm problem, and it is normally corrected in a later update.
Tracing an approved card payment to your bank deposit, or a broader discrepancy. An approved card sale can sit in a specific disbursement before it reaches your bank account. If a payment shows as approved but you do not see it in the bank yet, check its disbursement in Rhythm Payments instead of assuming the payment failed. To investigate a broader discrepancy, compare the electronic card batch to the deposited funds in Rhythm Payments, then compare transactions in Rhythm Payments to the matching Console batch for the same date. Sorting transactions by date and matching transaction IDs between the two places helps you isolate where they disagree. Also check whether the payment date in the Console matches the date in Rhythm Payments for the same transaction, because a mismatch can look like a missing or duplicate payment when it is not.
Sorting out payments by processor for a migration or legacy review. Transaction identifiers often include a pattern or prefix for the processor that created them. You can use that pattern to separate a batch of records by processor and isolate likely legacy-provider payments when you are deciding whether older tokens or transactions still matter for recurring billing. In the Query Center, filtering payments where Legacy Processor is not blank finds only transactions created after that field was introduced; it will not return older historical payments from before the cutover.
Result
You see the payment’s details, including who paid, how much they paid, the payment method, the invoice lines and credits it applied to, and the batch it is in. The payment’s audit history shows which user created it and how it was applied, separate from any later batch move or other follow-up activity. It can also include origin details, such as whether the payment came through a public payment link, which helps you trace how a payment attempt started. To see who actually processed a transaction, or whether it was entered manually instead of created automatically, check the payment processor’s own account. Rhythm’s payment record does not distinguish the two.
What to Do If It Fails
A search by the payment's latest processor transaction reference doesn't find it. Rhythm indexes the transaction reference from the payment’s first charge attempt only. If the charge was retried, search by the payment’s number, amount, or date instead. A payment can have more than one attempt with a different outcome, such as one attempt declined for insufficient funds and a later one approved but not yet settled. If something looks inconsistent, do not rely on one list row’s status or date alone; open the payment and review the full attempt history.
A payment across invoices for two different organizations under one parent isn't listed the way you expect. The payment’s owner, either a contact or organization, determines which customer’s payment list includes it. If a payment pays an organization’s invoice but is recorded against a contact, it appears on the contact’s payments instead of the organization’s. This is set when the payment is taken. On Receive Payment, choosing the payer as an Organization and then choosing its billing contact records the payment under the organization, while choosing a contact records it under that contact instead. If a transaction is missing from the record you expected because it has the wrong contact or organization association, you can fix it directly. Edit the order, invoice, and payment to add the correct contact or organization, and the transaction will appear on that person’s or organization’s record. To find these cases at scale, such as public payment link transactions that paid an organization’s invoice but ended up owned by a contact, build a Payments query with Bill To Type (order) equal to organization, Owner Type (payment) equal to contact, and Created By (payment) blank.
You expected to see an external payment but it isn't listed. External payments come through data migration or import, not everyday Console work. If one seems to be missing, contact Support.
You need to reconcile by your bank's trace number. Rhythm does not currently offer a report or search by trace number. Search by the payment’s number, amount, date, or processor transaction reference instead.
A payment's Payment Method field shows blank or "None." This usually means the order behind the payment was set to Pay Later rather than paid electronically at the time. It does not mean data is missing.
A card's last four digits aren't available when you query payments. Whether Rhythm stores that detail can depend on how the payment was submitted. For example, a payment made through the Portal can follow a different processing path than one entered in the Console. If you need that detail and it is missing, check how the payment was made before assuming it is an error.
A payment shows as complete with no processor transaction reference at all, for a payment type you don't normally see this on. Capture only runs for the payment types Rhythm recognizes, such as credit card and electronic check. If a payment record ever carries a different type label, the capture step can be skipped while the payment is still written as complete, leaving nothing to look up at the processor. Check the payment's type before assuming the transaction reference was lost.
The same saved card keeps failing with an identical gateway expiration error, and re-adding it doesn't help. If other cards produce the same error too, the pattern points to a provider-side or processing-path issue rather than a problem with that one saved-card record. Contact Support instead of continuing to delete and re-add cards.
A payment looks stuck, unsettled, or flagged. A processor-side status such as awaiting settlement or in review is not the same as a payment hold. Neither Rhythm nor the processor controls exactly when a transaction gets flagged for review, because that decision belongs to the processor’s own risk screening. Payrix commonly reviews unusually high-value transactions, roughly six figures and up, but it can also flag a lower amount that looks unusual for your association’s normal activity. There is no safe amount that is guaranteed to avoid review. Splitting a payment into smaller charges to try to avoid review is not recommended and does not reliably help. International card transactions can also be held or declined by the processor’s fraud screening even when they are legitimate. If that happens, work with your payment provider’s risk team to review the transaction and release any held funds.
An invoice or order shows a payment as applied, but opening it fails or you can't find the payment record at all. Occasionally, the payment record itself goes missing. Sometimes this happens because a charge failed at the merchant’s own level and the attempt was not fully backed out, so no payment record was ever created even though a related order or invoice still references it. In other cases, a record existed and was later removed. Either way, a processor transaction or attempted charge can exist with no matching payment visible on the order. When this happens, opening the payment from an order’s or invoice’s Related Transactions can fail with a message that the record cannot be found. Moving it to another batch can fail the same way, and the payment will not show in its own batch or in batch-based reporting. That can throw off reconciliation and leave a payment-date query or similar report incomplete for that payment. A fix for this kind of display or query problem generally does not retroactively correct records created before the fix shipped, so an older affected record can keep showing the problem afterward. The invoice or order can still look correctly paid and balanced even though the payment record behind it cannot be opened. This can happen even when the charge genuinely went through at the processor, because the order can point to a payment Rhythm no longer has. Downstream steps that depend on the payment, such as updating a renewal date or completing membership fulfillment, may not happen until the record is restored. Rarely, this can go far enough that a receipt goes out and a renewal shows as paid with no payment record behind it at all.
If you run into this, check the invoice’s status, open its Related Transactions, and try the payment link. If it fails, check whether the payment is visible in Rhythm Payments and in your Rhythm account’s audit log for that payment or invoice. If it is absent from both places, that is a useful sign the record is genuinely missing rather than just hard to find. Contact Support with the transaction ID. Restoring a missing payment record is not something you can do yourself, and Support currently handles each affected payment individually rather than through a general fix. If you have confirmed that no payment was collected anywhere, with nothing in Rhythm Payments and no payment record in the Console, cancel the order instead of trying to repair it. Canceling also cancels its invoice, so you can create a new order for the customer to pay again.
A card payment that settled with the processor and bank can still end up missing its Rhythm record this way. The symptoms match the pattern above: the payment shows as applied against the invoice, opening the payment record fails or errors, and the amount is absent from both the batch and its journal entry download even though the money was collected. Treat it the same way: confirm the payment shows in Rhythm Payments, then contact Support with the transaction ID instead of trying to recreate the record yourself.
If you need to confirm whether payment processing is working at all before you keep chasing a missing record, Support may ask your permission to add a test card and run a small, nominal transaction as part of the investigation. That is a normal step, not a sign something else is wrong.
A payment error appears to originate from BluePay. If your association uses BluePay as its payment processor, Rhythm Support cannot investigate the cause from the Rhythm side because Rhythm does not have access to your BluePay integration account. Someone on your side with BluePay login access needs to review the gateway details there.
You're disputing a payment or responding to a chargeback. Rhythm can show the paid order or registration record, the processor transaction ID, and audit history showing who created the record. Support cannot supply additional chargeback documentation or authentication evidence beyond what those existing records already contain.
A customer says they were charged twice, or you see only one payment but a negative balance. If you still see only one card payment but the account shows a negative balance, check for other credits, refunds, or payments recorded against a related contact or organization record before assuming the payment you found is the whole story. If Support needs to check the processor’s transaction logs to rule out a duplicate charge, ask promptly. Those logs are typically available to investigate for only about a week after the transaction. Some failed payment attempts never create a payment record at all. If the failure happened before an authorization reached the payment gateway, there is nothing to find in Finance & Billing, and checking the gateway itself for an authorization attempt is the only way to tell whether the failure happened before or after that point. A customer can also see a payment error on their screen even though the related order completed successfully in the Console. The audit log may not capture the error itself, so ask the customer for the exact steps, timing, and any error wording or screenshot before escalating.