Glossary

Stripe PaymentMethod

A Stripe PaymentMethod is the stored representation of how a customer pays, the card or bank account or wallet itself, as distinct from any single attempt to collect money with it.

Also called: payment method, payment_method, pm_, card on file

Start a free trial View Pricing

Definition

A PaymentMethod is the instrument, not the transaction. In Stripe’s API it is a plain noun: an id beginning `pm_`, a `type` naming what kind of instrument it is, and a hash matching that type carrying the details. A card gets a `card` hash with the brand and last four digits. A bank account gets a `us_bank_account` hash with the routing number and last four.

The clearest way to see what it is not is to look at what the object lacks. A PaymentIntent has an `amount` and a `status`. A charge has an `amount` and a `status`. A PaymentMethod has neither. It never attempts anything, so there is nothing to size and nothing to succeed or fail. It is the thing an attempt is made with.

That places it precisely in the chain. A [SetupIntent](/glossary/stripe-setup-intent) exists to create one and attach it to a customer. A [PaymentIntent](/glossary/stripe-payment-intent) picks one up and tries to collect with it. A charge records what happened when it did. The PaymentMethod itself just sits there, reusable, until something uses it.

For bookkeeping the useful part is not the definition. It is that the `type` field, which looks like a cosmetic detail next to the amount, is the single field that best predicts the two things that actually move your books: when the money lands, and what the fee looks like when it does.

Key points

+The stored instrument a customer pays with. Its id begins `pm_`.
+`type` names the instrument: `card`, `us_bank_account`, `link`, `sepa_debit`, `card_present`, and dozens more.
+No `amount` field and no `status` field. It is a noun, not an attempt.
+`customer` is set only once the method has been saved to a Customer.
+`allow_redisplay` controls whether Checkout and Elements may offer it as a saved method. It defaults to `unspecified`.
+Acodei writes records from charge events, so the payment method type never changes which QuickBooks record you get.

The type predicts your timing and your fees, not the amount

Two sales for the same amount on the same day can hit your bank in different weeks and net different money. The sale amount tells you nothing about either. The payment method type tells you both.

Stripe groups the methods it supports into eight categories, and the categories behave differently on exactly the axes a bookkeeper cares about. Cards are the familiar case. Bank debits are the one that quietly changes your numbers: Stripe’s own framing is that "by debiting your customer’s bank account directly, you can save on transaction fees when compared to cards". That is a fee-shape difference, not a rounding difference, and it applies to ACH Direct Debit in the US, SEPA Direct Debit in Europe, Bacs in the UK and BECS in Australia and New Zealand.

Buy now, pay later runs the other way and surprises people who expect installments to reach them in installments. Stripe is explicit that with these methods "your business is paid immediately and in full, and your customer pays nothing or a portion of the total cost at checkout". The customer’s payment plan is between the customer and the provider. Your books see one payment.

Vouchers are the far end of the spectrum. Stripe describes the flow as one where "customers receive a digital voucher with pending transaction details and then complete the payment at local stores". The sale is initiated online and settled in person, whenever the customer gets around to it.

So when the gap between your Stripe volume and your bank deposits changes shape and your revenue did not, the payment method mix is the first thing to look at, well before you start suspecting the sync. A month where bank debits went from a tenth of your volume to a third will move your timing and your net without a single thing going wrong.

What this page will not do is give you day counts or fee percentages by method. Those are pricing and network facts that change, and quoting a number that has drifted is worse than quoting none. The shape of the difference is stable. The numbers are not.

The charge keeps its own copy, which is why history stays right

A PaymentMethod can be detached from a customer or replaced when a card expires. That raises a fair question about your audit trail: if the instrument goes away, does the record of how an old sale was paid go with it?

It does not, and the reason is worth knowing. A charge carries two separate things. There is `payment_method`, which Stripe documents as the "ID of the payment method used in this charge", a pointer. And there is `payment_method_details`, which Stripe documents as "details about the payment method at the time of the transaction".

That second field is a snapshot, not a lookup. The brand, the last four, the funding type and the network as they stood on the day of the sale are copied onto the charge and stay there. Detaching the card later does not rewrite what the charge says.

