The hosted payment page still shows the earlier cart

Find the session behind the page

Keep the store cart's last recorded change time separate from the Session's creation time and the time someone observed the hosted page. Identify the Session through the authorized store or provider record. A screenshot of an earlier total records what was visible then; it cannot establish the current server record or whether the buyer has since submitted payment.

Stripe's hosted Checkout guide describes an application creating a Session with line items supplied through Price references or explicit price data. That gives the comparison a concrete starting point: the inputs actually sent when this checkout began. A current product page or changed cart is a separate record until the integration has carried that change into the checkout the buyer is using.

Compare the basket before comparing its total

Match product or variation references, quantities and the price associated with each line. Then compare the currency, discount, shipping, tax and final total recorded for each side. Two equal totals can conceal different item selections; two different totals can be explained by an identified component. Preserve the exact differing lines instead of reducing the report to a single amount.

Ask the integration owner to establish the server-authorized current basket from the store's records. Stripe's dynamic-amount guide says to recalculate and authorize amounts on the server rather than trust a total submitted by the browser. The buyer-visible cart is useful evidence of the mismatch, but it should not become the authority for a replacement charge simply because it is the newest screen.

If the server cart and the provider Session agree while the visible page does not, preserve that narrower discrepancy. If the Session itself still contains the older lines, investigate the creation or update handoff. Neither observation alone identifies a theme, cache or plugin as the cause.

Update support depends on the actual checkout path

Stripe documents updates for active unfinished Sessions and describes recalculating totals and taxes when Session line items change. Its dynamic-amount guide also describes runServerUpdate for the Checkout Elements SDK to refresh checkout state. That SDK behavior is not proof that a separately hosted page, or the WooCommerce connector you have installed, follows the same refresh path.

Record the checkout type, connector version and configured API version before choosing an update procedure. The Session reference cited here was captured at API version 2026-08-26.preview. Confirm the supported operations for the installed integration; do not treat a preview reference as a guarantee for every account or version. A supported update requires evidence that the provider record changed and that the buyer sees the intended basket afterward.

A failed server request and a failure to refresh checkout state are different points to investigate. Preserve the available request outcome and the resulting Session details separately. An instruction to refresh the browser is not proof that the authoritative line items were updated.

Resolve the existing payment state before replacement

Read both Session status and payment_status immediately before deciding what happens next. Stripe distinguishes those fields: a complete Session can still have payment processing in progress. Do not issue another payment request on the assumption that an older-looking page cannot have produced a payment. Stripe also cautions that amounts generally cannot increase after confirmation; a completed or confirming payment is no longer a simple cart-refresh problem.

If the existing attempt remains unfinished and the installed integration supports the required change, reconcile its updated lines and displayed total. If a replacement is required, have the authorized integration owner account for the prior Session, verify its payment state and establish which route remains usable before directing the buyer onward. Record the connection between the retired route and the replacement in private records. A new link by itself does not establish that the old one stopped accepting payment.

For a Prism checkout consultation, describe the changed basket, where the mismatch appears and whether payment state is confirmed. Agree scope, responsibilities, fees and terms before implementation. Keep full hosted-payment URLs, private tokens, customer details and credentials out of the public inquiry.

Cart-to-session snapshot

Use one disputed cart revision and the exact Session already open. Put the current store value and Session value together in each response, with observation times. A missing match or unknown payment state is an unresolved dependency before a replacement payment route is issued.

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.

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.