Find who owns the calculations after a payment rebuild

Identify the API separately from the payment form

The label Payment Element does not answer which system calculates the order. Stripe supports that same payment interface with two different underlying APIs. A checkout can therefore look familiar while its integration contract has changed. Ask for the previous and deployed API names alongside the old and current UI, with a dated release record or implementation reference supporting each entry.

A change from Checkout Sessions to Payment Intents can move checkout work into code or services the implementer must arrange. It does not prove that work was omitted. Conversely, using Sessions does not prove that every available feature is configured for your store. The question is what this implementation actually enabled and where each calculation now happens.

Follow each amount back to its rule

For tax, identify the component that produces the amount, the inputs it uses and the record that preserves the result. Separate the merchant's tax requirements from the software responsible for applying configured rules. This comparison can expose a missing calculation handoff; it cannot decide whether the business owes tax in a jurisdiction or whether its chosen rate is correct.

For shipping, distinguish a destination field, a selected service and a calculated charge. Recording an address is not evidence that a rate was calculated. Trace the selected method and its price from the store or external calculation service into the order total and the amount requested for payment.

For discounts, record where eligibility and value are decided and how the result reaches the final total. A coupon field is only an input. Its presence does not show that the rebuilt integration evaluates the offer. Name the system that determines the reduction and the component that passes it onward. Keep any interaction with shipping or tax explicit in the implementation record, rather than assuming the old order of calculation carried over.

Separate missing logic from missing display

Use retained records for an actual affected order to compare the item amounts, discount, shipping, tax, final order total and provider payment amount. Keep the currency and order reference aligned. Read the components using the store's documented tax-inclusive or tax-exclusive treatment; adding a displayed tax amount again may misread an already inclusive total. The aim is to trace recorded amounts, not invent a replacement formula.

If the calculated components exist and reach the amount requested for payment but disappear from the page, the evidence points to a presentation issue. If a configured component never produces a result or its result does not reach the payment amount, the calculation or handoff remains unresolved. A matching final amount alone is insufficient: it may conceal offsetting differences between components. An absent line also does not prove the correct value was zero.

When no relevant real order or retained calculation record exists, mark that behavior unverified. Do not create a sale to fill the worksheet, and do not change a past order simply to make it agree with the rebuilt checkout. Preserve the discrepancy so the implementer can identify the responsible step.

Accept a defined responsibility handoff

For each required feature, record both a system owner and a person responsible for maintaining it. A useful handoff says where the rule is configured, which component calculates the result, where the result is stored and how it reaches payment. Mark a feature preserved, intentionally changed under the agreed scope, or unresolved. A requirement with no identified calculation owner is an open deliverable even if the payment button works.

The merchant can compare this evidence with the rebuild agreement and keep specific omissions open before accepting the flow. For a Prism checkout-review consultation, summarize the API change and the calculation that cannot be traced. Scope, responsibilities, fees and terms must be agreed before work begins. Technical functionality is separate from provider permission to process the disclosed research-only business.

Checkout-feature responsibility comparison

Complete both sides from the real integration and its retained records. In the final column, record the previous owner, current owner, evidence reference and unresolved action for each feature. Unknown ownership or an untraced amount remains an open acceptance item.

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.