This is the correct behavior for accounting and it matches how you would want any ledger to work. The record of a transaction describes the transaction as it happened, not as the customer’s wallet looks today. When you are reconciling a sale from four months ago, the payment method detail on the charge is trustworthy on its own terms.

The `custom` type, which Stripe does not process at all

One value of `type` behaves unlike all the others, and it is the one most likely to produce a confusing gap between Stripe and your books.

Stripe defines the `custom` type as covering "user-defined payment methods that Stripe doesn’t process", and adds the constraint plainly: "you can’t use them in PaymentIntents or SetupIntents".

These exist so a business can record, inside Stripe, that a customer paid some way Stripe never touched. A cheque in the post. A bank transfer straight into your operating account. Cash across a counter.

The accounting consequence follows directly. No money moved through Stripe, so there is no charge and no [balance transaction](/glossary/stripe-balance-transaction). The payment is real and belongs in your books, but Stripe was never a party to it, so nothing about it can arrive through a Stripe sync. It has to be recorded in QuickBooks the same way any other payment taken outside your processor is recorded.

This completes a pattern worth holding onto. A Checkout Session may produce nothing because the customer left. A SetupIntent produces nothing by design. A `custom` payment method produces nothing because Stripe was only ever the filing cabinet.

What Acodei does with the payment method

Nothing branches on it, and that is the point worth stating plainly.

Acodei’s sales records key on charge events. `charge.succeeded` and `charge.captured` are what route to a sync job and write a record. Which record you get, a sales receipt or a standalone payment, is decided by your account settings, and the deposit target is the resolved holding account for that Stripe account and currency. None of those three decisions consults how the customer paid.

So a card sale and an ACH sale of the same amount, on the same connection, produce the same kind of QuickBooks record in the same account. What differs is when the charge event arrives, because that is set by how the payment method settles rather than by anything on the Acodei side.

The one case where a payment method type produces a visibly different sequence is a pending ACH debit that later fails, which leaves records behind rather than none. That behavior belongs to the ACH settlement window rather than to payment methods generally, and it is covered in full in [what happens when a Stripe ACH payment fails](/blog/stripe-failed-ach-payment-quickbooks).

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What is a Stripe PaymentMethod?

It is the stored representation of how a customer pays: the card, the bank account, the wallet. It has an id beginning `pm_` and a `type` field naming the instrument. Unlike a PaymentIntent or a charge it has no amount and no status, because it is the instrument rather than an attempt to collect.

What is the difference between a PaymentMethod and a PaymentIntent?

A PaymentMethod is the instrument. A PaymentIntent is one attempt to collect a specific amount using an instrument. The PaymentIntent carries the amount and the status and can produce a charge. The PaymentMethod carries neither and produces nothing on its own. One customer can have one saved card and hundreds of PaymentIntents against it.

Does the payment method type change what Acodei writes to QuickBooks?

No. Acodei writes from charge events, and the record type is set by your account settings rather than by how the customer paid. A card charge and a bank debit charge of the same amount produce the same kind of record in the same holding account. The type affects when the charge event arrives, not what gets written.

Why do two sales of the same amount reach my bank at different times?

Because settlement timing is a property of the payment method, not the amount. Cards, bank debits, wallets and vouchers all move money on different schedules. If your deposits have shifted and your revenue has not, compare your payment method mix across the two periods before you look at anything else.

If I delete a saved card, do my old sales lose their payment details?

No. A charge stores `payment_method_details` as a snapshot of the instrument as it was at the time of the transaction, separately from the pointer to the PaymentMethod itself. Detaching or replacing the card later does not change what an existing charge records.

What is a custom payment method in Stripe?

It is a type Stripe defines as covering user-defined payment methods that Stripe does not process, and they cannot be used in PaymentIntents or SetupIntents. They let you note inside Stripe that a customer paid by cheque, cash or direct bank transfer. Because no money moved through Stripe there is no charge and no balance transaction, so the payment has to be recorded in QuickBooks the way any payment taken outside your processor is.

What customers say about running Stripe through Acodei

★★★★★

“If you're testing out all the different Stripe/QuickBooks integration apps right now, let me save you some time. This one is the best one by far.”

RyanOwner at Indie Music Academy