A hosted payment line points to the wrong catalog price
Start with the affected Checkout Session and the line-item data supplied when it was created. Determine whether the integration sent a Stripe Price ID or explicit price_data. For a Price reference, trace that exact ID to its provider catalog record and compare its product association, amount and currency with the intended store item. For explicit price data, compare the supplied values with the store’s own price source. Locate the first disagreement before editing the public catalog or deciding whether a completed payment needs a remedy.
For: A research-only merchant whose Stripe-hosted Checkout line appears to use a different item or price from the store’s intended offer.
Identify the affected Session before comparing prices
Keep the store item or variation reference, the affected Session reference and its creation time together. Preserve the intended item, quantity, unit price and currency from the order or other retained record that belongs to that attempt. A product page viewed today may show a later edit; it does not by itself establish what the store intended when the Session was created.
Inspect the actual Session line and the available creation record through authorized access. Record the provider account context as well as the identifier so that the comparison uses the same catalog and Session. A product name that looks right is a useful clue, but the reference chain is what connects the store item to the provider record.
Keep private Checkout URLs, customer data and request credentials out of the worksheet. The internal Session identifier and the relevant catalog fields are sufficient for an authorized team to locate the records; the public consultation needs only a description of the discrepancy.
Determine which line-item path supplied the price
Stripe documents two ways to supply Checkout line items: Price references or explicit price_data. A Price ID points to a Price object created through Stripe’s Dashboard or API for catalog information held in Stripe. Explicit price_data can instead carry price and product information from the application’s external source. These paths require different evidence.
If the request used a Price ID, compare the exact submitted identifier with the mapping assigned to the store item. Then inspect that Price’s associated product and the amount and currency shown in the provider record. Record a mismatch in the identifier separately from a mismatch in the intended price. A correct product association alone does not complete the amount comparison.
If the request supplied explicit price data, preserve the supplied price and product values and identify the store record or calculation that produced them. Do not invent a configured Price ID merely to fill the worksheet. If the creation input is unavailable, mark the input path unconfirmed and ask the integration owner to identify it from retained records; the visible line label alone does not settle the question.
Find the first disagreement in the chain
Compare the store item’s intended mapping with what the application actually supplied. If those differ, the investigation belongs at the selection or mapping step. If the intended mapping and the submitted Price agree but the provider record describes a different amount or product, the mapping’s suitability is the unresolved issue. If the creation input and the Session line disagree, preserve both references for the integration owner to explain before changing either side.
Compare unit price with unit price and currency with currency before using the final payable total. Keep quantity and any recorded discount, tax or shipping components separate. Stripe Checkout supports such features within defined boundaries, but their presence in documentation does not mean your connector enabled them. A difference only in the total does not establish that the wrong Price ID was selected.
Also record whether the Session is for a one-time payment or a subscription. Stripe distinguishes those modes and supports mixed one-time and recurring carts in subscription mode. The intended purchase and the actual mode must agree; a matching first amount alone cannot settle the recurring-versus-one-time question.
Scope the correction from the evidence
Once you locate the first verified mismatch, record the affected mapping or input, the intended value and the person authorized to change it. Preserve the original Session evidence. A new catalog edit is not evidence that an earlier Session or completed payment now matches the intended offer. Review the actual affected payment state separately before deciding any refund or other customer remedy.
If the mapping is corrected, the relevant confirmation is that an actual subsequent Session from the affected store path carries the intended item and price data. Until that record exists, describe the mapping change as made but its later Session result as unconfirmed. Do not create a payment or invent an order to complete the worksheet.
For a Prism checkout-review consultation, describe the website, research-only products, connector and the specific mapping disagreement. Ask what investigation or implementation help can be included; scope, responsibilities, fees and terms are confirmed before work. Technical Checkout functionality does not establish provider approval for the business. The public form excludes payment details, passwords and customer records; email follow-up is not a booking, purchase or processing application.
Catalog-to-price reference map
Use one real Session line. Compare each step with its preceding source and mark the first verified disagreement. For explicit price_data, record that path instead of inventing a preconfigured Price reference. Keep this internal and omit private payment URLs and credentials.
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.
Catalog-to-price reference map. The last column is for temporary notes.
Mapping step
Record to compare
Meaning of a disagreement
Your finding
Store item reference
Record to compareItem or variation identity and the retained offer or order at Session creation.
Meaning of a disagreementA current product page alone cannot establish the earlier intended offer.
Provider Product reference
Record to compareThe product associated with the referenced Price, or product information supplied with explicit price data.
Meaning of a disagreementA different product association requires tracing the store-to-provider mapping.
Provider Price reference
Record to compareThe exact submitted Price ID against the mapping intended for this store item.
Meaning of a disagreementA different ID points to selection or mapping; explicit price data is a separate input path.
Intended amount and currency
Record to compareThe retained store unit price and currency against provider price fields or explicit values supplied.
Meaning of a disagreementCompare the same unit basis before drawing a conclusion from the final total.
Session line item
Record to compareActual Session line, quantity, creation time and the corresponding creation input where available.
Meaning of a disagreementDetermine whether the line follows what the application supplied; keep missing input evidence unconfirmed.
Purchase mode
Record to compareThe intended one-time or recurring offer and the actual Session mode.
Meaning of a disagreementA matching amount does not establish that the intended purchase type was selected.
Total components
Record to compareRecorded quantity, discounts, tax and shipping, where present.
Meaning of a disagreementA total-only difference may require a separate calculation investigation rather than a Price-ID change.
Correction and follow-through
Record to compareThe named mapping change owner and any genuine later Session from the same store path.
Meaning of a disagreementSeparate a changed configuration from evidence that a subsequent Session uses it correctly.
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 guide concerns Stripe Checkout Sessions and the documented Price-reference or explicit-price-data paths. Another provider or connector requires its own mapping evidence.
Catalog and Session evidence do not establish payment success, authority to refund, merchant eligibility or legal approval.
Do not include card data, authentication codes, API secrets, customer records or private payment-link tokens in the worksheet or public form.
Hosted Checkout flow and line-item responsibilities — checked 2026-09-29. Checkout Session creation supplies line items through Price references or explicit price data. Payment and subscription modes differ, subscription mode supports mixed carts, and quantity, tax, shipping and discount features have defined boundaries; documented features do not establish connector support or merchant eligibility.
Prism solutions — checked 2026-09-21. Published support covers storefront review, card-processing preparation and help with provider website questions. Scope, fees and terms are discussed before work; providers decide eligibility and account terms.
Prism contact — checked 2026-09-21. The form takes website, products and question, excluding card details, passwords and customer records. Follow-up is by email; an inquiry does not book an appointment, purchase work or submit a processing application.