A merchant account connects one business unit to one payment processor account, one general ledger (G/L) account, and one currency. With that connection, the business unit can accept card and bank payments. A business unit can use more than one merchant account, such as separate accounts for different currencies or processor accounts.
Prerequisites
- You need the merchant accounts permission in Setup.
- The business unit, its G/L account, and the processor account you want to use should already exist. Set up the processor account first under System › Integrations, and confirm its G/L mappings before you create the merchant account that points to it.
- To use the newer Rhythm Payments (Payrix) setup, your Rhythm account must be enabled for it and must already have a Payrix account under System › Integrations › Payrix.
Where to Find It
Go to Finance & Billing › Setup › Merchant Accounts to see merchant accounts for the business unit you are working in. Switch business units to see another unit's accounts. Select Create Merchant Account to add one, or open a row to edit it.
If you expected to see a merchant account and do not, check permissions and business unit access separately before you assume it is missing. A missing menu entry usually means you do not have the merchant accounts permission. An empty or unexpected list usually means you are working in a different business unit than the one that owns the account. When you troubleshoot someone else's access, confirm the exact username and page they are using, because a different login or admin view can make an account look missing or present.
Tip
Every card payment eventually needs to settle to a bank account, but your processor's payout schedule controls when the processed transaction reaches your bank. This setup screen does not control payout timing.
Setting Up a New Processor Account
Before you point a merchant account to a processor account, set up the processor account itself. Some processors also require boarding with the processor.
- Rhythm Payments (Payrix). Request a new merchant account by completing the Rhythm Payments application, using the Rhythm Payments Portal User Guide. The “merchant boarding form” mentioned in that guide is the same application, not a separate step. If you need more than one merchant account, complete a separate Rhythm Payments application for each one, then let Support know so they can coordinate with the payments team. You may need more than one when multiple business units should settle to different bank accounts, or when you are migrating an association that already has several processor merchant accounts. If a merchant account looks stuck inactive, Payrix onboarding may not have finished, and you may need to submit a new application to complete it. The application asks for a “principal,” which means the person responsible for making decisions for your organization, not a specific title. After boarding is complete, one Rhythm Payments login can have access to more than one merchant account, so the user can switch between them from a dropdown in the Rhythm Payments interface without custom development.
- BluePay. You can create a test BluePay account yourself from Security and Settings, but Rhythm does not store the required Account ID and Secret Key. Get them from BluePay and enter them exactly. A placeholder like “TEST” is refused because the Account ID field only accepts numbers. If your business unit uses more than one BluePay merchant account, contact BluePay to enable token sharing across your BluePay accounts. Without token sharing, a payment charged through any merchant account other than your first one can fail even when the account is set up correctly. Bank-account (ACH) payments also require ACH to be enabled on the BluePay account itself, so confirm that with your BluePay representative if electronic check payments are failing.
- Authorize.Net. After you create an Authorize.Net account, generate its API credentials and enter them exactly as Authorize.Net issued them. A stray character or extra space in the Login ID or Transaction Key causes authentication failures. Keep only one active Authorize.Net configuration for your account, because more than one active configuration at the same time can interfere with live payment processing.
If an external processor outside Rhythm Payments cannot be made to work, such as when you cannot get working credentials from it, moving to a different processor is a separate implementation project. Contact Support to start that conversation.
The Settings
| Setting | Options | Default | Effect |
|---|---|---|---|
| Name | Any text | Empty; required | The label shown in pickers and lists |
| ID | Letters, digits, underscores, hyphens, and vertical bars | The business unit's identifier, added for you | Must start with the business unit's identifier and cannot be changed after you save |
| Business Unit | The business units in your Rhythm account | The business unit you are working in | Controls which unit's payments can use the account and cannot be changed after creation |
| Payment Processor | Depends on your Rhythm account's current processor, plus BluePay and, if enabled, Authorize.Net | BluePay | The processor this account uses for charges |
| Processor Account | The processor accounts your Rhythm account has in Integrations, for the chosen processor | None; required | The specific processor account that receives the money |
| G/L Account | Any G/L account in your Rhythm account | None; required | The account that records the money held by this merchant account |
| Currency | A three-letter currency code your business unit accepts | — | The currency this account charges in |
| Statement Descriptor | Text, set with your processor | Your association's legal business name | The name shown on the payer's card statement and in the payment preview; it can be shortened from your full legal name |
| Debug Mode | On, off | Off | See below |
| Status | Active, inactive | Active | See below |
| Legacy Processor #1 and #2 | On/off, each with a processor, a processor account, and a cutover date | Off | Records an earlier processor so refunds for older payments still go to it |
Warning
A new merchant account in the Console starts with BluePay selected as its processor, no matter which processor your Rhythm account actually uses. If you do not change this field, you can create a merchant account on the wrong processor. Always confirm the Payment Processor field before saving.
Tip
If your processor is Stripe, decide carefully whether you need more than one merchant account before you set up the first one. Most associations only need a single merchant account, and that is the setup to choose if you are not sure. Changing between a single- and multi-merchant-account Stripe setup after you are live requires Rhythm engineering, so it is not a simple settings change later.
The currency must be one your business unit accepts, and the ID must start with the business unit's own identifier. Rhythm checks both requirements every time you save the account, including on later edits. The currency you choose here also has to be supported by the underlying processor account and its settlement bank. Pointing a currency to a processor account that settles in a different currency does not convert anything; payments still process in the processor account's own currency.
The Statement Descriptor comes from your processor account, not from this screen. To change it, you usually need to ask your payment provider to update it, and the change can take effect a little after the request. Because the descriptor can be a shortened version of your legal business name, a payer's bank may show a slightly different name in a text alert than Rhythm or the statement shows. That is normal, and the payer can confirm the charge with their bank if the name looks unfamiliar.
When you create an additional BluePay account, the Create BluePay Account screen tells you to enable shared tokens in BluePay for that account. Do that before you rely on saved payment methods carrying over correctly between your BluePay accounts.
To offer Google Pay as a payment option, first submit a Rhythm Payments application. After that application is in place, Google Pay is enabled by request through a separate support request. You do not turn it on yourself from this page.
If your account has a scheduled Payrix migration date, a banner appears in the console during the 10 days leading up to that migration to give you advance notice.
Debug Mode
Turning on Debug Mode makes every card or bank payment charged through that account succeed automatically, without contacting a processor or moving money. Use it only when you need to walk through a payment end to end while testing. The merchant accounts list does not mark accounts that are in debug mode; only the edit form shows an alert. Turn debug mode off before you use the account for real payments, because nothing prevents a live account from being switched into debug mode by mistake.
Tip
A sandbox refresh can replace a test processor configuration with your live account's actual processor details. If your sandbox's merchant accounts stop working for test payments after a refresh, check whether the processor and processor account are still the test values you expect. Recreate the sandbox configuration if they were overwritten.
Debug mode does not need a real card when you test saving a new card in the Console. A dummy test card works because vaulting a card for a debug-mode account does not attempt a real authorization for that step. This deliberate change lets debug mode complete a Rhythm workflow, such as an order, with a test card instead of requiring real card authorization. If a test transaction does not behave the way you expect, the merchant account's audit log shows when debug mode was turned on or off, which can confirm whether it was in the state you expected during testing.
Deactivating an Account
Setting an account's status to inactive keeps its history, refunds, and postings, but removes it from choices for new payments and from the account default.
Warning
Saved payment methods keep the token for a deactivated account. When a payment uses one of those saved methods, Rhythm refuses the charge because the account is inactive. Members with a saved card on a deactivated account cannot use it until you reactivate the account or they add a new payment method.
Deactivating a merchant account by itself does not stop every path payments can still take to it. If you want to fully stop payments for a period of time, also turn off credit card processing and any other payment options in the relevant application's settings. A payment can still be accepted through those settings even after the account it would use is inactive.
Reordering Accounts
When a business unit has more than one merchant account, drag the accounts into your preferred order on the list. Rhythm saves each account's new position when you drop it. If one move fails partway through, the list can be left partly reordered, so reload the page and check the order if you are not sure it applied.
Recording an Earlier Processor for Refunds
When you switch a business unit to a new processor, payments taken before the switch still belong to the old processor. Turn on Legacy Processor #1 to record that old processor, its processor account, and the exact date and time the switch happened. Refunds for payments made before that moment then go back to the processor that took them. If your business unit switched processors twice, turn on Legacy Processor #2 as well; its cutover date must be later than the first one's.
You also need a legacy processor when a merchant account moves to a new configuration on the same processor, such as a new Stripe setup, if refunds for transactions taken under the earlier configuration should still reach it. Record the earlier configuration as the legacy processor the same way you would for a full processor change. When you switch an account to Stripe, use the legacy processor fields to carry over the values from the prior gateway so refunds of older payments keep working.
If your business unit migrates through more than one earlier processor over time, you can record both legacy slots with their own cutover dates. Transactions from before the first cutover refund through the oldest processor, transactions between the two cutovers refund through the middle one, and transactions after the second cutover use the current processor.
Every payment record carries its own Legacy Processor value once a merchant account has one recorded, so you can query for it to find which payments ran under the legacy processor after a cutover.
The cutover date and time also decide routing going forward. Any new transaction from that moment on charges through the new processor you set as the merchant account's Payment Processor, while refunds for anything before it still route to the processor recorded as legacy. If your account's fiscal period spans the cutover, expect reporting for that period to show activity split across both processors. Your finance team decides whether to close the legacy processor account entirely after the cutover passes. Rhythm keeps the legacy processor recorded here for refunds regardless.
Warning
Once Legacy Processor #1 is turned on and saved, only Rhythm staff can change or clear it, and everyone else sees it locked. Legacy Processor #2 is not locked the same way after it is saved, so treat any change to it with the same care you would give the first. The Console offers Stripe as an option for Legacy Processor #1, but the save is refused if you choose it there. Stripe is only accepted in the Legacy Processor #2 slot. Saving has also been observed to fail with a validation error asking for "Legacy Payment Processor Info 2" even when you're not configuring a legacy processor at all, including right after choosing Rhythm Payments (Stripe). Separately, the required fields for Legacy Processor #2 have been observed to block a save even while that block is turned off and hidden on the form. If you run into either issue, try turning Legacy Processor #1 on and back off before saving. Contact Support if the save still does not go through.
When your Rhythm account is scheduled to migrate to a new processor, staff who sign in before the migration date see an informational banner if no accounts have been set up yet with the new processor. During the final week before the migration date, that same banner becomes a red warning that the old processor will stop being supported after the date passes. A related message warning that customer payments may be failing is meant to appear only after the migration date has passed and your replacement merchant account setup is still incomplete. If you see it before that date, it is showing early rather than describing a current problem. Migration notices are usually sent to a specific administrator on your account. If you see one of these banners but did not see an earlier notice, check with your other administrators or contact Support to find out what steps are still needed.
If you are moving saved card and bank tokens to Stripe from a prior gateway, Stripe may require your prior processor to export that saved-payment data directly to Stripe. The export must be encrypted with Stripe's own key and delivered to a secure destination Stripe provides. This exchange happens between your prior processor and Stripe, not inside this screen. Coordinating a token migration with Payrix can also require referencing your original request to have the prior gateway extract those tokens in the first place, so keep that reference handy if the import stalls.
Dependencies and Precedence
- Reaching a merchant account's processor account, G/L account, or business unit through a payment matters more than reaching it directly. You cannot delete any of these three records elsewhere in Rhythm while any merchant account still names them. Delete or reassign the merchant account first.
- Only the current business unit's active accounts are offered when staff choose one for a payment. Switch business units to reach another unit's accounts. The Bank Account field on Receive Payment works the same way. A business unit with no bank accounts of its own offers none, so an empty Merchant Account or Bank Account field while receiving a payment often means you are working in the wrong business unit, not that setup is missing.
- The account default (set in Finance Settings) applies across your whole account, from any business unit, and Rhythm checks it before the business unit's own first active account.
- A payment's business unit comes from the invoice or item it's paying, not from where you happen to be working. If that item's business unit has no active merchant account connected, the payment screen can open with no merchant account selectable at all. For example, this can happen when a product defaults to a business unit that was never connected to your gateway. Assign the item to the right business unit, or connect a merchant account to that unit, to fix it.
- Refund G/L accounts are set up on the business unit, not on the merchant account. Configure them from the business unit's own setup page. The merchant account's G/L Account setting is for the money the account holds, not specifically for refunds.
Change Impact and How to Revert
When you edit an existing account's processor, processor account, G/L account, or currency, the change affects payments from that point on. Past payments and their postings do not change. Saved cards for the account keep their existing token, so changing the processor account can leave those saved cards unable to charge until members re-enter their payment details. There is no undo after you save. Reopen the account and change the field back if needed.
Payouts and Bank Accounts
Your processor pays out to the bank account on file for the merchant account, on its own payout schedule and separate from this setup screen. A few things can hold that up:
- A bank-verification document didn't actually attach. Your processor may say a document, such as a voided check, was submitted when the file never went through. If a payout seems stuck, confirm the document actually uploaded and re-upload it if it did not.
- Changing the bank account doesn't automatically move payouts and fees to it. Adding or approving a new bank account with your processor does not necessarily mean payouts and fee debits switch over on their own. You may need to explicitly confirm that future payouts and debits should use the new account.
- Making an added bank account the primary one can need its own request. Beyond adding the account in the payments console, changing which bank account is primary may require a separate bank-change request with supporting documents. Your processor's own verification process can hold that up.
- A payout marked failed can still show up later. If a payout is marked as failed, do not assume the money is missing from a future payout report. It may already have been deposited in a later disbursement instead. Check your processor's Withdrawal Failures records for that payout rather than expecting it to reappear as unpaid in later payout activity.
Warning
If your processor account has its own login separate from Rhythm, deactivating that login can block card transaction processing and other account functions for the merchant ID it is tied to. Update or reassign the login ID with your processor before deactivating the user account behind it.
Why You Cannot Always Delete a Merchant Account
You cannot delete a merchant account while it is the default merchant account for your Rhythm account. Change the default first. Deleting an account can still be refused if other records depend on it, though the message you see does not name those records.
Warning
Deleting a merchant account does not check whether members have saved payment methods that hold a token for it. If you delete an account that members are actively paying with, those saved payment methods break instead of blocking the deletion. Deactivate an account instead of deleting it if it has ever taken a real payment.
Permissions
You need the merchant accounts permission in Setup to create, edit, reorder, deactivate, or delete a merchant account.
Validation and Errors
| Message contains | Cause | Fix |
|---|---|---|
| "Merchant account ID must begin with the business unit ID." | The ID does not start with the business unit's own identifier | Keep the form's prefix, or correct the ID by hand |
| The save is refused with no obvious field highlighted after choosing a currency | The currency is not one the business unit accepts | Choose a currency the business unit lists, or enable it on the business unit first |
| "Legacy Processor #2 can only be enabled when Legacy Processor #1 is enabled" | You tried to record a second legacy processor before the first | Turn on and complete Legacy Processor #1 first |
| "…cutover date must be after the cutover date of the first legacy processor." | The second legacy processor's cutover date is not later than the first's | Correct the second date |
| A payment fails although a customer chose a saved card | The saved card's token belongs to an account that is now inactive or was deleted | Ask the customer to add a new payment method |
| "Unable to authorize the credit card. The referenced resource does not exist." | The merchant account's processor configuration is incorrect | Review and correct the merchant account's processor and processor account, then test again |
| "Invalid Merchant ID" from BluePay | The BluePay processor account's Account ID or Secret Key is wrong | Confirm the Account ID and Secret Key with BluePay and correct them on the processor account |
| A card fails to authorize with a message pointing to your saved card token, on an account that used to run through a different, now-disabled legacy processor | The saved token still points at the disabled legacy configuration | Check the merchant account's Legacy Processor setup, and contact Support if the message does not otherwise explain the cause |