The buyer can pay while the order total is still updating
The last total the buyer reviewed, the order total committed for that submission, and the amount submitted to the provider must refer to the same finalized cart state and currency. Record the change and the timing of each amount before assuming that they match. Ask the implementer to define the server-authorized total and when it is safe to enable payment. An unfinished recalculation or a failed update should leave the change visibly unresolved, not silently submit an earlier amount.
For: A research-only store owner whose checkout allows payment while shipping, tax, or discount changes are still being calculated.
A shipping selection or discount action begins a change; it does not establish that every system has finished applying it. Use an actual affected order and available records to put the change request, displayed amount, order commit, and payment submission in time order. Keep the currency and the relevant shipping, discount, and tax components with each total. A number without its currency or cart state cannot establish agreement.
The buyer's last reviewed amount is a separate fact from the order's eventual total. A later order screen may show a corrected total without showing what was visible when Pay became available. If no observation or retained record establishes that earlier display, mark it unknown. Do not reconstruct it from the final receipt. Agreement between the final order and provider records alone leaves the buyer-facing timing question open.
Identify the integration that owns the calculation
Stripe documents Payment Element with either Checkout Sessions or Payment Intents. Checkout Sessions supplies checkout features; with Payment Intents the implementer owns checkout logic such as tax, shipping, and discounts. Seeing Payment Element on the page does not establish which API the installed integration uses or who updates the total. Record the actual plugin or custom integration and the person responsible for its server-side calculation.
Stripe's dynamic-amount guidance says amounts must be recalculated and authorized on the server rather than trusted from the browser. This supports asking which server result the order and payment use. It does not mean a successful server calculation proves the customer saw that amount. Both the authoritative calculation and the refresh of the customer-facing summary need to be accounted for.
The same guidance describes updates for active unfinished Sessions and Intents awaiting payment; after confirmation, amounts generally cannot increase. A late recalculation must therefore be investigated against the payment's actual state. Do not assume the integration can silently correct the provider amount after submission. PaymentIntent confirmation and any required customer action are distinct lifecycle stages, not interchangeable labels for a completed payment.
Make update success and update failure visible
Specify the behavior the store needs: show that the total is updating, withhold payment submission while the requested change is unresolved, and present the settled total for review before submission becomes available. If the requested change is rejected or cannot be completed, show that result and the valid remaining choices. An earlier total should not appear to include a newly selected shipping method or discount that never became authoritative.
For supported Checkout Elements SDK integrations, Stripe documents runServerUpdate as a way to refresh state and totals after a server update. Server HTTP failures require handling separately from failures to retrieve updated state through the SDK. The implementer must account for both; a finished browser operation is not enough to establish that the merchant server accepted the change. This documentation is not proof that an installed WooCommerce plugin uses that method or handles the race correctly.
Ask how the implementation identifies the most recent requested cart change and prevents an older response from making an obsolete total payable. This is a requirement to investigate in the installed system, not a claim about a universal platform defect. Include any express payment route the affected checkout actually offers, because the visible Pay control may not be its only submission path.
Use the comparison to choose the repair
If the committed order and provider amount agree but the recorded customer display is older, investigate the refresh and submission timing. If the order and provider disagree, investigate which cart state each used and reconcile the existing payment before further action. If all three amounts agree for the same state, this record does not establish an amount mismatch; an enabled button during a visible update may still require a clearer interaction, but the cause should not be invented.
Give the integration owner the timeline, the specific disagreement or missing observation, and the required settled state. Keep submitted amount separate from any later captured amount, refund, or order edit. A Prism checkout consultation can discuss the visible behavior and provider question within an agreed scope. Send the site, research-only products, platform, and a non-sensitive summary; exclude payment details, credentials, and customer records. Implementation responsibilities, fees, and terms are discussed before work, and technical agreement of totals does not decide processing eligibility.
Total-update timing record
Complete one record for an actual affected submission. Compare amounts only when their currencies and cart states match. Mark unavailable display evidence unknown. Here settled state means a completed cart calculation ready for review, not bank settlement. Keep original logs in authorized storage.
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.
Total-update timing record. The last column is for temporary notes.
Timing point
Evidence to retain
How to interpret it
Your amount, time, and finding
Change requested
Evidence to retainShipping or discount action and its recorded time; identify the intended cart change without customer details.
How to interpret itEstablishes which change needed to finish before the relevant submission.
Displayed amount before submit
Evidence to retainActual observation of the last visible total, currency, and whether an updating message remained.
How to interpret itDo not substitute the later order total for an unrecorded customer display.
Server calculation completed
Evidence to retainAuthorized recalculation result and time, or the server error recorded for this change.
How to interpret itDistinguishes an accepted amount update from a browser action that merely ended.
Order amount committed
Evidence to retainSaved order total and currency at submission, using available history rather than only the current edited order.
How to interpret itIdentifies the order state that should correspond to the submitted payment.
Provider amount submitted
Evidence to retainAuthorized provider or integration record for the matching payment, its currency, submission time, and state.
How to interpret itCompare the submitted amount with the same order state; a later capture or refund is a separate event.
Payment availability
Evidence to retainWhen Pay or an offered express route became available relative to the update and refreshed summary.
How to interpret itShows whether the buyer could submit before the latest total was resolved and presented.
Integration owner
Evidence to retainActual plugin or custom integration, API path if known, responsible implementer, and unresolved handoff.
How to interpret itAssigns the calculation and display repair to the installation that actually runs.
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
This comparison does not determine tax liability, prove the cause of a race, or authorize another charge. Missing historical display evidence stays unknown.
Stripe API and SDK guidance applies only to the documented integration and lifecycle. It is not universal WooCommerce behavior or permission to change a confirmed amount.
Keep card data, authentication codes, private payment-link tokens, API secrets, and customer records out of the worksheet and public consultation form.
Stripe Payment Element — checked 2026-09-29. Payment Element supports Checkout Sessions and Payment Intents. Sessions provides checkout features; with Intents the implementer owns checkout tax, shipping, and discount logic. The document does not establish a particular installed integration.
PaymentIntent and SetupIntent lifecycle — checked 2026-09-29. PaymentIntent requires_confirmation is distinct from requires_action. Payment lifecycle states must be read separately rather than treating a confirmation stage as completion.
Stripe dynamically update payment amounts — checked 2026-09-29. Amounts must be recalculated and authorized on the server. Active unfinished Sessions and awaiting-payment Intents can be updated; after confirmation amounts generally cannot increase. Checkout Elements SDK runServerUpdate refreshes state and totals, with server HTTP failures handled separately from SDK retrieval failures.
Prism solutions — checked 2026-09-21. Prism offers storefront review and help with provider website questions. Scope, fees, and terms are discussed before work; the provider decides eligibility and account terms.
Prism contact — checked 2026-09-21. The inquiry asks for the website, products, and question and excludes card details, passwords, and customer records. It is not an appointment, purchase, or processing application.