When a member pays by card or bank account, or saves one for later, the payment page sends those details directly to the payment processor: Rhythm Payments, Stripe, Authorize.Net, or BluePay. Rhythm never sees the full card number or bank account number. Rhythm only receives a reference it can use for future charges.
Rhythm Payments Pages Use a Temporary Key
A payment page built for Rhythm Payments, listed in the integrations catalog as Payrix, does not use your account’s permanent processor credentials directly. Rhythm support may also call this processor WorldPay; in this context, Payrix and WorldPay refer to the same system. Rhythm gives the page a session key that is limited to:
- one specific merchant;
- a small number of uses, with Payrix defaulting to three unless your merchant is set up for single use; and
- a short time window, measured in minutes.
Your merchant setup in Payrix controls the number of uses and the length of that time window. The payment page does not request those limits. Turning on limited-use session keys for your account does not guarantee single use by itself. Your merchant must also be set up for single use in Payrix, or the default of three uses still applies.
If your account has more than one Rhythm Payments merchant, Rhythm uses only the first merchant listed for this session key. In rare cases, that merchant selection can make the Add Card form load with no card fields and no visible error, instead of falling back cleanly. If that happens and your account has more than one Rhythm Payments merchant, check that combination first. After the key runs out of uses or time, it stops working, and a new page load gets a new key. If Rhythm cannot issue this limited-use key for any reason, the payment page uses a reusable key instead so the page still works. You and the payer cannot tell this happened just by using the page.
Rhythm sends Payrix the raw payment amount. The currency charged comes from how your merchant account is configured in Payrix, not from the currency the payer saw on the page.
A New Card Is Checked Before It's Kept
When a member saves a new Rhythm Payments card, Rhythm checks the card before keeping it. If the check fails, Rhythm tries to delete the card at the processor so the member does not keep an unusable saved payment method. This check uses the merchant tied to the specific processor account named in the request.
Tip
If a member says a card they just entered “disappeared” right after saving, it most likely failed this check and was removed instead of kept in a broken state. Ask them to enter the card again and confirm the details, especially the billing address.
This save check can fail before Rhythm creates any order and before a transaction appears in the payment portal. If someone reports a card-save failure, do not expect to find a matching order or portal transaction as confirmation, because the failure can happen earlier.
Not every decline includes a visible reason. Sometimes the card's issuing bank declines the attempt directly, and neither Rhythm nor Payrix receives any explanation beyond the decline itself. If a card keeps failing with no useful detail on your side, ask the cardholder to contact their card issuer.
Adding a second payment processor account of any kind to your Rhythm account, not only a second Rhythm Payments merchant, can also cause an error when a member tries to add a card during a portal join or renewal flow. The check runs against the merchant tied to the specific processor account named in the request.
Payrix returns the card's type, such as debit or credit, when it creates the token. That happens before Rhythm adds any processing fee and submits the payment. This timing lets a payment page treat debit and credit cards differently, such as for fee handling, as soon as the card is entered.
Why a Stripe Payment Page Offers Different Options by Currency
A Stripe-powered payment page decides which payment methods to offer, such as cards, bank debits, or digital wallets, partly based on the payment’s currency:
| Setting | What it controls |
|---|---|
| Payment mode (cards, electronic checks, or both) | Which method types Stripe’s payment page can show. If this is not set, the page defaults to cards only. |
| Currency | Which specific method types are available within the allowed payment mode. Some wallet and local bank-debit options work only for certain currencies. |
If bank debits are requested for a currency that Stripe supports only for cards, the page has no method type to offer, and Stripe refuses to set up the payment.
Method availability also depends on which payment method types are turned on for the connected Stripe account, not only on currency. For example, enabling us_bank_account supports US bank-account debits in USD but not in EUR. To collect EUR bank debits, sepa_debit must be enabled on the connected account. An international ACH-style flow can also need a bank-debit type beyond us_bank_account, such as sepa_account. If the currency you're collecting has no enabled method that supports it, the attempt fails the same way it would if the currency did not support the requested payment mode.
The currency shown on the payment page is also the currency actually charged through Stripe. It is not a cosmetic label separate from what Stripe processes. One exception is worth knowing: a manually created invoice in a currency other than US dollars can still transact to Stripe in USD instead of the currency shown on the invoice.
A recent change to your multi-currency settings, or to payment-processor testing, can also show up later as a membership join or renewal that suddenly fails to initialize. If join or renewal payments stop working right after a currency or gateway change, check that change first.
For US-dollar bank debits specifically, Stripe requires the payer to verify their bank instantly through the bank’s own sign-in when the page is set to collect only bank debits, not both cards and debits. In that case, Stripe does not allow the slower micro-deposit method. A bank that Stripe does not support for instant verification cannot be saved this way. If the page offers both cards and bank debits, this instant-verification requirement is not set, and Stripe may fall back to micro-deposits for a bank account entered there.
Rhythm also sends Stripe the contact's phone number as part of card setup. Rhythm Payments, listed as Payrix, does not send phone data the same way.
A Stripe payment that requires 3D Secure authentication can remain incomplete at Stripe even while the related Rhythm payment or order looks complete on your side. Completion in Rhythm is not proof that Stripe finished authenticating the payment. If something looks off with a Stripe-backed transaction, check that specific transaction's status at Stripe before concluding Rhythm marked it successful incorrectly. Among several suspicious-looking attempts, the one that actually completed can look the same as the ones that did not until you check.
Tip
A sandbox commonly leaves Stripe disabled on purpose, so you avoid running real or accidental transactions while you test. If you see a secure Stripe payframe error in a sandbox and your testing does not involve payments or multi-currency behavior, you can ignore it.
Hosted payment fields can also fail to appear for reasons outside Rhythm. Stripe maintains its own list of blocked countries, and a payer connecting from one of them, or through a VPN or another network pattern Stripe flags, may find that card fields simply do not load. The processor enforces these restrictions for its own compliance and fraud reasons, and Rhythm cannot override them. If you see an unusual cluster of repeated payment attempts from the same payer, that pattern can also mean the payer is switching networks or locations, such as by using a VPN, rather than pointing to a webhook or sync problem on Rhythm's side.
Tip
Stripe does not block debit cards on its own. If you want to prevent debit-card transactions, ask about enabling Stripe Radar for Fraud Teams. The standard machine-learning Radar option is not enough for this. Rhythm manages the Stripe platform account and has to turn the feature on before a rule can be applied for your account. Radar screens every Stripe transaction it is applied to, not only the ones that turn out to be debit cards, and each screened transaction carries an additional fee on top of normal processing. That fee typically starts around $0.02 and may be higher depending on Stripe's pricing. A blocked debit card shows the payer a standard card-declined message, not a message naming the reason.
If a payment captured successfully at the processor does not show up in Rhythm's payment history or transaction views, that is not expected. A captured payment should also appear in Rhythm. When you investigate, gather the processor's transaction ID, the related order ID, and the Rhythm payment ID, if one exists, so support can trace exactly what happened between the two systems. It is also worth distinguishing a payment the gateway actually declined from one that never reached the gateway at all. The absence of any record at the processor is a useful clue when a portal checkout or renewal attempt fails without a clear reason.
Multiple Rhythm Payments Accounts
If you connect more than one Rhythm Payments merchant, saving the second one displays a warning about saved payment methods. Once two or more merchants exist, saved payment methods use different tokens. Tokens created for the first merchant will not work with the new one, and Apple Pay and Google Pay stop being offered at all. If your account already has saved cards in active use, review this carefully with your Rhythm contact before adding a second Rhythm Payments merchant.