Saved payment methods — when to use them (and when not)

Once Stripe (or another processor) is connected, Suprata can store a customer's card or bank account on file as a saved payment method. The token sits in the system, attached to that customer's Account, and can be charged again without re-keying.

This unlocks workflows that aren't possible with one-time payments — subscription billing, autopay on invoices, one-click checkout, post-paid service. It also concentrates risk: a compromised account, a misconfigured automation, or a customer dispute hits harder when you're storing their financial credential.

This article covers when to enable saved methods, how to use them safely, and the compliance footprint to be aware of.

What "saved" really means

When a customer enters card info to pay an invoice, one of two things happens:

1. One-time charge. The card is used to pay this invoice and then it's gone — nothing about that card is kept on file with you.
2. Save the method. A secure reference to the card is kept on the customer's Account so you can charge it again later. The actual card number is never stored on Suprata's side — your processor (Stripe) holds that, and they're set up specifically to do so safely.

That distinction matters: with saved methods you get the convenience of charging a customer again without re-keying anything, and you don't have raw card numbers sitting in your business — your processor handles the sensitive part.

What saved methods unlock

The visible features include subscription billing, automated invoice payment, payment plans, and post-paid service — all of which require a method on file.

Concretely:

• Recurring invoices — auto-charge a saved method every cycle (monthly maintenance, quarterly retainer).
• Service agreements with autopay — the agreement spawns invoices on schedule and auto-pays them.
• Subscription billing — straight subscription model with a saved card and a fixed monthly charge.
• Post-paid service — tech does the work, leaves; the system charges the saved card after the fact, no second customer interaction needed.
• Payment plans — split a large invoice into installments charged automatically over time.
• One-click checkout — for office staff taking a phone payment, "use card on file" beats re-keying every time.

Without saved methods, every charge requires the customer to be present (or at minimum, present a fresh card detail).

When to enable saved methods

The decision is per-customer-relationship, not all-or-nothing. Three patterns:

Pattern 1: opt-in by customer choice

The customer pays an invoice through the public link and the checkout has a "Save this card for next time?" checkbox. They tick it; their token is stored. Default behavior, low friction, high comfort — they made the choice.

This is the right default for most businesses.

Pattern 2: required for a specific service

Some services only work with a card on file — month-to-month subscriptions, on-call retainers, automated billing for utility-style services. Sign-up for those services explicitly captures a card up front.

The signal to the customer should be unambiguous: "This service requires a payment method on file. We'll charge $X every month until you cancel."

Pattern 3: office staff capturing during onboarding

When a new commercial customer signs paperwork, your accounts-receivable person captures a card or ACH for autopay as part of the onboarding flow. This is appropriate for higher-trust commercial relationships and B2B work.

Don't do this for residential walk-ins without explicit verbal-and-written consent. The optics ("you took my card?") are bad even when the legal posture is fine.

When NOT to enable saved methods

• One-time customers. A walk-in service call where you'll never see this customer again. Saving their card is risk without benefit. Take the one-time payment and move on.
• Customers who haven't asked. Don't quietly save a card behind the customer's back. Even if you're technically authorized, the surprise charge is a customer-experience disaster.
• Disputed accounts. If the customer is in active dispute over an invoice, don't enable any new automated charges to their saved method. Pause, resolve the dispute, then resume.
• Cards near expiration. Stripe will alert you when a card is about to expire, but if you have a customer with an expiring card and no fresh method captured, autopay will fail. Catch these and prompt the customer for a refresh before they actually expire, not after.

ACH vs. card — which to save?

Saving an ACH (bank account) is meaningfully different from saving a card:

For high-value recurring charges (commercial monthly billing of $500+), ACH almost always makes sense — the savings on fees alone pay for the longer settlement time. For low-value ad-hoc charges, cards are usually fine.

The pattern many businesses settle on: capture both. ACH as primary for the recurring side; card as backup if ACH fails.

Autopay on invoices — how it runs

Once enabled, autopay runs on its own in the background. Each cycle, it looks for invoices that are:

• Past due (or coming due, if you've configured "auto-charge on due date").
• For a customer with a saved method.
• Marked as autopay-eligible.

It then attempts the charge. Outcomes:

• Success → invoice closes, customer receives a receipt.
• Soft failure (insufficient funds, temporary card decline) → retried on the next cycle, customer optionally notified.
• Hard failure (card expired, account closed, charge disputed) → autopay disabled for that method until human intervention; customer notified to update payment.

Watch for failed-charge alerts. The system surfaces these in the invoice list and (if configured) emails staff. A pile-up of failed autopay attempts means you have multiple customers needing payment-method updates.

Compliance and security

A few important points:

• You don't store card numbers. Your processor handles that. Suprata keeps a secure reference to the card so you can charge it again, but the card data itself never lives in your business.
• Bank account info for ACH is handled the same way. Same principle — your processor keeps the sensitive part; you keep a reference you can charge against.
• You need clear customer consent before storing and charging a method. Most jurisdictions require it, and the customer experience demands it. Suprata captures that consent at the moment the method is saved (the "save this for next time" checkbox or a signed agreement). Keep that record.
• Card network rules apply. Visa and Mastercard have their own rules for stored cards and recurring charges — things like notifying the customer before each charge and using a predictable name on their statement. Your processor handles most of this for you, but check their documentation if you're doing high-frequency or high-value recurring billing.
• Refunds, voids, and disputes all work the same as one-time charges. Saved methods don't change what you're liable for.

Common mistakes

• Enabling autopay on every customer with a saved card by default. Then a customer who meant to be one-charge-only sees an unexpected charge. Always make autopay opt-in per customer or per agreement, not opt-out per system.
• Not capturing fresh consent when a method is updated. A customer updating their card to a new card is also re-consenting to be charged. Don't auto-roll the consent forward as if nothing changed.
• Storing a method captured at one business unit and using it under another. If the customer authorized "ACME Plumbing" to charge their card, charging under "ACME HVAC" (a sister brand) without re-authorization is risky.
• Ignoring failed-charge alerts. Fail once, retry, fail again — but then it's been a month, the customer has racked up $2,000 in unpaid invoices because autopay silently kept failing, and now the relationship is awkward. Triage failures weekly.
• Assuming saved methods will follow you to a new processor. They don't. Saved cards and bank accounts are tied to the specific processor account they were captured under. If you switch processors (Stripe to USIO, or to a different Stripe account), you have to re-capture every customer's method.

What to set up alongside

Once saved methods are working:

• Receipt templates — make sure the auto-charged-card receipt is clear about what was charged and why (which invoice, which service). Prevents the "I didn't know about this" disputes.
• Failed-charge notifications — both for staff (so you can chase) and for customers (so they update before the next attempt).
• Update-card flow — give the customer an easy way to update their saved method without you having to take a phone call. The customer portal supports this.

Related articles

• Connecting Stripe
• Sending an invoice to a customer
• Recurring invoices (forthcoming)
• Autopay on service agreements (forthcoming)
• Handling a customer dispute (forthcoming)