Glossary

Stripe PaymentIntent

A Stripe PaymentIntent is the object that tracks a single attempt to collect a specific amount from a customer, through every state that attempt passes through, from requiring a payment method to succeeding or being canceled.

Also called: payment intent, payment_intent, PaymentIntent object, pi_

Start a free trial View Pricing

Definition

Stripe describes the PaymentIntent’s amount as the "amount intended to be collected by this PaymentIntent". That word does the work. A PaymentIntent is a record of intent and progress, not a record of money that moved.

It exists because collecting a payment online is rarely one step. A card may need authentication, a bank redirect may need the customer to come back, a first attempt may be declined and a second may succeed. The PaymentIntent is the object that survives all of that and keeps a single, stable identity for "the customer is trying to pay us $80".

The thing that records money actually moving is the Charge, and Stripe links the two through a field whose name gives away the relationship: `latest_charge`, documented as the "ID of the latest Charge object created by this PaymentIntent". Latest, not only. One PaymentIntent can produce several charge attempts over its life, and Stripe states the field is "null until PaymentIntent confirmation is attempted", so it can also produce none at all.

For bookkeeping, that is the entire point. A PaymentIntent is not something you post to the books. A charge is.

Key points

+Tracks an attempt to collect a specific amount, through every state that attempt passes through.
+Stripe defines its amount as the amount "intended to be collected", not the amount collected.
+Can produce zero, one, or several charge attempts. `latest_charge` is null until confirmation is attempted.
+Has seven statuses: requires_payment_method, requires_confirmation, requires_action, processing, requires_capture, canceled, succeeded.
+A succeeded PaymentIntent in the Stripe dashboard is not what causes a QuickBooks record to appear.
+Identified by an id beginning `pi_`. The charge it produced begins `ch_`.

The seven statuses, and which one means money moved

Stripe documents the PaymentIntent `status` field as taking one of seven values: `requires_payment_method`, `requires_confirmation`, `requires_action`, `processing`, `requires_capture`, `canceled`, or `succeeded`.

Read as a sequence they describe a negotiation rather than a transaction. The first three are all waiting on somebody: a payment method has not been attached, confirmation has not happened, or the customer has to complete a step such as 3D Secure authentication. `processing` is the payment underway. `requires_capture` is the authorization-only case, where funds are held and not yet taken, which is what Stripe’s `manual` capture method produces.

Only two are terminal. `canceled` ends the attempt, and Stripe records why in `cancellation_reason`, with values including `abandoned`, `expired`, `failed_invoice`, `void_invoice`, `duplicate`, `fraudulent` and `requested_by_customer`. `succeeded` means the collection worked.

None of the seven is an accounting fact by itself. Even `succeeded` is a statement about the attempt, and what you actually book comes from the charge underneath it.

One intent, several attempts

The one-to-many relationship between a PaymentIntent and its charges is the part that most changes how you read the Stripe dashboard.

Stripe keeps a `last_payment_error` field on the object, documented as "the payment error encountered in the previous PaymentIntent confirmation", and notes that it is cleared if the PaymentIntent is later updated. A field named for the previous error only makes sense on an object that expects to be tried again.

So a customer whose card is declined and who then pays with a different card has one PaymentIntent and more than one charge attempt against it. The successful one is the one that moved money. The failed one is real history, and it is not revenue.

This is why counting PaymentIntents is not a way to count sales, in either direction. A PaymentIntent can exist with no successful charge, so counting intents overstates. And a single subscription customer generates a new PaymentIntent for every renewal invoice, so an intent is not a customer either. The countable, bookable object is the charge.

Why the dashboard and your books disagree about timing

A PaymentIntent going green in Stripe feels like the moment the sale happened, which makes it the natural thing to expect your accounting to react to. It is not what accounting reacts to, and the gap explains a specific confusion.

Stripe emits separate events for the intent lifecycle and for the charge. It also states plainly that it "doesn’t guarantee the delivery of events in the order that they’re generated", and its own example of a subscription creation lists `customer.subscription.created`, `invoice.created`, `invoice.paid` and `charge.created` as events that can arrive out of order.

So watching the PaymentIntent succeed tells you the collection worked. It does not tell you that the charge event has been delivered, and the charge event is the one carrying what your books need: the balance transaction detail, the fee, the net, and the settlement currency. Those live on the [balance transaction](/glossary/stripe-balance-transaction) attached to the charge, not on the intent.

The practical version: if a payment shows as succeeded in Stripe and the corresponding record has not appeared in QuickBooks yet, the intent succeeding is not evidence that anything is wrong. It is evidence of one step in a chain that has more steps after it.

