What This Does
A contact's saved cards and bank accounts are on the contact's customer page. From that page, you can review each method on file, remove one that is lost or no longer needed, and move a schedule to another saved method when the current one changes. Rhythm names each saved method by its type and last four digits, such as a card brand with the last four digits or a checking account with the last four digits. You cannot add your own nickname for a saved method, including during checkout. In Console and the Portal, the credit card option accepts only credit card details and does not let you add a bank account.
If your account uses Rhythm Payments, Payrix hosts the card fields on save and checkout screens. Validation messages for those fields, such as an invalid expiration date, come from Payrix, so the wording may not match the rest of Rhythm.
If your association uses Rhythm Payments, the payment provider can refresh an expiring card behind the scenes and update the saved token with the card's new details. Cards saved under an earlier processor, such as BluePay, do not refresh that way.
Rhythm Payments replaced legacy processors such as BluePay and Authorize.net, which Rhythm no longer supports. If your association still uses one of those legacy processors, you must move to Rhythm Payments instead of choosing another processor, and you need to complete a merchant account application to set it up. Associations still on a legacy processor were notified by email and Console messaging. Complete the pre-transition steps promptly to avoid a disruption to payment processing. After those steps are complete, the cutover itself typically finishes within seconds and should not disrupt saved-method processing.
Recurring ACH is not currently supported for Rhythm Payments recurring plans on Payrix. A recurring or scheduled plan built on Rhythm Payments works only with a saved card, so you cannot use a saved bank account for an automatic recurring charge yet.
When to Use It (and Not)
Use this when you need to review or clean up a customer's saved payment methods. You can also move an automatically charged record, such as an installment schedule, to a new card after the old one expires or is replaced. If you want the customer to choose or add a payment method while paying, see Add or Choose a Payment Method to Pay instead.
A saved method belongs to one contact, so you cannot move it to a different contact's record. If the wrong person's card is saved here, such as when someone pays on another person's behalf, review it and remove it if your organization does not want it kept on that account. The workaround is to add the correct payment method again the next time that person pays or renews.
Prerequisites
- You can open the contact's customer page. Saved payment methods appear only on a contact's page; organizations do not have a saved payment methods tab.
- To move a scheduled charge to a different saved method, you need permission to edit the record that owns the schedule, such as an installment schedule.
- Console access to a contact's saved payment methods should ask for a CAPTCHA challenge only once every few hours, about five. If you are prompted repeatedly within that window while only moving between pages, that is not expected behavior.
If your association clears Allow users to securely save credit cards & bank/ACH accounts in Finance & Billing › Setup › Other Settings, staff and members can no longer save a new payment method. Any method already on file stays here until someone removes it.
Steps
- Open the contact's customer page and select the Stored Payment Methods tab. The tab label shows how many payment methods are on file.
- Review the table. Each row shows the method's type, name, last four digits, expiration date, and the merchant accounts that have a working charge token for it.
- To remove a method, select the trash icon in its row, then confirm the removal.
- If your association uses Rhythm Payments and other records still use the method, the Payment Method In Use dialog opens and asks you to select a replacement payment method. Choose one of the contact's other saved methods to continue.
- After you choose a replacement, Rhythm moves the dependent records to that method and removes the old one.
Each row's expiration date comes from the token itself. The date is blank for an older, non-migrated method saved under a previous processor, such as BluePay or Authorize.net, when that method was never linked to a token in your account's current processor. A method in that state can still appear as a stored renewal method with no usable expiration date, and a charge against it can fail instead of completing.
There is no query field or report that flags every contact with this kind of outdated saved method. There is also no bulk way to fill in a missing expiration date afterward, because the underlying card details were never stored. Each affected member has to re-enter or re-save their payment method. If you need to find likely candidates ahead of time, the closest query is Renewal Payment Card Expiration with Auto Renew = Yes. Rhythm has no query field for the stored payment method itself, and no way to query whether someone chose to save a method during checkout.
You cannot select several rows here and delete them together. Remove each saved method one at a time with the trash icon. If you need to clear stored payment information across your whole account, such as after turning off the option to save payment methods, use the mass-delete page in System Settings instead of this panel. Saved methods created before your association moved to Rhythm Payments cannot be bulk-removed from the front end either. Contact Support if you need a batch of those older methods cleared out.
Rhythm also does not offer a report that shows when a customer first saved a card or which payment provider originally holds it. This table is your closest view into a contact's saved methods.
Variants
- Replacing a scheduled charge's method on its own. To point a single scheduled charge, such as an installment schedule, to a different saved card without removing the old one, open that record and use its Update Payment Method action to choose another of the customer's saved methods. An installment plan charges the card from the contact's saved payment methods here. Updating payment information somewhere else, such as directly on the order or installment record, does not make a new card available to the plan unless it is also saved to the contact. If an installment stops processing because of a stored payment method problem, re-saving that same card through Update Payment Method can restore processing, even without adding a new card.
- Accounts that don't use Rhythm Payments. If your account uses a different payment processor, removing a saved method does not check whether other records still depend on it, and there is no replacement step. Removing the wrong method can leave a schedule with a card that no longer works. The schedule can also keep showing that card's masked details even though it is no longer among the contact's saved methods. Check the contact's current saved methods list, not just what the schedule displays, before you assume a scheduled charge still has a working card.
- A saved method from before a processor change. After your association switches payment processors, a method saved under the earlier one, such as BluePay or Authorize.net, can keep working for recurring and scheduled charges until someone updates the card in the Portal. That update saves the card under the new processor instead. After that happens, or after Rhythm migrates the token another way, the method may no longer appear in the ordinary saved-methods list even though the recurring charge behind it can still run on that token in the background. If your association also turned on a second currency around the same time, watch for a renewal that is still tied to the earlier processor's saved method. It may be charged instead of using the new currency's price, which can produce a converted amount instead of the price you configured. A setting used on accounts that have moved to Rhythm Payments can route a qualifying auto-renewal charge tied to a legacy token through the earlier gateway instead of Payrix. You can tell these apart because they produce different transaction codes than Payrix-generated charges.
- Saving a new card before token migration finishes. If a customer manually renews and saves a new card while Rhythm is still linking their older, legacy-format tokens to your current processor, that linkage only targets tokens still in the old format. It does not overwrite the token from the card the customer just saved. Rhythm treats that manually saved card as the default for future auto-renewals because the customer explicitly chose it.
Result
The method no longer appears in the customer's saved payment methods list. If you replaced it because it was in use, every record that depended on it now charges the replacement instead.
Side Effects
- Removing a method the customer relies on for a recurring or scheduled charge means the next charge will need a working method. If your association uses Rhythm Payments and the method is still in use, Rhythm asks you to choose a replacement before the removal can finish, so this is normally caught. Other payment processors do not catch this, so double-check that a method is really unused before you remove it.
- You cannot delete a contact while they still have saved payment methods on file. Remove the methods first if you need to delete the contact.
What to Do If It Fails
- The removal fails with an error. The table stays as it was, and nothing is removed. Try again, or contact Support if it keeps failing.
- A staff member tries to pay with a saved method and Rhythm says the method has no working token for the chosen merchant account. The saved card or bank account was never charged through that merchant account, so Rhythm has no way to charge it there. Choose a different saved method, or have the customer add the card again. Re-adding the card sends a fresh token and can also fix a future recurring or auto-renewal charge that failed for the same reason. Seeing a card on this page does not prove it will charge successfully. Console can show a saved card even when your current payment processor has no usable token for it, which is a common reason an automatic renewal fails even though a card appears to be on file. The same issue can show up in a few other ways. A checkout or membership sign-up can fail because of a saved Authorize.net profile, and removing that stored profile so the payer can add the card again has been observed to resolve it. A completed contact merge can also leave a previously saved profile unusable at checkout, where deleting and recreating the profile can be the fix. A backend order or renewal that fails with a "No transaction token" error while using a saved card often clears up if you delete the stored method, have it re-saved, and retry. If it still fails after that, the payment provider may need to look at the token itself. Deactivating or deleting the underlying stored payment profile can also unstick a failed payment so the customer can add the card again and retry.
Warning
On accounts that moved to Payrix, cards saved under an earlier gateway such as BluePay or Authorize.net keep their old tokens. Auto-renewals, certification renewals, installment schedules, and pledges built on those tokens keep processing against the earlier gateway until the tokens are migrated. A token migration only moves tokens it can match to a user record. If no match is found, that saved method is not migrated, and the customer must save their card again before a future auto-renewal can use the new processor. A method saved under the legacy BluePay gateway specifically has to go through a secure migration before it works with Rhythm Payments; it is not picked up automatically. If an auto-renewal is tied to a token from a gateway your association has since disabled, and that token was never migrated, the renewal fails until the customer resaves their card. When Rhythm imports tokens from a previous processor, the import does not by itself recreate stored payment methods on contact records in every case. A separate step may still be needed to associate the imported tokens with the right contacts before they can be used for billing or auto-renewal.
- Saved auto-renewals stop working because the merchant account behind them was deactivated (for example, an Authorize.net account). Re-enable that merchant account so Rhythm can keep processing the existing auto-renewals, or have affected members sign in and update their saved payment methods so future renewals use an active account.
- A payment using a saved method fails for no obvious reason. Delete the saved payment method, have the customer add it again, and save it once more if they want to keep using it. That can let the next payment go through. Treat this as a temporary fix rather than a permanent one. If payments keep failing after that, look into the specific cause below. A card that saves without error is not guaranteed to keep working. The issuing bank can still decline a later charge against it, which shows up as a normal decline on that transaction rather than a problem with the saved record itself.
- A saved card shows a blank or "null" value instead of its details, such as a card labeled "Visa xxxnull." This usually means the stored card record is invalid or corrupted. It can also come from invalid billing address data on the contact, such as a stray character in an address line. Delete the stored method and try a different card, or add the same card again. This has cleared the failure in a number of cases, though it is not guaranteed every time. If you would rather not remove it yet, have the customer manually enter their card on the open invoice instead of relying on the saved method.
- The Console shows "No vaulted tokens" for a saved method. This can be a display issue rather than a real problem. The saved payment method can still exist and work even when Console shows no tokens for it. Confirm with the customer or by attempting a payment before you assume the method is unusable.
- A null value appears in an address-related field on a saved method. In at least one reported case, this was only a display issue and did not affect payment processing. Do not assume address geolocation or payment processing failed just because a field displays as null. Confirm with an actual payment attempt.
- A card saves without any problem, but a later purchase with that same card is declined for an address mismatch (AVS). Saving a card only authorizes it using your merchant gateway's own AVS settings. If your gateway is not set to enforce address verification at that moment, a card can be saved even with an incorrect billing address. A later purchase with that card can still be declined for an AVS mismatch. There is no setting in your account to relax or change this address-verification behavior; it follows your gateway's own configuration. If a customer's payment keeps failing this way, try correcting the address on the contact record, then have them re-save the card with the corrected address. That resolves it in some cases.
- You can't tell whether a card-save attempt actually failed, or why. Some failed attempts to save a card do not appear in your payments portal at all, so you may need to rely on the customer telling you a save is not working rather than finding it yourself. Rhythm also does not always show a clear, human-readable reason for a declined or errored saved card. The message can be generic in both Console and the Portal. When you troubleshoot a saved-card failure, remember that a card failing after it was already saved usually points to a later authorization problem or a gateway-specific issue with the saved profile, not bad information the customer originally typed in. Support also cannot always confirm from the interface whether a contact removed a stored payment method through the Portal themselves. The contact record shows that a change happened, not who made it or which screen they used.
- You need to tell whether a failure is specific to one saved card. Add the card again and run a small live charge, such as a one-cent invoice payment. If it goes through, the issue is likely tied to that specific card or saved profile rather than payments on the account generally. If you would rather not charge the cardholder to test this, re-enter the card during a normal order, choose to save it, then cancel before you reach final submission so nothing is charged. Check the contact's saved payment methods afterward to see whether the last four digits populated. Then compare the result against another card or a test card to see whether the problem follows one specific card.
- A card payment can't be processed for one specific contact, with a record-not-found error, and nothing points to a broader problem. If the issue looks isolated to that one contact rather than to your payment structure generally, process the payment directly in Authorize.net as a workaround. Then record it in Rhythm as an offline credit card payment so your books stay accurate.
- A saved bank account (ACH) payment keeps failing. Confirm that ACH is enabled on your association's payment gateway, and check whether the problem is isolated to one payer or affects everyone using a saved bank account. Re-saving the payment method and retrying often clears it. If it does not, the payment provider may need to look at the gateway configuration.
- A card fails to save even though the merchant account is in Debug mode. Debug mode stops a merchant account from sending real charges for live processing, but it does not bypass the gateway's own card-number validation. Adding or vaulting a card still needs to pass that check before it can be saved, so an invalid or clearly fake test card number can still be rejected even with Debug mode on.
- Adding a card fails with "Please supply a billing address," and there's no address field to fill in. This can happen when the card-entry form does not show the billing-address fields it needs. It is a display problem with the form itself, not bad address data. Refresh the page and try again. If the address fields still do not appear, contact Support.
- Your association's saved payment methods from a previous processor don't appear after a migration to Payrix, and the import can't proceed. If the encrypted export your previous processor, such as Authorize.net, originally provided is no longer available from that processor, ask them to resend it so it can be uploaded and checked again. If Support is coordinating that import on your behalf, keep the reference for your original request to move off that processor; Payrix may need it to continue the import.
- You need to remove a method but there's no other saved method to choose as a replacement. Add a new method for the customer first. See Add or Choose a Payment Method to Pay, then remove the old one.
Warning
On accounts that use a payment processor other than Rhythm Payments, deleting a saved card removes it immediately without checking for records that still charge it. Confirm with the customer, or check their schedules, before deleting it.