Stripe Mandate

Three objects, not one

Bank-debit payments involve three separate records, and mixing them up is the source of most mandate confusion.

The **payment method** is the bank account: routing number, last four, account holder. The **mandate** is the permission to debit that account, with its own id and its own status. The **payment** is a single act of collecting money using the first two.

Stripe keeps the link explicit in one direction. The mandate points at the payment method it authorises, documented as "ID of the payment method associated with this mandate." So from a mandate you can always find the account. Going the other way, in the Dashboard, "Active mandates appear under a customer’s saved payment methods", each showing "the accepted text, acceptance date, and IP address".

Why it matters practically: a saved bank account with a dead mandate is not a usable payment method, and nothing about the account details will tell you that. The status you need to read is on the other object.

This is the same distinction [Stripe PaymentMethod](/glossary/stripe-payment-method) draws between the instrument and the attempt, extended one step further back. The instrument is not the attempt, and the permission is not the instrument.

What acceptance actually captures

The `customer_acceptance` hash is the evidentiary core of the object. Stripe describes it as "Details about the customer’s acceptance of the mandate", and what it holds depends on how the customer said yes.

Stripe documents two kinds. Online mandates "appear as part of the payment flow on a website and customers accept them through a user interface element such as clicking an Accept or Pay button." Offline mandates "require that you present the specific terms to your customer in writing or over the phone."

For online acceptance the object stores an `accepted_at` timestamp alongside `online.ip_address` and `online.user_agent`. That combination is not decoration. It is the answer to the question a bank asks months later.

Across both kinds, Stripe says the mandate records three things: the business name, whether the authorisation is one-time or recurring, and "The date and method of acceptance (IP address, user agent, and timestamp for online flows)".

One operational detail that surprises people building custom forms: "You only need to display a mandate the first time you collect a customer’s bank account." The permission persists. You are not re-asking on every debit, which is exactly why the permission needs a durable record of its own.

Why the paper trail exists: proof of authorization

Occasionally a customer’s bank asks you to prove that a debit was authorised. Stripe calls this a proof of authorization inquiry, and it arrives as a `charge.dispute.created` event with the status `warning_needs_response`.

What the bank wants is the mandate. Stripe lists it first among the required evidence: "Mandate authorization (required): A copy of the authorization proving that the customer or bank account holder agreed to the debit on their bank account."

Who produces it depends on how you collected it. "If you use Stripe-hosted ACH mandates, Stripe automatically responds to the customer’s bank with a copy of the debit authorization." If you built a custom mandate through the Payment Intents API, "Stripe creates a dispute inquiry for your business to provide evidence for the payment in question", and answering it is your job.

There is also a standing Nacha obligation that has nothing to do with disputes: "you must provide each customer with an electronic or hard copy of the mandate." Stripe does this for you by email when the customer has supplied a billing email address. Turn Stripe’s emails off and the obligation does not go away, it just becomes yours.

So the mandate is doing two jobs at once. It gates the debit, and it is the artefact you produce when someone asks whether the debit should ever have happened.

How a mandate goes inactive, and what it takes with it

A mandate does not usually expire on a schedule. It gets killed by an event, and Stripe names them.

"ACH Direct Debit mandates can become inactive, which renders the payment method unusable. This can occur when a customer disputes a payment, when certain payment failures occur, or when Stripe becomes aware that the payment method is no longer valid, such as when a bank account is blocked."

The dispute case is the harshest and the most common. A disputed ACH payment "invalidates the mandate associated with the payment method and you can’t reuse it. To attempt a charge again, you must resolve the dispute with the customer and collect a new mandate authorization." And there is no third chance on that account: "If they dispute a subsequent payment, Stripe blocks the bank account from further re-use."

Revocation is quieter. Customers "can revoke a mandate at any time by contacting you directly", which means the notice arrives as an email or a phone call rather than as a webhook. Stripe’s guidance is to cancel or capture pending payments and then detach the payment method. If you miss it, the outcome is unambiguous: "If you debit an account after a mandate is canceled, the payment will fail."

For a subscription business this is the failure mode to design around. A dead mandate does not announce itself at renewal time. It announces itself as a failed charge on a customer who has changed nothing and expects the payment to work, and the fix is not a retry. It is collecting fresh permission.

Single use, multi use, and recurring debits

The `type` field says how far the permission reaches. `single_use` "Represents a one-time permission given for a single payment." `multi_use` "Represents permission given for multiple payments."

That maps onto how you collected it. A one-off checkout produces permission for that payment. Saving the bank account for later, through `setup_future_usage` or a SetupIntent, is what asks for the broader permission, and Stripe’s recommended mandate text for that case is explicitly separate and additional. See [Stripe SetupIntent](/glossary/stripe-setup-intent) for how that collection step works when no money moves.

Recurring debits carry obligations beyond the mandate text. Stripe: "If you originate recurring preauthorized debits, you must disclose to your customers how these amounts are calculated or a range the customer can anticipate. You must also give your customer at least 7 calendar days notice if you change the timing of any recurring preauthorized debits."

A scope mismatch is its own failure: permission for one payment cannot fund a series. `single_use` and `multi_use` exist so the scope is a value you can read rather than something you have to remember about how the customer was onboarded.

On Connect, scope narrows further. Cloning a bank account to a connected account "duplicates the mandate authorization to the connected account", but a mandate authorised `on_behalf_of` one connected account "can’t be used with a different connected account".

What a failed debit does to your books

Mandates are an authorisation concept, and QuickBooks has no equivalent object. Where the two worlds meet is one step downstream, when a debit that was never going to succeed reaches your ledger anyway.

The timing is what makes it awkward. ACH is a delayed-confirmation method: Stripe documents standard settlement at four business days from payment creation, with a faster two-day option for eligible US accounts. So the payment is recorded long before anyone knows it worked. Stripe is blunt about the reversal: "If a payment fails after funds have been made available in your Stripe balance, Stripe immediately removes funds from your Stripe account."

Acodei handles that sequence explicitly for invoice payments. A new ACH payment in the pending state is recorded against the QuickBooks invoice as if it had succeeded. If it succeeds, nothing changes. If it fails, Acodei deletes the payment, then writes a pending sale record and a reversal of that sale record on the daily balance summary for the day of failure, so the entry into and exit from the Stripe balance both appear on the day they actually happened.

That is failed-debit handling, not mandate handling. It describes what happens after a debit fails, and says nothing about mandate status being checked beforehand. The story of the failure itself, and what it leaves behind in QuickBooks, is covered in [Stripe failed ACH payment in QuickBooks](/blog/stripe-failed-ach-payment-quickbooks).