Request a trace from the deployed checkout's incoming values to the server's authoritative price calculation and the amount sent to the payment provider. It should identify the catalog or approved order price, the rules for adjustments and who may change that order. Stripe documents recalculating and authorizing amounts on the server rather than trusting client totals. A browser total appearing in a request is a reason to inspect how it is used; it is not, by itself, proof that the server trusted it.
For: A research-only merchant investigating a report that checkout may use a browser-supplied total as the payable amount.
Separate a displayed amount from the authority to charge it
The browser displays a cart and sends selections to the store. The question is what the server does with those inputs before it asks the provider to collect an amount. A server may receive a displayed total and ignore it, compare it with its own result or use it without an independent calculation. An observed request alone cannot distinguish those paths.
Ask the implementer to identify the specific handler in the deployed version that creates or updates the payable amount. Its explanation should show where item identities and quantities are checked, where prices are obtained and which result reaches the provider. Simply locating a server API call does not answer the question if the amount passed into that call came directly from the browser.
A discrepancy between an order and a captured payment is a different finding. It establishes that two records differ, while this review asks whether the integration protects the calculation even when ordinary order and payment totals happen to agree.
Trace catalog prices and approved adjustments together
Use the actual catalog, order configuration and approved adjustments to identify the price basis. An authorized negotiated order price or discount may differ from the current public price. The useful distinction is whether the server obtains that adjustment from an authorized record and checks that it applies to this order, rather than accepting whatever total the client supplies.
Stripe's dynamic-amount documentation calls for server recalculation and authorization. Ask for both parts: the computation of the amount and the check that the requester is allowed to change the relevant order. A mathematically correct amount for an order the requester cannot change would leave a different boundary unresolved.
For an integration using Stripe Payment Intents, the Payment Element documentation leaves tax, shipping and discount checkout logic with the implementer. Payment Element can also use Checkout Sessions, which includes checkout features. Identify the actual integration before assigning responsibility; the appearance of the payment fields does not establish which calculation path the store installed.
Ask for evidence tied to the running version
Request a guided explanation of the relevant deployed code or configuration, its release identifier and the mapping from input to stored order total to provider amount. Existing records from a real order can help connect that path to actual activity. Keep currency and amount representation visible in the explanation so a formatting difference is not mistaken for a price decision.
A valid verification packet identifies which browser values are accepted as selections, which are independently checked and which cannot set the total. It also points to the rule governing a rejected or unauthorized change. Documentation that describes a provider feature without showing how the installed integration uses it leaves implementation unverified.
Have the implementer demonstrate the boundary through the existing implementation and available verification evidence. Do not alter a live customer's request, manufacture an underpriced order or create a payment to prove the concern. If existing evidence does not establish rejection behavior, record that limitation and agree the separately authorized investigation needed to close it.
Make the next decision from what the trace establishes
If the trace shows that the server trusts a client total without an authoritative calculation, record the affected checkout path and deployed version as a concrete defect. The merchant and implementer should agree the correction and operating response for that path. Do not erase real order or payment evidence while investigating possible consequences.
If the server independently calculates and authorizes the amount, retain the evidence and examine any remaining mismatch at the order or payment stage where it occurs. If the code path or deployed version cannot be identified, the boundary is unverified; a normal successful order does not settle it.
For a Prism checkout-review consultation, describe the observed issue, platform, payment integration and missing evidence in ordinary language. Agree whether investigation or implementation is included, who owns it and what evidence will establish completion. A technical correction neither grants provider approval nor establishes the legal eligibility of the research-only catalog.
Amount authority record
Complete this from the actual deployed checkout and existing real records. Use nonsensitive references or evidence-status notes. Conclude supported, contradicted or unverified for each checkpoint; matching totals alone do not establish that the server rejects unauthorized values.
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.
Amount authority record. The last column is for temporary notes.
Checkpoint
Evidence to request
What it establishes or leaves open
Your finding
Catalog price source
Evidence to requestServer-side lookup or configured price record used by the deployed amount handler.
What it establishes or leaves openIdentifies the authoritative price source, rather than the browser's displayed copy.
Approved order adjustment source
Evidence to requestExisting approved order price, discount or other adjustment and the rule that applies it.
What it establishes or leaves openShows the basis for a permitted difference from catalog price; does not authorize arbitrary client adjustments.
Browser-supplied value
Evidence to requestDescription of input fields and how the server uses or discards each monetary value.
What it establishes or leaves openA submitted total alone does not show whether it controls payment.
Server calculation owner
Evidence to requestNamed component and maintenance role for items, shipping, discounts and tax in the installed integration.
What it establishes or leaves openIdentifies who can explain or repair the computation; do not infer the API from the payment widget.
Order-change authorization
Evidence to requestDeployed check connecting the requester and permitted change to the relevant order.
What it establishes or leaves openSeparates permission to change an order from the arithmetic used to total it.
Provider amount handoff
Evidence to requestTrace of the calculated amount and currency into the existing create or update call.
What it establishes or leaves openConnects server authority with the amount actually requested from the provider.
Existing verification evidence
Evidence to requestRelease identifier, relevant code or configuration and existing real-order evidence with sensitive values removed.
What it establishes or leaves openBounds the conclusion to the implementation examined; missing rejection evidence remains an explicit gap.
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
Stripe documentation describes Stripe integrations. It does not prove what a particular store, plugin or other provider has implemented.
This is an evidence review, not authorization to manipulate customer requests or create fraudulent, fabricated or test payments.
Keep API secrets, authentication tokens, client secrets, private payment links, card details and customer data out of the worksheet and public inquiry.
Stripe Payment Element — checked 2026-09-29. Payment Element supports Checkout Sessions or Payment Intents. Sessions includes checkout features; with Intents, the implementer owns tax, shipping and discount checkout logic. This does not identify a store's installed integration.
Stripe dynamically update payment amounts — checked 2026-09-29. Stripe requires recalculating and authorizing amounts on the server rather than trusting client totals. The documentation does not establish that an unseen integration implements this boundary.