When someone pays by card or bank account, your billing application sends the payment to Authorize.Net or BluePay. Rhythm then asks the processor to handle the payment based on the transaction type and the processor’s response.
Authorizing a Payment Versus Capturing It
For a card payment, Rhythm can ask Authorize.Net or BluePay to authorize an amount, which reserves the amount on the payer’s card without collecting it yet. Rhythm can then capture that authorization later to collect the payment. For most transactions, Rhythm completes both steps at once as a sale, which authorizes and captures in one request. For each of these transactions, Rhythm charges your existing saved Authorize.Net profile instead of creating a new payment profile each time.
If Collect, Rhythm’s billing engine, asks Authorize.Net to authorize a payment without an amount, Authorize.Net places a nominal hold of one unit instead of refusing the request. Authorize.Net handles an amount of zero the same way. BluePay treats a missing amount differently and refuses the request.
A capture uses only the first authorization recorded on a payment. If a payment somehow has more than one authorization, Rhythm does not capture the later ones. Rhythm also does not compare the capture amount with the original authorization amount, so the processor decides whether to accept it.
In rare cases, the gateway can approve a payment while Rhythm’s record does not update to match it. The invoice or order may still show an open balance, or the payment may look pending, even though the card or bank account was charged. If a payer says they were charged but Rhythm still shows the payment as open, check the transaction in your Authorize.Net or BluePay account before assuming the charge failed.
Voiding Versus Refunding a Cancelled Payment
When a card payment is cancelled, the result depends on the processor and the timing. The payment becomes either a void, where the charge never reaches the payer’s statement, or a refund, where settled money is returned.
| Processor | Rule |
|---|---|
| Authorize.Net | A same-day charge cancelled before an internal cut-off is voided. After that cut-off passes on the payment date, cancelling the payment creates a refund instead. |
| BluePay | Always creates a refund, never a void. Even a same-day cancellation still appears on the payer’s statement before the money is returned. |
A void cancels the whole transaction only; you cannot void part of a payment. If a payment has more than one capture, only the first capture is voided or refunded, and later captures are left alone. Rhythm does not compare a refund with the amount that was actually captured, so the processor decides whether to accept the requested refund amount. If BluePay says it could not locate the original transaction, BluePay generally could not find the master transaction or token your request used. Confirm the original payment still exists and was captured in BluePay before trying again.
A void does not always release the payer’s card the way they expect. If a capture is voided instead of the original authorization, BluePay may not send the card issuer the same release signal it would send for the authorization itself. The payer’s card can keep showing an authorization hold until it expires on the issuer’s schedule, even though Rhythm shows the payment as cancelled.
Tip
BluePay and other gateways record transaction times in their own time zone, which may not match the time zone shown in Rhythm. If a BluePay timestamp looks off by an hour or so, check whether the gateway and Rhythm are reporting in different time zones before assuming something is wrong.
Electronic checks and other digital payment methods are refunded through the payment gateway itself, not through a separate process in Rhythm. If a refund for one of these payment types does not work, check your gateway account settings for that payment type. Also look for any refund-specific setting that applies to it separately from card payments. If you need help completing the refund in the gateway, contact your payment gateway provider directly because Rhythm cannot complete that part for you.
If BluePay integration test mode is turned on in your Rhythm integration settings, a payment can still create a normal-looking gift or payment record in Rhythm even though BluePay never captures it as a live transaction. Cancelling that payment later does not send BluePay a real refund either, because there was never a live capture to refund.
A transaction can also exist at BluePay or CardPointe with no matching refund record in Rhythm’s payment history for the same invoice or payment. If your gateway account shows a refund that Rhythm does not, treat the gateway as the source of truth for whether the money actually moved, and contact Support with the transaction details if the two records do not reconcile. A refund can fail to reach the processor for a related reason: if the connection between Rhythm and your Authorize.Net account is broken, Rhythm may record a refund as processed while Authorize.Net never receives it, and the balance can show as due again later. If a refund does not seem to have reached the payer, verify the transaction directly with your processor. If Rhythm sends a refund and BluePay cannot process it, review the specific refund error in your BluePay account, correct the underlying issue there, and reprocess the refund from BluePay directly. A generic error about a refund credit not being processed means the gateway needs attention before the refund will complete. Rhythm Support cannot sign in to or inspect your merchant or gateway account for security reasons, so you or your processor contact must confirm gateway-side settings and transaction details.
Why a Repeated Charge Can Be Blocked
A gateway’s "duplicate" or "authorization failure" response to a repeated charge is usually a fraud or velocity control, not a problem with the payment itself. The block typically clears after the gateway’s own time window passes.
Authorize.Net refuses a second sale when it exactly matches the amount, card, and account already charged within the last two minutes, and the account is in live mode. This 120-second window works the same way for every live Authorize.Net account and cannot be changed from the Console. It does not apply in test mode.
A related but separate issue can come from BluePay. BluePay performs its own duplicate scrubbing, and it can reject a new transaction that repeats the same card number, billing address, and amount within a short window, even for a different order or contact. This duplicate response is a fraud or velocity control, so the same charge may succeed if you wait a few minutes and try again. The same scrubbing can catch a second refund too: a refund for the same amount, by the same user, on the same order, submitted again within about 10 minutes of the first, may be rejected by BluePay the same way a duplicate charge would be. In some cases, these fraud or velocity rules let a transaction appear to process and then void it automatically.
If these payments are truly separate and not accidental double-clicks, review your BluePay account for the specific error, check BluePay’s own error-message reference, and contact BluePay support. A BluePay representative can adjust duplicate scrubbing for your merchant account or reduce the time threshold in your velocity filter settings so closely spaced transactions stop being rejected. BluePay and CardPointe also support a transaction-level override parameter that can bypass duplicate scrubbing for a single payment; ask BluePay support whether that applies to your account. BluePay controls these settings, not Rhythm.
If you see an error like "Authorization Failure Rate Exceeded", that is a separate fraud-prevention rule. It means too many incorrect payment attempts were entered in a short period, and the processor is protecting the account against card-testing attacks, sometimes called carding. This restriction clears on its own after five minutes, and there is nothing to reset in Rhythm.
Not every payment error in this category can be resolved from Rhythm. Some errors, including membership payment failures tied to a gateway’s fraud rules, are controlled entirely by the payment gateway and need its support team to adjust them.
Test Mode Versus Live Mode
An Authorize.Net account sends transactions to either Authorize.Net’s test system or live system based on the account’s settings page under Payment Processors. A few operations always use Authorize.Net’s test validation, no matter how that account is set: validating a newly saved customer profile and deleting a stored payment page key. Because of that, a new card is not checked against the live network during that specific step, regardless of the account’s mode.
Tip
Running a single authorization as a connection test does not create a linked sale record. An authorization-only test is not meant to complete a full purchase, so seeing an authorization with nothing attached to it afterward does not mean anything went wrong.
Some card-security features live outside this settings page entirely. If your BluePay or CardPointe account uses Visa 3-D Secure authentication, your payment provider sets it up, not Rhythm. Rhythm has no control to turn it on or off. You do not need any Rhythm-specific identifiers to configure it; the details you need are already in your gateway account.
What Rhythm Sends Automatically
- Every Authorize.Net sale is marked as a one-time charge, not a recurring one. This includes recurring gifts and membership renewals, so Authorize.Net sees them as ordinary individual transactions.
- If a saved Authorize.Net card fails the card’s address verification, Rhythm reports the specific merchant account, contact, and payment back to Collect so the decline can be shown accurately. Only an address mismatch triggers this. A wrong card code, an expired card, or insufficient funds do not trigger it, and those declines can appear in Rhythm as a generic order-preparation or integration-execution error instead of Authorize.Net’s specific decline reason. Whether an incorrect card code or address declines a transaction also depends on your merchant processor’s settings, so the same card can be declined on one account and accepted on another. If you need to confirm a decline reason directly with Authorize.Net, remember that Rhythm Support cannot sign in to your Authorize.Net merchant account for security reasons. You or another authorized contact on the account must confirm it.
- Saving a card, or paying with a new card, automatically creates the matching customer and payment profile at Authorize.Net. You do not need to create those profiles yourself before paying through Rhythm.
- A payer with no matching Rhythm contact, such as someone using a public payment link, is saved under a temporary guest payment profile at Authorize.Net. Guest profiles are temporary, and Authorize.Net removes them after about 90 days.
- Deleting a saved payment profile in only one place can leave Rhythm and Authorize.Net out of sync. Delete a profile in both places, and keep the profile counts aligned. Authorize.Net allows only 10 payment profiles per customer, so profiles left behind in one place can contribute to hitting that limit.
- Switching an account active or inactive does not affect whether it can authorize, capture, void, refund, or sell. An inactive account continues to process normally through these calls.
After You Stop Using BluePay
If your account has moved to a new processor, Rhythm’s ability to investigate older BluePay transactions is limited. Once BluePay is no longer your active processor, Support may not be able to look into a historical BluePay transaction in much depth. If you suspect a problem with a transaction from your BluePay period, contact BluePay directly, and have the cardholder contact their card issuer if fraud is suspected.
Support has also seen legacy BluePay auto-renewals keep processing unexpectedly after a gateway cutover. Disabling the legacy BluePay connection, such as by replacing its integration key with a value BluePay no longer recognizes, has stopped this from recurring in cases Support has reviewed. Treat this as a workaround rather than a standard step, and check with Support before changing a connection you still rely on for anything else.