A currency amount was scaled incorrectly before payment
Trace the currency code and numeric unit at every boundary: the displayed price, stored order total, gateway input, outgoing provider request and resulting provider record. Stripe API amounts use the currency’s documented minor-unit representation, with zero-decimal and special-case exceptions; multiplying every amount by one hundred is not a universal rule. Locate the first point where the represented monetary value changes, and have the amount-calculation owner resolve it before further affected payments are accepted. A suspicious size difference is a clue, not proof of a scaling defect.
For: A research-only merchant or authorized integration owner investigating a submitted payment amount that is much larger or smaller than the agreed price.
Begin with one genuine affected order and its actual payment request. Confirm the currency code as well as the number at each stage. Compare the submitted amount with the agreed payable total, including the actual item, discount, shipping and tax components already recorded on the order. Comparing a product unit price with the full order total can create an apparent discrepancy that has no unit-conversion cause.
Keep the displayed amount and the underlying stored value separately. The display may format decimal separators or show a symbol without revealing the unit used in storage. Record whether the integration treats a value as major currency units, minor units, or formatted text. If you cannot establish that from the real configuration or code owner, mark the representation unknown instead of interpreting the digits by appearance.
Read the charge rule for the exact currency
Stripe’s supported-currencies documentation says API amounts use currency minor units and identifies zero-decimal currencies and special cases. The charge representation must follow that documentation rather than a universal assumption of two decimal places. ISK and UGX require a two-digit compatibility representation without fractional currency units. That differs from simply accepting a decimal fraction because two digits are transmitted.
The same document distinguishes HUF and TWD charge handling from payout handling. Make sure the rule being applied is for the operation in this trace. A payout constraint cannot be substituted for the rule governing a customer payment. These Stripe conventions do not establish another provider’s amount representation, and a supported currency does not establish that the account or research-only catalog is eligible.
Find the first boundary that changes the value
Read the trace from the agreed order total forward. For each boundary, record the value received, its unit, the transformation performed, and the value passed on. Express both sides in the same monetary unit using the applicable currency rule. Different raw numbers can represent the same monetary amount when the units differ; equal raw numbers can represent different amounts when the unit changes.
If the stored total is correct but the outgoing provider amount represents a different monetary value, investigate the calculation or serialization between those points. If the provider request represents the right amount but the displayed page does not, the evidence points toward presentation instead. Check for a conversion applied twice, a conversion omitted, or rounding performed at a different stage, but describe each as a hypothesis until the recorded values and the responsible code support it. A neat numerical ratio alone does not locate the fault.
Separate the correction from existing payment outcomes
Preserve the original request evidence and determine whether the provider rejected the request, left a payment unresolved, or recorded a completed payment. A wrong submitted number does not prove that the buyer paid it. Conversely, changing a stored order total does not demonstrate that an earlier provider payment changed. Reconcile each affected order and provider record before deciding on any refund or further payment request.
The amount-calculation owner should identify the exact currency and operation rule, the boundary to change, and the evidence that the corrected calculation represents the agreed amount. Keep the affected route from accepting further incorrect payments until that is established. For a Prism checkout consultation, provide the platform, gateway version, currency and a sanitized description of the boundary where values diverge. Scope, responsibilities, fees and any implementation work are confirmed before work begins.
Amount representation trace
Fill this from one real affected order and its authorized integration records. Write the currency, unit and observation time with each amount. Compare monetary values only after applying the exact currency and operation rule. The first unequal value identifies an investigation boundary, not an automatic cause or authority to charge again.
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 representation trace. The last column is for temporary notes.
Trace point
Evidence to capture
Interpretation
Your trace
Currency code
Evidence to captureCurrency code on the order and outgoing payment request; the operation being performed.
InterpretationA different currency needs a currency-flow investigation before diagnosing a numeric-unit mismatch.
Store displayed amount
Evidence to captureThe amount and currency shown for the actual order, with its included charges and discounts.
InterpretationEstablish the agreed payable total rather than comparing a product price with an order total.
Order stored amount
Evidence to captureThe stored total, documented unit and component totals inside the store’s authorized records.
InterpretationDetermine whether the value itself differs or only its public formatting does.
Gateway input
Evidence to captureValue and unit passed from the order calculation to the integration component.
InterpretationLocate any change before the provider request is assembled.
Provider submitted amount
Evidence to captureOnly the outgoing numeric amount, currency, documented unit and timestamp from a sanitized request record.
InterpretationInterpret the amount using the charge rule for this currency; do not copy a complete request containing secrets or customer data.
Provider recorded result
Evidence to captureProvider amount, currency and exact payment status for the matching attempt.
InterpretationSeparate a rejected or unresolved request from money actually collected.
Conversion or rounding owner
Evidence to captureNamed component and maintainer responsible for each scale conversion or rounding operation.
InterpretationInvestigate the first boundary that changes the represented value; confirm the applicable exception before changing code.
Authorized resolution
Evidence to captureAffected-order reconciliation and the merchant’s decision after the owner explains the correction.
InterpretationKeep existing payment remedies separate from restoring the amount calculation for future payments.
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 amount-unit rules apply to the named currency and operation. They do not establish another provider’s convention or a universal charge limit.
This trace cannot determine an unseen integration’s cause or authorize refunds, extra charges, tax changes or currency-market eligibility.
Record only sanitized numeric evidence. Exclude API keys, payment tokens, card data, authentication codes and private customer records from the worksheet and public consultation form.
Stripe supported currencies — checked 2026-09-29. API amounts use currency minor units with zero-decimal and special-case exceptions. ISK and UGX require two-digit compatibility representation without fractional units; HUF and TWD charge and payout handling differ. These rules do not identify the cause of an unseen amount mismatch or establish merchant eligibility.
Prism solutions — checked 2026-09-21. Prism discusses storefront review, processing preparation and provider website questions within an agreed scope. Scope, fees and terms are discussed before work; provider eligibility remains separate.