Stripe Payout Method

Four fields on one object, all of them about where

The classic payout object is where most people meet this, and it carries four separate fields that all sound like they answer the same question. They do not, and telling them apart saves a lot of time.

The destination is the ID of the bank account or card the payout is sent to. This is the one that matches what you see in your Stripe dashboard under payout settings, and it is the one most failure codes are really about.

The type is either a bank account or a card, describing what that destination is.

The method is either standard or instant, describing how fast it travels rather than where it goes. Stripe notes that instant is supported for payouts to debit cards and bank accounts in certain countries.

The payout method is the odd one out, and it is the field this page exists to explain. Stripe defines it as the ID of the v2 financial account the funds are sent to. So it is not a method in the sense that the method field is, and it is not a payout method in the sense the money management API uses. It is a pointer that is either empty, meaning this payout behaved normally, or populated, meaning this payout went into a financial account.

That single distinction has a direct bookkeeping consequence, because a payout into a financial account is money moving between two balances you own, while a payout to your bank is money arriving in your bank. Same event name, two different meanings.

The object that decides whether money can move at all

The other payout method is a real object, and it belongs to the money management side of Stripe rather than to the payments balance.

Its type is one of three things: a bank account, a card, or a crypto wallet. When it is a bank account, Stripe attaches the bank name, the country, the last four digits, the routing number, the currencies that account supports, the delivery options that are enabled on it, and whether the account is a checking account. It also carries its own archived flag, which is how a payout method is retired without being deleted. Stripe exposes archive and unarchive as explicit operations for that reason.

The object also records the payout speeds available for that specific destination, either instant or standard, which is where you find out that a given bank account cannot receive an instant payout before you promise somebody one.

The field that matters most, though, is the usage status, and it is more interesting than a single usable flag.

Usage status has two axes, and they disagree on purpose

Stripe does not record one eligibility for a payout method. It records two, because there are two different things you might do with a destination and they have different requirements.

The payments axis covers sending funds to recipients, which is what an outbound payment does when you pay a vendor or a contractor. The transfers axis covers sending funds to yourself, which is what an outbound transfer does when you move your own money out to your own bank.

Each axis carries one of three values. Eligible means the destination has met all the necessary requirements. Requires action means it needs to meet more requirements, or somebody needs to do something, before it can be used. Invalid means it can never support that flow, and Stripe gives credit cards for transfers as the example: a card is not a thing you can transfer your own balance into, so no amount of verification will change that answer.

That three-way split is the part worth remembering, because two of the three look identical from the outside. A movement that did not happen because the destination requires action is waiting on a task somebody can complete. A movement that did not happen because the destination is invalid for that flow is waiting on nothing, and will never happen. Retrying it, or waiting another day, accomplishes the same amount in both cases, which is nothing, but only one of them has a fix.

There is also a setup intent recorded on the object when one is active, which is the mechanism by which a destination that requires action gets verified.

What a blocked payout method does to your books

The accounting consequence of all this is quieter than an error, which is what makes it worth understanding.

When a payout method is not eligible for the flow you are trying to use, the money does not move. No outbound payment, no outbound transfer, nothing posted anywhere. And because bookkeeping software records movements of money, nothing arrives in QuickBooks either. There is no failed record to investigate and no error in your books, because the thing that would have produced a record never happened.

So the symptom is an absence. A vendor says they were not paid. A transfer you expected to see in your bank never arrived. Your financial account balance is higher than your forecast said it would be. None of those show up as a problem in QuickBooks, because QuickBooks is faithfully recording a world in which that payment was never made.

That is the practical reason to know this object exists. When something did not post and you cannot find an error anywhere, check whether the destination was ever able to receive it. The answer is on the payout method, not in the sync.

One scoping note that saves a wasted search. The money management payout method object belongs to Stripe’s newer money management and global payouts stack, and Stripe lists global payouts as available in the United Kingdom and the United States. If you are a business taking payments and receiving ordinary payouts to your bank, you may never encounter this object at all. The field on the payout object is the one you are more likely to meet.