Rhythm connects to Authorize.Net, BluePay, Rhythm Payments, and Stripe through payment processor account records you create for each processor. Each record stores the credentials or connected-account ID Rhythm needs to run card and bank transactions. This record is separate from the merchant account you set up in Finance & Billing, which points to the processor account described here.
Prerequisites
You need to be signed in to Console for your Rhythm account. This article does not name a specific permission; the screens you can use depend on your Console access.
Where to Find It
Go to System & Security › Integrations and open the card for your processor:
| Processor | Screen |
|---|---|
| Authorize.Net | Authorize.Net |
| BluePay | BluePay |
| Rhythm Payments | Payrix |
| Stripe | Stripe |
Each screen shows every account of that type connected to your Rhythm account. Select Create [Processor] Account to add an account, or open a row to edit one.
Connecting an Account
- Open the processor’s screen and select the create button, such as Create Blue Pay Account.
- Enter a Name for the account. Rhythm suggests an ID from the name; you can change it before you save, but not afterward.
- Enter the credentials or identifier your processor requires, using the table below.
- Choose whether the account should run in test mode, if your processor offers that option on this form.
- Save the account.
Result
The account appears on the processor’s list, is marked Active, and becomes available for your business units to use in Finance & Billing.
Warning
Adding a processor’s name under bank accounts in Finance & Billing does not create a Payment Processor Account. Configure the processor here, under Integrations, first. For example, open the BluePay integration and save an account here before you look for it in merchant account setup.
| Processor | What you enter | Test mode |
|---|---|---|
| Authorize.Net | Login ID and Transaction Key | Enable test mode? checkbox |
| BluePay | Account ID and Secret Key | Enable test mode? checkbox |
| Rhythm Payments | Merchant ID — the Payrix merchant your account is paid into | None on this form |
| Stripe | Connected Account ID — the Stripe connected account your account uses | None on this form |
Authorize.Net and BluePay credentials are entered in plain text, and they appear unmasked when you reopen the account to edit it. Treat this screen like any other record that holds sensitive account information, and limit Console access to Integrations to the right people in your organization.
When you or Support need a processor’s merchant ID for a backend change, verify it from this integration record in your Rhythm account. This is important for work such as coordinating a payout or account update directly with the processor, because an ID saved elsewhere can be out of date or belong to the wrong account.
Warning
Rhythm does not stop the same Rhythm Payments merchant from being named in more than one Rhythm account, and it does not stop you from creating a second account for a processor you already use. If your association has only one merchant with a processor, keep one account unless you have a specific reason to add another. See below before you do.
Rhythm Payments and Stripe: The Second-Account Warning
If you try to create a second Rhythm Payments account or a second Stripe account when you currently have exactly one, Rhythm shows a warning before you save. Adding a second account of either kind changes how Rhythm stores payment methods. Instead of tying a saved card to the one merchant it was saved against, saved methods become usable across any merchant for that processor on your account. The warning calls out two specific consequences:
- Any card or bank account already saved under your existing merchant will not work on the new one.
- Digital wallets, including Google Pay and Apple Pay, stop working once a second account of that processor exists.
This change takes effect as soon as you save, and there is no confirmation step beyond the warning itself. Read the warning before you continue. If your organization is considering a second processor account for either of these processors, talk to your Customer Success Manager or Support first.
Authorize.Net and BluePay: Risks of a Second Account
Rhythm is built around one active payment processor account and one active merchant account per processor at a time. Support has seen an extra active Authorize.Net account interfere with saving cards or processing orders, even for a business unit that was never assigned to that extra account. If you have an Authorize.Net account you are not using, consider setting it inactive. In cases Support has reviewed, deactivating an unused, active Authorize.Net account restored card processing, and reactivating it reproduced the same failure. Treat this as a temporary workaround rather than a permanent setup, and check with Support before you rely on it.
If you are adding a second BluePay account, check with BluePay first. Authorizations that rely on stored transaction references can require shared token functionality to be enabled across your BluePay accounts. Support has seen payment attempts against a non-default BluePay account fail until that setting was turned on. Shared tokens are not something you can turn on from Rhythm’s BluePay integration screen; your BluePay account representative has to enable or confirm it.
Changing Who Manages a Rhythm Payments Account
Dispute notices and other account-administration emails for Rhythm Payments come directly from Payrix. If the staff member who originally set up your account leaves, replacing them is not a normal Rhythm user change. It means deactivating the old user and establishing a new principal, or control person, directly in Payrix rather than in a Rhythm user profile. Contact Rhythm support to make that change.
Removing an Account
Open the processor’s list and use the row’s delete action to remove an account you no longer use. Deleting is permanent. Rhythm does not check whether a business unit’s merchant-account setup, a queued transaction, or a page still depends on the account before removing it. If something still depends on the account, that dependency fails instead of blocking the delete. If you are not sure whether an account is still in use, check your merchant accounts in Finance & Billing first.
Deleting the account record here does not close your merchant account with the processor, and it does not stop the processor from billing your association. Disabling or removing an account in Rhythm only stops Rhythm from using it. To fully close a merchant account, contact the payment processor directly.
Authorize.Net setup can live in more than one place in Rhythm. The processor account here, under Integrations, is separate from the merchant account you set up in Finance & Billing. Before you delete an Authorize.Net account, check both areas. A leftover reference in the other one can cause confusing failures even after this record is gone.
Stripe: Choosing Which Account Payments Use
If you have more than one Stripe account connected, Finance & Billing’s Collect settings decide which account Rhythm uses for each Stripe operation. Depending on those settings, Rhythm acts on your primary connected account or on Rhythm’s own platform account. Changing which account is primary, or switching modes, changes where new customers and cards are created. Payment methods already saved under the old account keep pointing to that account. If your Stripe setup needs more than one connected account, review your Collect settings alongside this change.
Collect settings also control whether payers see Stripe’s Link, Cash App Pay, or PayPal as extra payment options; the Stripe account record does not. These options are only offered in USD. Other currencies never show them, regardless of how Collect is configured.
Beyond Link, Cash App Pay, and PayPal, the full set of payment methods a payer sees during portal checkout comes from your Stripe connected account’s own enabled-payment-methods configuration, not from a Rhythm setting. If checkout shows a payment option you did not expect, check which payment methods are enabled on that Stripe account before assuming it is a Rhythm issue.
The Stripe setup you use also changes what you can see in Stripe afterward. With one connected account per merchant, or direct charges, that Stripe account owns the charge and customer records. Full payment details are visible there, but you can use only one Stripe integrated account. With multiple merchant accounts sharing one Stripe connection, or destination charges, a saved payment method can work across your merchants. In that setup, the connected account’s payment list in Stripe shows a transfer-related payment object instead of the original card charge. That object may not show the card brand, last four digits, customer, or description you expect, and its identifier may not match the payment’s identifier in Rhythm.
Refunds you process in Rhythm for a Stripe connected-account payment should appear both in Rhythm and in that connected account’s own Stripe records. Support has seen a case where a refund did not show up in the connected account for a time before the behavior was corrected. If a refund is missing from your connected Stripe account after you process it in Rhythm, contact Support.
If the Stripe account ID stored in Rhythm does not match your actual Stripe account, saving a new card or bank account can fail with a Stripe error such as "No such customer." Correcting the stored Connected Account ID to the right Stripe account resolves it.
Support impersonating your Rhythm account to help you does not give them permission to add team members inside your connected Stripe account. If you need to give a colleague Stripe access, someone who already has administrative access in your Stripe account needs to invite them there directly.
Warning
Changes to the Stripe account record are not tracked in an audit log you or Support can review. If the Connected Account ID changes unexpectedly, Rhythm cannot tell you who changed it or when.
Rhythm supports two ways to structure multiple Stripe accounts, and each comes with a tradeoff. One approach lets a single saved payment method be reused across more than one connected account, but limits what each connected account can see in its own Stripe payment list. The other gives each connected account full visibility into its own charges, customers, and cards, but constrains your setup to a single Stripe integrated account rather than letting a saved method work across several. You cannot currently have both cross-account reuse of a saved method and full per-account visibility at the same time. Talk to your Customer Success Manager or Support about which tradeoff fits your organization before setting up more than one Stripe account.
Verifying BluePay Credentials
If a BluePay payment is not behaving as expected, you can double-check the credentials Rhythm is using. Open System & Security › Integrations › BluePay, edit the account, and review the Account ID and Secret Key stored there. Confirming that the stored credentials match what BluePay issued is a reasonable first check, but credentials are not always the cause of a processing problem. Use your processor’s dashboard for transaction-level detail.
The same first check applies to Authorize.Net. Even when the Login ID and Transaction Key stored in Rhythm look correct, Authorize.Net can still reject them, such as when the key is no longer active on Authorize.Net’s side. If Authorize.Net rejects credentials that match what you expect, verify with Authorize.Net why they are being rejected. You may need to generate a new set of API keys if Authorize.Net cannot explain it. An error stating that the VITAL identification numbers are incorrect points to the same kind of mismatch. The values in your Authorize.Net integration settings do not match your merchant account’s information at Authorize.Net, rather than indicating a failure of the connection itself. Compare the two and correct whichever side is out of date.
If a bank-account, ACH, or eCheck payment through BluePay fails, do not assume your account’s merchant configuration is the problem right away. In cases Support has investigated, a failure that looked like a configuration issue turned out to be a broader defect instead, so check with Support before reconfiguring anything. If ACH processing has never gone through successfully on an account, BluePay’s own Virtual Terminal may need one ACH transaction run directly in it to activate ACH processing before Rhythm’s payments will go through.
Moving Saved Payment Tokens to a New Processor
Switching processors does not automatically bring your members’ saved cards and bank accounts with it. Moving those saved payment tokens is a coordinated request between your prior processor, the new processor, and Rhythm. Plan for it as its own project, not as a side effect of connecting the new account.
Rhythm can initiate the transfer request only for a payment provider relationship Rhythm manages. If your prior processor account was not managed by Rhythm, you need to contact that provider directly to request the export and coordinate the secure transfer with the new processor. Exporting from your old processor and importing into a new one use different request forms and require different details from each side. Rhythm engineering can tell you which one applies to your migration. Requesting every existing token from your prior processor in one bulk export can carry processor costs. Limiting the request to members with a stored card or an active auto-renewal, rather than every token on file, can reduce that cost. Your prior processor will also likely need a list of the specific transaction IDs to identify which tokens to include.
For a migration to Stripe specifically, your prior payment provider needs to securely export the saved payment data directly to Stripe using Stripe’s own migration process. The export is encrypted with Stripe’s PGP key and delivered to a Stripe-provided SFTP account. If your prior provider needs SFTP credentials to do this, they may receive them through their own PGP key or a secure phone contact.
For a migration from Authorize.Net to Rhythm Payments, a support request must be submitted through Payrix’s support portal within 7 days after Authorize.Net pushes the token export to its SFTP server, so Payrix can pick up the file. Payrix’s support portal may require you to create an account there before you can submit that request. After Payrix imports the tokens, Rhythm receives a follow-up file that it uses to associate the imported tokens with the right records in your Rhythm account.
Rhythm Payments: Account Setup and Payouts
Setting up a Rhythm Payments, or Payrix, merchant account involves your processor as well as Rhythm. Some steps happen entirely on the processor’s side.
- Onboarding must finish completely before the merchant can process. If the original application was never fully completed, the merchant can remain inactive, and Payrix may require a brand-new application before it can be activated. The primary account holder may also need to verify their email as part of that process; if the verification prompt still shows as incomplete, redo it.
- Verification is per merchant account, not per organization. If your association has more than one merchant account, the payment provider may ask for identity verification documents separately for each one. Finishing onboarding for one merchant account does not mean a second one is ready to process payments.
- A merchant can be temporarily held. A payment can fail with an error referencing a missing merchant when the specific Payrix merchant behind the transaction is in a held or not-fully-boarded status at the processor. This can happen even when the Merchant ID stored in Console is correct and another merchant account in the same Rhythm account still processes normally. Support may need to ask the payment provider’s risk team to release the hold. An error such as "Unknown processing service: integrations-payrix-accounts" during a card save in portal checkout or renewal points to the same kind of problem: the merchant account is not connecting correctly to the processor.
- Changing a control person or executive requires formal documentation. Submit a ticket through the Payrix Support Portal to request the change; Payrix will ask you to upload approved supporting documentation through a secure link.
- Payout bank changes need matching documentation. Updating the bank account your payouts go to can require a bank letter or other supporting documentation, and the processor can hold the update until the account details match exactly what it has on file.
- A new payout account is not automatically primary. After you add a second payout bank account, the control to make it primary can be greyed out or unavailable to you. Changing the primary payout account can require Rhythm to coordinate that change with the processor on the backend.
- Reserve holds sit outside normal payout visibility. A payment provider’s risk team can place a reserve hold on funds that is separate from your usual payout review. A deposit only appears once that hold is lifted. If a payout seems delayed for longer than expected, contact Support so they can follow up.
- Enable Payrix’s email alerts to hear about payout issues sooner. Turning on Email Alerts within Payrix notifies you about certain payout problems, rather than requiring you to notice a missing deposit on your own.
- Use Support for processing questions, not the payment processor’s in-product messaging. Rhythm cannot confirm whether messages sent through the message area inside Rhythm Payments are monitored. For ACH or other payment-processing issues, contact Support directly instead.
Business units, general ledger accounts, and the merchant accounts that connect them to one of these processor accounts are set up separately in Finance & Billing.