Five settings on the Other Settings page control how members and other payers handle open invoices in the Portal. They also control whether someone can pay a shared invoice without signing in. All five settings belong to the single finance settings record for your Rhythm account.
What It Controls
- Whether Portal members can pay an open invoice by electronic check (bank account), in addition to credit card.
- Whether payers can save a credit card or bank account on file while paying an open invoice, so they can reuse it later.
- Whether a member paying a membership invoice is offered automatic renewal, and whether that offer starts checked or unchecked.
- Whether anyone holding a shared link can pay an invoice without signing in to the Portal, and which Portal site opens the payment page.
- Which payment methods a public, sign-in-free payment link accepts: credit cards, electronic checks, or both.
Where to Find It
Go to Finance & Billing › Setup › Other Settings. The fields are on the Basic Settings card and, when public invoice payments are turned on, on a separate Public Invoice Payments card lower on the page.
Prerequisites
You need the permission your administrator grants for finance settings. Rhythm support staff can change every field here. Other administrators can see and change everything except the payment processor choice and its related Stripe options, which are covered in a separate article.
Portal and public invoice payments use the payment processor on your main merchant account. If that account still points to your previous processor, Portal card entry and saved-card payments continue to use that older path, including any gateway-specific errors, until you finish switching the merchant account over.
The Settings
| Setting | Options | Default | Effect |
|---|---|---|---|
| Allow electronic checks when paying for open invoices in the portal | Checked, unchecked | Unchecked | Adds an Add Bank Account option to the Portal payment picker for open invoices. This applies only to the Portal and does not change what staff can do when they take a payment in the Console |
| Allow users to securely save credit cards & bank/ACH accounts | Checked, unchecked | Checked | Controls whether the Portal payment-method picker offers a "save this payment method" option while someone pays an open invoice |
| Automatic renewal question (three radio buttons) | Disabled (no offer shown), Opt In (shown, starts unticked), Opt Out (shown, starts ticked) | No selection until you choose one | Controls whether a member paying a Portal invoice for a Membership product sees a renewal checkbox, and how that checkbox starts |
| Allow users to pay invoices in the portal without logging in | Checked, unchecked | Unchecked | Turns on public, sign-in-free invoice payment links. This is available only after Rhythm has switched on public invoice payments for your Rhythm account |
| Select the Portal: | Any of your Portal sites except an event microsite | None until chosen | Required once public payments are on. This is the site where a shared link opens the public payment page |
| What types of payments should be accepted? | Credit cards, Electronic checks, Both credit cards and electronic checks | Both | Required once public payments are on. This limits what an anonymous payer can use when paying from a shared link |
Warning
The automatic renewal question and the checkbox above it save to the same value. Ticking the checkbox is the same as choosing Opt Out. Unticking it does not save because the setting only accepts Disabled, Opt In, or Opt Out as its saved value, not a plain "off." If you untick the checkbox without choosing one of the three radio buttons, the page cannot save. Choose a radio button instead of relying on the checkbox.
Staff and payers reach payments through different paths, so a payment can succeed in one place and fail in another. A payment entered manually by staff in the Console does not use the Portal or public-link settings on this page. Because of that, it can succeed even when a payer's emailed public invoice link fails, or the reverse. Troubleshoot each path on its own instead of using one path’s result to judge the other.
Warning
Being in Sandbox mode does not, by itself, stop payment transactions from reaching your payment processor. Rhythm allows transactions in a sandbox so you can test your payment processor setup there. It is not automatically a safe test mode for payments. Use a merchant account in debug mode, not just a sandbox environment, when you need to be sure nothing is charged for real.
Two other payment-method controls are on the same Other Settings page, but they are outside the five settings above:
- Stripe Options, covered in a separate article, has its own checkboxes that turn options such as one-click and similar Stripe-backed payment methods on or off for both the Console and the Portal. A Stripe-backed option also needs to be enabled directly in Stripe. If it is on here but not in Stripe, Rhythm shows an error prompting you to enable it there too.
- Digital wallets (Apple Pay and Google Pay) can appear in the Portal payment picker for associations on Rhythm Payments, without a setting on this page to turn them on. If you need to remove a wallet option from Portal checkout, Rhythm support currently needs to make that change for you.
Public Invoice Payments in Detail
A public invoice payment link lets someone without a Portal account, such as an organization’s representative, pay an invoice from a link staff send them. The payer does not need to sign in. To turn it on:
- Go to Finance & Billing › Setup › Other Settings.
- Check Allow users to pay invoices in the portal without logging in. This reveals the Public Invoice Payments card.
- In Select the Portal:, choose the Portal site where the payment page should open. We recommend choosing your main Portal site.
- In What types of payments should be accepted?, choose which payment methods to accept.
- Save your changes.
Result
Staff can now send a public payment link for an invoice. Anyone with that link can open the payment page on the Portal site you chose and pay without signing in.
Warning
Turning this setting on is not enough by itself. The Portal site you choose must also have the Public Invoice Payments feature installed in the Portals & Microsites application. Otherwise, the link opens a site with no payment page. Confirm the feature is installed before you send any public payment links. Even with the feature installed, a recipient can pay without logging in only if the billing notice or email you send them includes the invoice's public payment link. Turning this setting on does not add the link to a notice by itself.
Warning
A public payment link tied to an organization's invoice does not always match the payer to an existing CRM contact. Depending on how the payer enters their details, Rhythm can create a new contact record even when a similar contact already exists. The payment still applies correctly to the organization or invoice. If you want to avoid duplicates, check for a new contact after a public payment comes in.
Warning
A public payment link accepts payment from anyone who has it, with no sign-in required to slow down automated abuse. If someone uses the link to test stolen card numbers ("carding"), you can see a spike in authorization attempts. Your payment processor may step in with its own restrictions, and staff may need to clean up the resulting fraudulent transactions afterward. Those same fraud controls can also delay or block legitimate payments while they are active. Treat an unexpected spike in authorization attempts as a reason to check with your processor, not just as noise to ignore.
Tip
If a payer sees an option to add a bank account instead of, or alongside, a credit card in the credit card payment flow, Allow electronic checks when paying for open invoices in the portal is usually turned on. Electronic check payments, meaning bank account payments, use this one setting in both the Portal and public invoice payment links. There is no separate toggle for public links. There is nothing separate to activate with the payment processor itself; turning on this one setting is enough. If the page tells an anonymous payer that their bank information will not be saved even though they see an option to add a bank account, that is expected. A one-time public payment does not save the payer's details the way a signed-in Portal payment can. To remove the ACH/checking-account option from a public link specifically, clear the electronic-check option, or limit accepted methods to credit cards only, on this same page. Either choice also avoids the Stripe direct-debit authorization step for those links.
An invoice's payment link is a public Portal pay-invoice URL, not a link to its record in the Console. You get it from the invoice itself: open the invoice and use its Get Payment Link action. The same settings record also governs invoices your organizations receive from a membership renewal. Once a renewal creates an invoice, it can be paid later from the organization's own Portal payment pages, such as My Organization › Make a Payment, using these same payment settings.
Warning
An existing public payment link is tied to the Portal site's URL at the time it was sent. If you later change your website or Portal site, a link sent before the change can return a page-not-found error even though public invoice payments are still on. Reissue the link from the invoice after a site changeover.
Who a Public Payment Is Recorded Against
A public payment link matches the payer to an existing contact by the email address entered, not by name. If that email does not match an existing contact, Rhythm creates a new contact record for the payment instead of trying to match by name alone. Because of this, the payer's name and email as entered determine who the payment is recorded against, even if that is not the name on the original invoice. You may see a payment recorded to a different person than the one the invoice was originally billed to if someone else pays it on their behalf. A payment made this way is associated with that individual payer, not with an organization, so it cannot be used to advance an organization-billed membership or invoice at the organization level. In Rhythm, the payment shows the name of the contact it is recorded against. In your payment processor, the same payment may not consistently show a name, so do not rely on the processor's view alone to identify the payer.
Tip
A large ACH payment made through a public link by a payer who is not signed in can face an extra verification delay before it settles. Because the payment does not carry a signed-in payer's identity, your payment partner or bank may flag it for review first.
What the Public Payment Page Can and Can't Show
The public payment page is built around the Public Pay Invoices component, which shows the invoice number, date, and balance due. You can add static content above or below that component, such as instructions or branding, but you cannot change the component's own fields or add a dynamic invoice link inside it. If your invoice template includes the public payment link as a field, that field has no conditional visibility. It appears whenever the template includes it, whether the invoice is paid or not. To keep the link off a paid invoice, remove the field from the template instead of trying to hide it conditionally.
Public payment and donation pages also run CAPTCHA as a safeguard against automated card-testing attempts. You may see CAPTCHA on a public payment page even though the Console, where staff take payments directly, does not show it. That is expected because CAPTCHA protects the public, sign-in-free path. If a payer completes CAPTCHA and the card-entry form still does not appear, or a wallet option shows a message about being in a test environment on an account that is not a sandbox, treat it as a payment-page problem to report to Support rather than something the payer did wrong.
Customizing what a payer sees beyond these settings is not always something you can configure yourself. For example, adding payment-method detail to the Portal's View Payment page may require a product request rather than a setup change.
Dependencies and Precedence
- Public invoice payments depend on Rhythm switching on the underlying feature for your Rhythm account. If that has not happened, the Public Invoice Payments card does not appear on this page, no matter what else you configure.
- Every invoice carries its own sharing link. Turning public invoice payments off does not stop an already-sent link from working, because payment from the link is checked against the invoice’s own sharing link rather than this setting.
- What types of payments should be accepted? controls what a public payment link page offers. It does not affect the Portal’s signed-in payment pages, which use only the electronic-check and saved-payment-method settings above.
- Whether a member sees an electronic-check option while paying a membership invoice can also depend on a related setting in Membership. If electronic checks are not showing where you expect them, check both this page and your membership payment settings.
- A public invoice payment link does not use override checkout settings configured elsewhere. If you rely on those overrides to charge a credit card processing fee, that fee is not applied on a public payment link. There is currently no way to configure a public link to charge it.
- There is not yet a clean way to query or report on public-link payments separately from other payments in Rhythm.
Change Impact and How to Revert
- Turning off electronic checks or saved payment methods removes the option from the Portal picker going forward. It does not remove payment methods a payer already saved.
- Turning off public invoice payments removes the Get Payment Link action from invoices and hides the settings card. A public link already sent keeps working, because the payment page checks only the invoice’s own sharing link, not this setting.
- Deleting your finance settings record entirely turns public invoice payments off until the settings are saved again. The Get Payment Link action disappears until then.
- Changing your website or Portal site can break links you already sent, even though this setting itself has not changed; see the warning above.
Permissions
You need the permission your administrator grants for finance settings to change any setting on this page. Staff without that permission cannot open the page.
Validation and Errors
If you turn on public invoice payments and try to save without choosing a Portal site or a payment-method option, the page blocks the save until you choose both. If you untick the automatic renewal checkbox without choosing one of the three radio buttons, the save fails and the page shows an error. Choose Disabled, Opt In, or Opt Out instead.
If a payer reports missing payment options on an invoice, first confirm the invoice has a billing contact. Open the invoice in the Console, use Invoice Options › Edit Details to assign one if it is missing, save, and test Receive Payment. Then impersonate that billing contact to test paying the invoice in the Portal. This shows whether a missing invoice contact, rather than these settings, is causing the gap.
If a public payment link fails but you cannot reproduce the problem, try paying the same invoice through the signed-in Portal instead of the public link. The two paths have different settings and checks, so comparing them helps show whether the problem is specific to the public link. Signing in and paying from the Portal is also a working alternative for a payer whose public payment page will not let them enter a card. If a public payment page loads as a blank page instead of showing an error about the setting or the link, it can be a temporary product issue rather than a problem with how the link was shared. If reloading the page does not help, report it to Support.
Tip
Whether a completed invoice payment sends a payment-received notification, on top of any notice generated by a billing run, depends on separately configured notifications. If you expect a notification when a payment comes in through a shared link or the Portal, confirm that notification is configured rather than assuming it happens automatically.