Compare the existing Session IDs in the same provider account and environment, then trace each Session to the intended store order. Matching totals or matching page designs do not establish a shared Session. Read both Session status and payment_status, and check for an existing successful payment before continuing. Two different Sessions are separate records to reconcile, not proof of two charges and not a reason to create a replacement or automatically cancel either one.
For: An owner or authorized checkout operator for a research-only store whose buyer has two payment tabs open for what appears to be one cart.
Preserve the report that two payment pages are open, but investigate through the merchant’s authorized store and provider records. For each tab, have the integration owner identify the existing Checkout Session and the store order it was created for. Compare the actual IDs privately in the same account and environment. Do not ask the buyer to submit either payment to establish the connection.
If both tabs resolve to the same Session ID in that account and environment, the evidence points to two views of one Session. If the IDs differ, there are two Session records, even if the products, currency and total match. Then determine whether both records map to one intended order or to different orders. An equal amount helps compare the records but is not a unique order reference. If the integration does not provide a traceable association, leave that link unresolved.
Read the lifecycle and payment state together
Stripe’s Checkout Session reference distinguishes status from payment_status. The source used here is the reference at API version 2026-08-26.preview, checked on September 29, 2026. It shows that a complete Session can still have payment processing in progress; payment_status distinguishes paid, unpaid and no_payment_required. Confirm the vocabulary against the version and integration actually installed rather than assuming every connector exposes the same fields.
Record both fields for each existing Session, with the observation time, then compare them with the store order and any linked payment record. A complete label alone does not establish that the intended order has been paid. An unpaid value does not by itself establish that every earlier payment attempt is finally over. A no_payment_required value is not evidence that a second payable page is needed. The meaning of the Session must be reconciled with the intended order and the payment flow actually used.
Idempotency does not merge different payment opportunities
Stripe documents idempotency as returning the saved result when the same request is retried with the same key. A differently keyed request does not gain protection from an unrelated earlier request. After a key is pruned, reuse is treated as a new request. That behavior is about requests; it does not establish from two visible tabs that only one Session was created.
Ask the integration owner to compare the existing creation records if the Session IDs differ. The useful findings are whether the records came from the same retried request or separate requests, and which order association each retained. Keep keys and full request payloads out of this worksheet. A claim that the checkout uses idempotency is insufficient without the actual relationship between these two Sessions. Adding another Session before that relationship is understood only adds another record to reconcile.
Choose the next action from the mapped outcome
When one intended order has a confirmed successful payment, resolve why another page still invites payment before directing the buyer to continue. When payment is still processing or the records disagree, assign the case to the owner who can reconcile the provider and store states. When both Sessions appear unpaid, still establish whether either has a payment in progress and which existing path the integration intends to use. An unpaid snapshot is not permission to pay through both pages.
If the mapping shows two genuinely separate orders, the merchant must confirm the buyer’s intended purchase before changing either order. If it shows two Sessions for one order, the integration owner needs a documented decision about which existing path remains appropriate. This guide does not prescribe automatic cancellation, expiry or replacement. Record the chosen path, the evidence supporting it and any unresolved status; any operation requires the actual provider and integration rules.
For a Prism checkout-review consultation, summarize the platform, whether the Session IDs matched, the observed states and the unresolved order association. Include the website and research-only product types; omit private payment links and customer records. Scope, responsibilities, fees and terms are confirmed before work. Email follow-up to an inquiry is not authorization to manipulate payments or a provider eligibility decision.
Parallel-session map
Use one map for the reported pair. Compare real identifiers in authorized systems; enter only match/mismatch results, status values, observation times and non-sensitive role labels here. A missing order link or unresolved payment state blocks a conclusion that either page is safe to continue.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Parallel-session map. The last column is for temporary notes.
Comparison point
Existing evidence to read
Decision the evidence supports
Your finding
Store order reference
Existing evidence to readThe intended order and the integration’s recorded association from each existing Session.
Decision the evidence supportsEstablish one intended order, two orders or an unresolved mapping; totals alone cannot decide.
Session identity comparison
Existing evidence to readBoth actual Session IDs, compared privately within the same provider account and environment.
Decision the evidence supportsSame ID identifies one Session record; different IDs require separate state checks.
First session status
Existing evidence to readThe first existing Session’s status and payment_status, plus observation time.
Decision the evidence supportsRecord lifecycle and payment state independently; complete alone is insufficient.
Second session status
Existing evidence to readThe second existing Session’s status and payment_status, observed in the same investigation.
Decision the evidence supportsDo not copy the first Session’s outcome because its total matches.
Existing successful payment
Existing evidence to readThe intended order’s linked provider payment records and any unresolved processing state.
Decision the evidence supportsA confirmed payment or an unresolved attempt must be reconciled before another payment instruction.
Creation-request relationship
Existing evidence to readAuthorized integration records showing a retry of one request or distinct requests.
Decision the evidence supportsA general idempotency claim does not establish protection across distinct requests.
Owner decision
Existing evidence to readThe responsible role, selected existing path if established, remaining uncertainty and supporting record.
Decision the evidence supportsDocument the disposition without creating, cancelling or expiring a Session from this worksheet.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
The Session status discussion is bounded to the captured Stripe API reference at 2026-08-26.preview. Confirm the actual integration and version; it does not describe every hosted checkout.
This map does not authorize a payment retry, refund, replacement Session or automatic cancellation. Different Session IDs do not prove duplicate successful charges.
Keep Session and payment identifiers in authorized records. Never enter full checkout URLs, private link tokens, request payloads, card data, authentication codes or secrets in the worksheet or consultation form. Stripe technical behavior does not establish merchant eligibility.
Checkout Session status and existing Customer prefill in captured API reference — checked 2026-09-29. In the captured 2026-08-26.preview reference, Session status and payment_status are distinct: a complete Session can still have payment processing in progress, and payment_status distinguishes paid, unpaid and no_payment_required. These fields support investigation of the existing Sessions, not a universal connector behavior or proof of this order’s outcome.
Stripe idempotent requests — checked 2026-09-21. The same idempotency key returns the saved result of the original request. A different request is not protected by an unrelated earlier key; reuse after pruning is a new request.
Prism solutions — checked 2026-09-21. Prism’s published support includes storefront review and processing preparation. Scope, fees and terms precede work; the provider decides eligibility and account terms.
Prism contact — checked 2026-09-21. The form takes the website, products and question, excludes card details, passwords and customer records, and leads to email follow-up rather than a booking, purchase or processing application.