Most payments do not require you to choose a business unit, cash account, or processor by hand. Members paying in the Portal or through a public payment link never choose those details themselves. For example, an event’s payment setup decides which bank account receives the payment, not the payer. Rhythm uses the payment details to choose the right setup, and this article explains what to check when a card payment fails for a reason other than the card itself.
How a Payment's Business Unit Is Chosen
When a payment does not already have a business unit, Rhythm chooses one automatically:
- If the payment applies to one or more invoices, Rhythm uses the business unit on the first invoice listed on the payment. Only that first invoice matters; Rhythm does not split one payment across business units based on the invoices it pays.
- If the payment is not tied to an invoice, Rhythm uses the business unit in your Rhythm account with the lowest priority number.
A checkout belongs to one business unit. Rhythm does not combine items or payments from one donation, purchase, or event flow across different business units. The payment must be made in the same business unit as the store or event that created it.
If you choose a business unit in the Console, the payment already has one. Rhythm then skips automatic assignment, including the merchant account defaulting described next.
When you process a payment against an invoice in the Console, your selected business unit must match the invoice’s business unit. A mismatch is a common cause of a generic payment-processing error that does not explain much by itself. If a card payment fails in the Console but works from a different business unit context, check that you are working in the invoice’s business unit before assuming something else is wrong. Rhythm shows your current business unit only in the top-right corner of the Console. It does not show a pop-up or warning when you apply a payment while a different business unit is selected.
Deactivating a business unit removes it from the options the next time someone switches business units in the Console. From that point forward, staff can no longer apply a new payment against it. Adding a new merchant account or business unit to your Rhythm account can also change which merchant account existing transactions try to use going forward, even for a store or business unit you did not mean to change. If payments unexpectedly start trying a different account after a setup change, check what was recently added.
How the Merchant Account Is Chosen for a Card or Bank Payment
Rhythm defaults the merchant account only when Rhythm also assigned the business unit, which happens for Portal and public payments. The Console always sends its own merchant account. When defaulting applies, Rhythm chooses the merchant account from the business unit’s default-account setting and account priority. The invoice or product being paid does not change that choice.
When a customer pays with a saved card or bank account, Rhythm needs a saved token for the merchant account that will process the charge. If the saved payment method does not have a token for that merchant account, Rhythm refuses the payment and shows a message explaining the problem. Staff using the Receive Payment screen see the same check stop the payment before it is submitted.
A store or checkout can have its own merchant-account setting, separate from the business unit’s default. If a store is configured to use one merchant account while you expect another, such as a secondary account for a specific program, the store-level setting still controls processing. Setting up the business unit correctly will not override it. Check the store’s own merchant account setting when a checkout uses an unexpected account.
If the merchant account a payment uses belongs to a different business unit than the invoice it pays, the payment can fail. The error does not always say the two do not match. This is another version of the business-unit mismatch described above, so check that the merchant account and the invoice’s business unit agree.
A saved card or bank account token is tied to the merchant account and business unit where it was originally saved. If a customer saved a payment method while paying in one business unit and later tries to use it in another, Rhythm can refuse the charge with a token-related error even though the method worked before. To work around this, remove the saved payment method and add it again in the business unit you need, or avoid saving the card for a transaction outside its original business unit.
Authorize.Net is a partial exception. Because Authorize.Net needs to support routing a saved card to whichever merchant account processes it, Rhythm creates an Authorize.Net payment profile for a saved card in every business unit, not only the one where the card was first entered. If an association’s memberships are set to auto-renew and the saved cards were originally stored under an Authorize.Net merchant account, renewals can still fail with an authentication error if that merchant account later becomes inactive. An inactive account cannot take a new charge, no matter how the token was created.
Recurring and auto-renewal billing runs use whatever token a saved payment method already has. If your account has moved to a new processor but a member’s saved method still only has a token for the old one, billing runs keep charging the old processor’s token until the member updates their payment method or your account completes a token migration. Switching processors does not move existing tokens to the new processor by itself. If you migrate saved tokens from Authorize.Net to Payrix, the imported tokens become usable in your Rhythm Payments account only after the import is mapped to the correct merchant account. Until that mapping is correct, the tokens will not appear where you expect them.
If a saved-method error mentions Stripe and a token that “does not appear to be a Stripe token,” the business unit’s configured processor or merchant account usually does not match the processor that originally created the token. It usually does not mean anything is wrong with the card. If your merchant accounts use a BluePay parent-child setup, with one primary account and a related sub-account, BluePay itself must have token sharing turned on. Without token sharing, transactions that should route to the sub-account can fail even when the Rhythm-side setup looks correct.
For a bank-style payment such as ACH, Rhythm still needs a working merchant account and bank account for the business unit or event taking the payment. If ACH payments fail, check that the relevant business unit, or the bank account named on the event, has an active and correctly configured merchant account. An ACH problem often traces back to that setup rather than to the payer’s bank details.
Warning
On Payrix, the $0.00 authorization check described below can, in some cases, use the first merchant account configured in your integration list instead of the merchant account assigned to the business unit. The transaction still settles in the correct merchant account. If an authorization record points to an unexpected account but the actual charge and settlement look right, that mismatch is the likely explanation, not a misconfigured business unit.
Which Kind of Account a Payment Type Uses
Card payments and electronic check debits are charged through a merchant account. Every other payment type, including a direct bank debit, posts to a bank account in the payment’s business unit. A store credit payment does not move money, so it does not need either kind of account. Rhythm refuses a payment that uses the wrong account type. That means an electronic check payment goes through your merchant account and processor instead of behaving like a simple bank transfer.
An option labeled “ACH” does not always mean the same thing. In some places, it means an electronic check that Rhythm processes through your merchant account and processor. In others, it records a bank payment handled entirely outside Rhythm, with Rhythm keeping only the record. If a payment type in your setup is called ACH but records an external bank transfer instead of processing a live one, treat it as an offline record, not a live electronic check.
When a payer chooses a bank-debit option such as electronic check at checkout, they enter their own bank account and routing details. Rhythm does not pre-fill or already know that information. Electronic checks also require a fully configured merchant account, not only a switched-on option. For example, BluePay must separately enable ACH on a BluePay merchant account before electronic check payments will process. On Payrix, an ACH request can still fail with a merchant-configuration error until the merchant account setup behind it is complete, even after ACH has been enabled in your Rhythm account and console settings.
Tip
Queries and reports do not always show a specific payment method. A payment made by check, ACH, or available credit can appear with its payment method set to blank or “none,” even when the payment record shows a method. A query also cannot tell a debit card apart from a credit card. Check the payment processor’s own transaction view if you need that level of card-type detail.
Why Rhythm Authorizes a Card Before It Charges It
As soon as a payer enters card details, Rhythm sends the card to the processor for an instant authorization, before the order or payment is submitted. This checks that the card is valid and can be charged, including whether the card number matches the billing ZIP or postal code and address. The payer then learns about a bad card or mismatched address right away, instead of after checkout appears finished. Rhythm may send this authorization as a $0.00 charge. A $0.00 authorization only confirms that the card works; it does not mean the actual payment amount was submitted as zero. When a payment covers more than one line item, including a $0 line item, Rhythm can send a separate authorization for each one. Because the processor treats each authorization as its own transaction, it may assess a small fee for each one, even when a line collects no money.
Rhythm checks the billing address you enter against a validated version of that address. If the address is not the exact form Rhythm validates, or it does not match what the card issuer has on file, the authorization can fail even when the card is fine. Rhythm Payments does not have a setting to relax or turn off this address and ZIP check, also called AVS. Changing how it works would require a broader product decision, not a one-off adjustment for a single account or case.
How the Payment Is Charged Through a Processor
After Rhythm chooses a merchant account, that account’s configured processor moves the money according to how your Rhythm account is set up. A few processor-specific behaviors are important:
On your primary processor (Payrix): every environment except your live account routes through the processor’s test system. Payments in a sandbox never reach a real card or bank account, no matter how they are configured.
On Stripe: if the card issuer requires additional authentication, also called 3-D Secure, Rhythm cannot complete that authentication step. The payment fails, and the payer needs to use a different card or payment method. One-click checkout on Stripe also needs at least one of the three checkboxes under Stripe Options in Rhythm to match functionality that is actually turned on in your Stripe account. If none of them match what Stripe has enabled, one-click checkout will not transact even though it appears available. Stripe’s own decline messages come directly from Stripe’s response codes, and Rhythm does not currently rewrite them into friendlier text. If your account uses Stripe for more than one currency, saved payment tokens can keep routing through an older processor path until the token migration to Stripe for that currency finishes. Do not assume every charge is on Stripe just because Stripe is your account’s current processor. A separate dependency, the service Rhythm uses for currency conversion, can also block Stripe’s card-entry fields from loading or block payment processing outright if that service has trouble. If Stripe’s card fields do not appear, especially in a renewal flow, rule out that cause.
If your account is still on an older processor and past its scheduled move date: some card charges through that older processor are deliberately allowed to fail, which prompts the move to the current processor. This affects only new charges; authorizations and refunds through the older processor are not blocked this way. A retry sometimes succeeds. If you see intermittent failures before your processor move is complete, that behavior is expected, and completing the move resolves it. Moving off a legacy processor such as BluePay or Authorize.Net to Rhythm Payments is required, not optional. Rhythm has retired support for those older processors, and you need to complete a merchant account application before your scheduled deprecation date to avoid a payment disruption. Treat a communicated migration date as required and time-bound, not optional. Complete the pre-transition steps promptly. Once they are done, the actual cutover typically finishes within seconds and should not disrupt checkout. After the cutover, new transactions route to Rhythm Payments. Anything tied to a transaction created before the cutover, such as a refund, still goes through the original processor. Turning off or disabling the old processor integration is separate from migrating saved tokens. Disabling it does not move any unmatched token to the new processor, so a member whose card did not migrate still needs to re-save their payment information. The two remedies for tokens that stayed behind are the same either way: migrate the legacy tokens into the current processor, or have members re-save their cards so new tokens are created in the current one.
On Payrix, fraud screening: a payment can be rejected because the payer’s billing address does not pass address validation, even when the card is fine. When this happens, the authorization can still show on the payer’s statement for a while instead of disappearing right away. This can happen whether the order was placed in Orders and Inventory or the payment was received directly through Receive Payment in Finance & Billing.
On Stripe: if the card issuer requires additional authentication, also called 3-D Secure, Rhythm cannot complete that authentication step. The payment fails, and the payer needs to use a different card or payment method.
On BluePay, an older processor some accounts still use: a “duplicate” decline usually means BluePay’s own duplicate-transaction screening blocked a second charge attempt with the same card shortly after an earlier one. It typically clears after some time. Staff with BluePay access can also remove the attempted authorization so the customer can try again right away. BluePay records its decline reason as an auth code on the transaction itself, and Rhythm does not maintain its own catalog of every BluePay decline or error message. On some older BluePay integrations, a failed payment may show only a generic outcome, such as decline or duplicate, instead of an issuer-specific reason like insufficient funds.
If your account is still on an older processor and past its scheduled move date: some card charges through that older processor are deliberately allowed to fail, which prompts the move to the current processor. This affects only new charges; authorizations and refunds through the older processor are not blocked this way. A retry sometimes succeeds. If you see intermittent failures before your processor move is complete, that behavior is expected, and completing the move resolves it.
On Stripe: if the card issuer requires additional authentication, also called 3-D Secure, Rhythm cannot complete that authentication step. The payment fails, and the payer needs to use a different card or payment method.
If your account is still on an older processor and past its scheduled move date: some card charges through that older processor are deliberately allowed to fail, which prompts the move to the current processor. Roughly half of new charges fail this way once the deadline passes while your move is still incomplete. This affects only new charges; authorizations and refunds through the older processor are not blocked this way. A retry sometimes succeeds. If you see intermittent failures before your processor move is complete, that behavior is expected, and completing the move resolves it.
Many workflows use the same processor and merchant-account configuration, including event registrations, membership renewals, exhibit-related payments, and back-office invoice payments. Because of that, one shared configuration problem can affect several transaction types at the same time. If several unrelated payment workflows start failing together, or failures appear in both the Portal and the Console, check for a shared processor or merchant-account issue before treating each failure as separate. When payments suddenly start failing broadly, start by checking the billing ZIP code on a retry. If failures continue across many payments after that, your account may have been temporarily blocked on the processor’s side, which must be resolved with the payment provider directly instead of in Rhythm. A decline that references an authorization or rate limit, sometimes with a reference to your network address, can also mean the processor or one of its partners is temporarily rate-limiting attempts from that connection. Wait a bit and try again, or try from a different network, before escalating further.
Your payment processor may deduct processing fees from each transaction as it settles instead of billing your organization separately. Because of that, a bank deposit can arrive as a net amount after fees rather than the full transaction total. Card and ACH transactions are not necessarily batched or reported the same way. When you reconcile what came in, check your merchant account statement, not only your bank deposit.
Portal checkout can show your payment processor’s own name or logo instead of your organization’s. For example, a Google Pay flow may display the processor’s name. That is expected and does not mean anything is misconfigured.
If a merchant account’s credit card processing mode is set to a range or calculated option instead of enabled, card payments can be blocked until the setting is changed back to enabled. Check this if card payments, including donations, stopped working right after a settings change.
Rhythm’s own payment-entry screens require a cardholder name before a card payment can be saved. If the processor’s transaction records are missing the cardholder name, that points to something happening after Rhythm submitted the charge, not to a user skipping the field during entry.
Warning
Rhythm recognizes certain normalized payment types, such as credit card and electronic check, when it captures a charge. If a payment record ever carries a different type label, the capture step can be skipped while the payment is still recorded as complete, leaving no processor transaction to match it. More generally, a card payment can occasionally succeed at the processor without Rhythm’s record reflecting that success, or the other way around. Check the processor before retrying a payment that showed an error, so you do not create a duplicate charge that later needs a separate refund. A gateway or merchant-account problem on the processor’s side can also appear as a misleading application error, such as one that looks like a login or missing-record problem, instead of a message that clearly points to payment processing. If the merchant account field on a payment screen is unexpectedly blank instead of auto-filled, try reloading the page before assuming the merchant account itself is invalid.
Diagnosing a Failed Card or Bank Payment
If a card payment fails and the customer’s bank says the card is fine, the cause is often the processor, merchant account, or business unit the payment used. Work through those items in order before assuming the card is the problem. First confirm that your account is using Rhythm Payments instead of an older processor still in place. Then check whether the failure affects every card or only one, review the exact error shown, and verify the merchant account configuration.
Rhythm’s error message is not always the most useful place to look. For many processors, especially BluePay and other externally connected gateways, Rhythm passes through the processor’s message directly and cannot edit or clarify it. When you see a generic “unable to process transaction” message, or something similarly vague, the more specific decline reason usually appears only in the payment processor’s own account, if one exists. Check there, or ask someone with login access to check, before concluding the payment record is broken. This also applies to electronic check payments, not only cards. If Rhythm and the gateway are run by different companies for your account, such as with a BluePay integration, Rhythm support does not have access to that gateway account and cannot investigate the decline from the Rhythm side. Someone with gateway login access needs to check it there, or you can contact the gateway or processor directly, since it usually has the best explanation for its own decline.
A vague message such as “Error during order preparation” can still mean the card itself was declined or unusable, even when the message does not say that directly. Retrying with a different card or payment method is a reasonable next step. The error shown to a payer also does not always match the most useful underlying reason. For example, a front-end message about an address mismatch can hide a plain issuer decline, so check the transaction detail when the on-screen text does not seem to fit. By contrast, a checkout error that appears before a payment method is submitted, such as a message saying no payment method has been entered, is a form-validation message rather than a gateway decline. Troubleshoot it differently from an actual processor decline.
A few checks can help you narrow down where the failure is happening:
- Retry the same card through Quick Charge in Rhythm Payments. Comparing the result helps you tell whether a decline is tied to the original checkout flow or screen, or whether it is a broader processor or bank response that would happen no matter how the charge was submitted. The same approach can help isolate whether an ACH problem comes from your processor configuration or from the Console or Portal, or whether an invoice-payment failure is specific to that workflow instead of a broader authorization problem.
- Open the transaction in the payments portal and follow its linked merchant account, rather than relying on the merchant account’s display name, to confirm which account actually processed a charge. This matters most when two merchant accounts have similar or identical display names. The balance shown for a merchant account is the amount available to be paid out, not a way to confirm whether a specific transaction routed to that account. Use the linked-transaction check instead.
- Confirm which processor or gateway integration is actually active before you run a checkout test. It is easy to test against the wrong one and mistake a routing difference for a broken payment.
- A payment Rhythm declines can still succeed when you run the same card again directly in the processor’s own console. That is useful confirmation that the decline was specific to that attempt, rather than proof that Rhythm mishandled the charge.
- A different payment completing successfully around the same time is useful evidence that payment processing itself is working, even while you troubleshoot one failed transaction. A card can still be declined because the issuing bank placed an alert on it, which is a bank-side block rather than a sign of a broader problem.
- A visible transaction in Rhythm Payments with a status such as “Transaction declined,” along with its own transaction ID, means the attempt reached the processor and came back with a decline. That is a payer- or processor-side result, not a sign of a platform-wide problem.
| What you see | What it usually means | What to check |
|---|---|---|
| A generic “unable to process transaction” message, or a disabled or misconfigured merchant account appearing as a billing-address error | The processor returned a plain decline without a specific reason, or checkout is pointed at a disabled merchant account | Check the processor or merchant account for a more detailed decline code; confirm the merchant account used for checkout is active, not only that the business unit is correct |
| “Invalid Merchant ID” | Despite the wording, this often points to a billing-address mismatch or an issuing-bank decline, not a broken merchant-account setup | Verify that the billing address matches the card, or have the payer contact their card issuer |
| An address or ZIP mismatch, sometimes shown alongside a card that otherwise checks out | The address entered does not match the card issuer’s records, or it does not match Rhythm’s validated version of the address, even when the address looks correct to you | Re-enter the billing address exactly as the address field suggests; if you are confident the address is correct, ask the payer to verify it directly with their card issuer, since issuer-side restrictions can look like an address mismatch |
| A CVV or security-code error | The code entered does not match the issuer’s records | Ask the payer to re-enter the card’s security code; the error text can use a brand-specific term, such as an AMEX security-code name, even when the saved card is a different brand, and that wording does not mean Rhythm misidentified the card |
| "User authentication failed due to invalid authentication values" on an Authorize.Net account | Authorize.Net rejected Rhythm's own request to the gateway; this can affect saving a new card and checking out with one the same way, since both send the same kind of request | Contact Support with the error details |
| "International transactions are not allowed," shown even though your account accepts them | The card issuer, or fraud screening on the processor's side, is usually blocking the transaction rather than a Rhythm-side restriction | Ask the payer to contact their card issuer; contact Support if it keeps happening for a country you accept |
| Decline code 51 | The card issuer reported insufficient funds, so this is not a Rhythm problem | Ask the payer to try a different card or contact their bank |
| A decline the issuing bank or card network flags as fraud, or an international decline tied to fraud screening such as FraudSight | The card issuer, card network, or your payment provider’s fraud controls are involved, separate from anything configurable in Rhythm; an international decline may require a merchant-side fraud-setting change and direct contact with the fraud-screening provider | Ask the payer to confirm with their bank, or contact your payment provider, or the fraud-screening provider directly, for a provider-side or fraud-screening block |
| Card payments failing account-wide with no clear cause | The provider may have blocked the account, often after suspected card-testing, or “carding,” activity; CAPTCHA can help deter repeated automated attempts | Contact your payment provider to confirm and lift any block; consider enabling CAPTCHA on public payment pages if this recurs |
| Payments failing only from a VPN, hosted card fields not appearing at all, or staff unable to apply payments in the back office | Some payment providers block VPN traffic or certain countries as an anti-fraud measure, and Rhythm cannot override that; staff applying payments in the back office can be blocked the same way | Disconnect from the VPN and retry; for a public payment page, treat this as provider anti-fraud behavior, not a Rhythm defect, so there is no bypass |
| Card brand shown incorrectly, such as an American Express card displayed as Visa, in the Console, a receipt, or a confirmation email | This is a display-only mismatch; the payment processor’s transaction record is the accurate source for the actual card brand. This has been resolved on some processors but may still appear on others | Compare against the processor’s transaction record if the brand matters; this has affected some public payment flows too, occasionally causing the payment itself to fail |
A few other patterns are worth knowing:
- If payment error text mentions your prior processor, such as Authorize.Net, after your account has moved to Rhythm Payments, that reference can be misleading. The real cause is often an address mismatch or incomplete merchant-account setup, not the old processor.
- If several different saved cards all fail with the same expiration-style error, the pattern points to a processor or processing-path issue rather than any one card record.
- A card-save failure in the Portal can come from gateway configuration even when it happens with “Enable test mode?” both on and off. Do not assume the test-mode setting caused the problem just because it was set one way when you noticed the issue.
- A BluePay sandbox decline can mean the BluePay merchant account is not configured to allow the transaction you are attempting. BluePay itself may also need to enable test-card processing for that account.
- A payment submission that seems to hang, instead of showing an error right away, can still resolve as a decline from the cardholder’s bank. If that happens, the payer should contact their bank for the reason.
- In rare, unconfirmed cases, a payment may route to an older, already-retired processor even though your account’s current processor is Stripe and no old saved payment method is involved. If you see this with no clear explanation, contact Support so it can be investigated.
If you contact Support about an intermittent payment failure, include the exact date and time of the attempt, the error message or a screenshot, and the browser and device used. Those details help the investigation.
A charge that shows on a cardholder’s statement is not always a completed payment. It may be only a pending authorization, which is a hold rather than a finished charge. A pending authorization clears on the cardholder’s bank’s timeline, not Rhythm’s, so it can stay on a statement for a while even when Rhythm shows nothing pending.
Settlement, Reserves, and Payouts to Your Bank Account
A card payment moves through more than one state on its way to your bank account. Seeing more than one state does not mean the customer was charged more than once. Authorization, capture, and settlement are separate stages of the same transaction. An authorization can show as approved before the charge is captured and settled, and a payment can have only one eventual settlement even though earlier states are visible in the processor’s records.
Settlement is not the same as a payout. Your processor can mark a payment settled and still delay the payout to your bank account, most often because it placed the transaction or your account on reserve for risk review. If a payment shows as settled in your Rhythm Payments dashboard but the deposit never arrives, check whether a reserve is in place before assuming the money is missing. A payout shown as a negative amount often does not mean money was taken from you. The processor may be using incoming funds to pay down an outstanding balance on your payments account instead of transferring them to your bank account.
A payment can also show as approved in your processor without being settled, while Rhythm still shows the related invoice open or a renewal not completed. Approval alone does not mean your invoice has been paid. Confirm settlement, not only approval, before treating the transaction as finished.
If a payout is rejected, your processor may pause further payouts until the reject is resolved. The resolution depends on the reject reason. A bad-account reject can require you to prove your banking details, such as with a bank letter confirming the account is valid. An unauthorized reject can require your bank to whitelist your processor’s funding IDs and confirm it will accept the processor’s credits and debits. After you switch your payout bank account, double-check the routing number too. An incorrect routing number on an otherwise correct new account can still cause payouts to fail until it is corrected.
Disabling your Rhythm Payments merchant account’s processing stops new credit card transactions from going through it. It does not stop funds from already processed transactions from being paid out to the bank account linked to that merchant account.
Testing Payments Without Moving Real Money
You can put a merchant account into debug mode to simulate every charge and refund made through it instead of sending those transactions to the real processor. Debug mode applies to every payment through that merchant account, in every environment, including Portal and public payments. A merchant account in debug mode never moves real money, no matter who pays through it. You turn debug mode on or off from the merchant account settings, not from the payment screens.
Warning
Debug mode affects every payment through the merchant account, including payments members make on their own. Before you enable it, make sure you are not simulating payments your Rhythm account still expects to collect.
Debug mode does not change how Rhythm validates a card when you add or save it as a payment method. Even with debug mode on, adding or vaulting a card still must pass the gateway’s normal card-number checks. A fake or clearly invalid test card number can still be rejected before vaulting completes. Debug mode takes effect only when a real charge attempt happens after that. In some cases, saving a card can show an address-mismatch error even when the billing address is correct, while the underlying authorization still reaches the gateway and appears successful in the payments portal. If you see that combination, check the payments portal before assuming the save failed outright. If you ever see real activity in your payment gateway from a merchant account you believe is in debug mode, check whether debug mode was turned on at the time. A merchant account in debug mode is not expected to reach the gateway at all.
Testing on a live processor’s own sandbox has its own quirks. On Payrix, keep validation test transactions under $5, since larger amounts have been unreliable during testing. Some sandbox test cards only succeed with certain whole-dollar amounts, such as an odd or even amount depending on the card. If a sandbox card declines, try a different whole-dollar amount before assuming the integration is broken. For BluePay, turn on test mode from Security & Settings › Blue Pay so credit cards are not actually processed, then use the gateway’s designated test card number, which Rhythm recognizes as a test card. Authorize.Net has its own test-mode setting in its integration settings in Rhythm. Check that setting too if a merchant account’s transactions are not behaving as you expect. If you use Stripe with a connected account, test checkout transactions show up in your own connected Stripe account, not in a separate platform-level sandbox. Look there to confirm a test charge went through.
Tip
Placing a small real order through your online store is a valid end-to-end test of whether Rhythm can authenticate to and submit a transaction through Authorize.Net. It uses the same connection a live checkout would use. If Support is troubleshooting a payment issue with you, they may ask permission to add a test card and run a small live transaction as part of the investigation. That is a normal way to confirm whether processing is working.
Charging Through an Inactive Merchant Account
An inactive merchant account cannot be used to charge a new payment. Rhythm refuses the payment and shows a message that points you to choose an active account. Refunds and authorizations are not blocked the same way, so you can still refund an older payment after the merchant account that processed it has been retired.
A merchant account does not have to be explicitly set to inactive to stop working this way. An incomplete merchant-account setup, even one that looks fine in one place but was never fully finished in Rhythm Payments, can cause the same kind of failure. When card purchases will not go through, check the merchant account’s setup, not only whether it is active or inactive. In some cases, the account can also be blocked or inactive on the gateway side, such as in Payrix or GlobalPay, without Rhythm showing that clearly. That is not necessarily an application problem, and getting it working again may require following up with the gateway’s own support rather than changing something in Rhythm.
Tip
If you need the BIN, or bank identification number, for a failed transaction and cannot see it yourself in Rhythm Payments, you may need to contact Payrix directly. Rhythm support does not always have access to retrieve that detail.
Rhythm Payments Access, PCI Compliance, and Getting Help
You can find your Rhythm Payments merchant ID, or MID, in the Console under Security and Settings, in the Rhythm Payments integration. Rhythm Payments uses that MID to link your Console account to your Rhythm Payments account. Use that value if an external system or integration needs to point to the right merchant account.
Rhythm Payments collects card information through a secure iframe. Cardholder data does not pass through Rhythm or get stored in the Rhythm platform. Payrix, the payment processor, handles that data. Because of that, Rhythm is out of scope for PCI questions that are really about the processor, such as evidence of ASV scanning or the processor’s own compliance documentation. Those items come from Payrix, not Rhythm. If a PCI questionnaire asks about your “ecommerce partner” or “ecommerce website provider” and you use Rhythm for your storefront but a separate merchant account for processing, that question is usually about the merchant services provider, not Rhythm as your storefront. The Attestation of Compliance to provide is the payment processor’s own AoC, since the processor is the PCI DSS Level 1–compliant party handling the actual payment data. Rhythm does not generate that attestation itself.
Setting up a Rhythm Payments merchant account is separate from a legacy processor relationship such as BluePay, and it can require different information. It often asks for bank statements or processing statements from the last few months because the review covers PCI, SOC2, security, and financial-regulatory requirements that a prior processor relationship did not need to satisfy. Approval of that application is not the last step. Once approved, the merchant account still must be set up inside Rhythm and associated with the right settings before it can be used. Access to review transaction information is not granted until underwriting is fully complete and approved.
Tip
Signing in to Rhythm Payments is separate from signing in to the Rhythm Console or Portal, and it can use a different username than your regular email address. Losing access to your Rhythm account does not necessarily mean losing access to Rhythm Payments. That depends on who previously administered the payment account, because the two logins are not tied together. Reporting access in Rhythm Payments also depends on your user being correctly linked to the right company or merchant account. If you can sign in but are only prompted to choose a company or merchant account without seeing the report you expect, that linkage is usually the reason, and your customer success contact can help sort it out. Rhythm Payments also organizes access through “teams” whose labels can stay generic, such as “Default Team,” and do not always identify which account they control. Once you have confirmed which team is yours, rename it to something descriptive so this is easier for your organization going forward.
For changes that must happen on the processor side instead of in Rhythm, such as updating the bank account your payouts settle to or closing a merchant account entirely, make the change in the Payrix/Worldpay platform itself, not in the Rhythm payment portal. Rhythm support can help route that kind of request but cannot make the change directly. If you need Payrix’s own support to review a decline or account issue, go through Rhythm Support rather than opening a ticket with Payrix directly. Because of how the Payrix partnership is structured, Payrix’s support team cannot work tickets that end users open themselves, so Rhythm Support opens and manages that case for you.
Related
See the related articles for setting up merchant accounts and business units, receiving payments day to day, and what members see when they pay in the Portal.