PaymentIntent versus the objects it sits between

Four objects get used interchangeably in conversation and mean genuinely different things.

The **PaymentIntent** is the attempt to collect. It has an intended amount and a status, and it may or may not have produced money.

The **Charge** is one attempt to move money, and the object that succeeded or failed on its own terms. It is what a sale is, and it is what a QuickBooks sales record corresponds to.

The **[balance transaction](/glossary/stripe-balance-transaction)** is what the charge did to your Stripe balance: gross, [fee](/glossary/stripe-fee), net, and the date the money becomes available. This is the object that carries the numbers a bookkeeper needs.

The **[payout](/glossary/stripe-payout)** is money leaving Stripe for your bank, long after all of the above.

An [authorization hold](/glossary/stripe-authorization-hold) is a fifth case worth keeping separate: a PaymentIntent in `requires_capture` has placed a hold and taken nothing, so there is nothing to book until it is captured.

What Acodei does with a PaymentIntent, and what it does not

Acodei does not sync on the PaymentIntent lifecycle. Its sales records key on the charge: `charge.succeeded` and `charge.captured` are the events that route to a job and produce a QuickBooks sales record, with the record type decided by your account settings rather than by anything on the intent.

This is worth stating precisely, because the documentation used to say otherwise. The webhook event list on Acodei’s product documentation for product and account mapping previously included `payment_intent.succeeded`. It was removed in a code verification pass on 8 August 2026, on the grounds that no such handler exists in the webhook processor and that charges arrive as `charge.*` events. If you have been waiting for a PaymentIntent event to drive your books, it never did.

That is not the same as saying Acodei ignores the object. When an event is processed, Acodei retrieves the relevant Stripe objects from the payload, the payment intent among them, and the PaymentIntent is a deliberate second stop in two mapping lookups. For description-based [product mapping](/glossary/quickbooks-product-service), on a charge not linked to a Stripe invoice, Acodei reads the charge or payment description first and the PaymentIntent second. For metadata mapping, the read order is payment or charge, then PaymentIntent, then invoice, then subscription.

So the accurate summary is that the PaymentIntent is a source of data, not a trigger. It never causes a QuickBooks record to be created, and it can still decide which QuickBooks product that record lands on when the charge itself carries nothing useful. If your mapping rules depend on metadata your platform writes to the PaymentIntent rather than to the charge, that is supported, and it is worth knowing it is the fallback rather than the first thing read.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What is a Stripe PaymentIntent?

It is the object that tracks a single attempt to collect a specific amount from a customer, through every state that attempt passes through. Stripe defines its amount as the amount "intended to be collected", and it can produce zero, one, or several charge attempts along the way. The charge is what records money moving; the PaymentIntent is the record of trying.

What is the difference between a PaymentIntent and a Charge?

A PaymentIntent is the attempt, a Charge is the money. Stripe links them with a `latest_charge` field, documented as the id of the latest Charge object created by that PaymentIntent, and that field is null until confirmation is attempted. One intent can therefore have several charges or none. For bookkeeping, the charge is the postable event and the intent is not.

What are the PaymentIntent statuses?

Stripe documents seven: requires_payment_method, requires_confirmation, requires_action, processing, requires_capture, canceled, and succeeded. The first three are waiting on something, processing is underway, requires_capture is an authorization holding funds without taking them, and canceled and succeeded are the two terminal states.

Does Acodei sync payment_intent.succeeded events?

No. Acodei keys its sales records on charge events, `charge.succeeded` and `charge.captured`. A `payment_intent.succeeded` entry appeared in Acodei’s internal webhook event list until it was removed during a code verification pass on 8 August 2026, because no handler for it exists in the webhook processor. A PaymentIntent succeeding in Stripe is not what causes a QuickBooks record to appear.

Does Acodei read anything from the PaymentIntent at all?

Yes, for mapping. When Acodei processes an event it retrieves the relevant Stripe objects from the payload, including the payment intent. For description mapping on a charge not linked to a Stripe invoice, it reads the charge or payment description first and the PaymentIntent second. For metadata mapping the order is payment or charge, then PaymentIntent, then invoice, then subscription. So the object is a data source, never a trigger.

My PaymentIntent succeeded but nothing is in QuickBooks yet. Is it broken?

Not necessarily. The intent succeeding is one step, and the charge event that drives the sync is a later one. Stripe also states that it does not guarantee events arrive in the order they were generated. A record that has not appeared yet, with no error against it, is usually still in the queue rather than failed.

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