1. A missing object can be a missing account context
A successful creation response followed by No such payment_intent is a documented community problem, not necessarily evidence that a payment object disappeared. One developer reported creating a PaymentIntent with a connected-account option, then failing when updating it or continuing in the browser.[4] That question establishes an integration need, not the frequency of the problem or proof that every similar error has the same cause.
Stripe defines resource_missing broadly: the supplied ID is invalid, the resource does not exist, or an ID for a different resource was supplied.[3] For Connect direct charges, first investigate account context alongside the identifier. Do not interpret the error alone as a declined payment, a deleted transaction, or authorization to create another payment.
2. Identify who owns the transaction object
Stripe states that direct-charge PaymentIntents and Charges exist on the connected account, not on the platform. Accessing their data requires querying with the connected account ID in the Stripe-Account header.[1] A platform-level lookup is therefore not a reliable inventory of direct-charge payments.
Our recommended investigation record contains the internal order reference, object type, object ID, owning connected account, environment and original creation request reference. Resolve ownership from trusted server-side records rather than a merchant selector supplied by the browser. Ask which account created this particular object, not merely which seller should receive the money. If the original architecture is not direct charges, stop and establish its ownership model before applying this procedure.
3. Reconstruct one read-only request
Stripe documents the platform secret key together with a connected account ID beginning acct_ for server-side calls. Its account header must be included on each request, and server libraries support per-request account selection.[2] A successful scoped creation does not justify assuming a later worker or service inherited that scope.
- Compare the original object ID with the value passed to the failing endpoint; check object type and accidental truncation.
- Check the authorized account mapping and the effective account header or SDK request option at the failing call site.
- Inspect background-job serialization: preserve the owning account with the object reference instead of passing only the payment ID.
- Repeat an authorized read with the known ownership context before considering any write.
As an illustrative request shape, retrieve GET /v1/payment_intents/pi_example with Stripe-Account: acct_example and server-side platform authentication. These are placeholders, not a tested request or returned result. Do not probe unrelated merchants' accounts to discover where an object lives.
4. Match browser scope to server scope
Server correctness is only one branch. Stripe separately requires the connected account ID as an argument to the client library; its JavaScript example uses Stripe(publishableKey, {stripeAccount: connectedAccountId}).[2] The direct-charge guide initializes Stripe.js with the same connected account ID used to create the PaymentIntent.[1]
If an authorized server retrieval works but browser confirmation fails, compare the browser's account configuration with that creation record. Check the checkout session after merchant switching, page restoration or reused client initialization. These are recommended inspection points, not claims about a specific framework defect. Pass the intended account context from authenticated server logic, and keep the browser configuration paired with the intended payment rather than silently falling back to the platform.
5. Keep environment mismatch separate
Stripe separates sandbox and live-mode objects: each mode has its own keys, and objects in one mode are inaccessible to the other.[5] Record the exact sandbox or live environment as part of the investigation. Matching an acct_ value does not eliminate the need to check which environment produced the object.
Use three decisions. If the ID or object type differs, repair the reference. If ownership differs, repair account routing. If the environment differs, repair environment selection. When all three match and retrieval still fails, preserve the actual error and request details for further investigation rather than declaring a scope fix successful. Key rotation is not the diagnostic objective here; do not replace credentials merely to test an ownership hypothesis.
6. Close with evidence, not another payment
Stripe notes that direct-charge scoping also affects synchronization services: they must query the connected account rather than only the platform.[1] Apply the same ownership record to reporting and support tools so an empty platform result does not become an assertion that the customer never paid.
Recommended acceptance checks are an authorized retrieval of the intended object, matching account context in the browser, correct environment selection, and a support record linking those observations to the original creation. Exercise these checks in your own test environment; this article reports documentation research, not executed integration tests. Keep secret keys and client secrets out of diagnostic notes. The result sought is an explained lookup path, not a guarantee of payment completion, financial safety or regional availability.
Sources and dates
Official documentation supports technical behavior; community questions demonstrate qualitative demand only. Retrieved and checked on 2026-09-22. Retrieval is not publication. Unstated dates remain unknown. This is documentation research, not a live-account test, PayIn feature claim, or legal, tax or financial advice. Account eligibility and regional availability require separate confirmation.
- [1] Create direct charges · Publication date not stated; update date not stated · Checked 2026-09-22.
- [2] Make API calls for connected accounts · Publication date not stated; update date not stated · Checked 2026-09-22.
- [3] Error codes · Publication date not stated; update date not stated · Checked 2026-09-22.
- [4] Stripe Connect PaymentIntent error: No such payment_intent · Publication date not stated; update date not stated · Checked 2026-09-22.
- [5] API keys · Publication date not stated; update date not stated · Checked 2026-09-22.