One order creates several payment amounts in the history
That depends on whether the provider is asking about purchase size or individual collected payments. Preserve both views: the underlying order and each actual payment event linked to it. A deposit and a final balance can be separate collections for one purchase, while an authorization is not another collected amount to add to its capture. Obtain the requester’s definition of ticket size before choosing the reporting unit, included events and period. Do not present either view as a universal formula.
For: An owner of a research-only business preparing an application from orders that have deposits, final balances or multiple payment records.
Build one order record with its payment events beneath it
Start with the real order or invoice that establishes the purchase and its agreed total. Preserve any documented changes rather than replacing the original history with a later amount. Then list the actual payment events associated with that obligation, including the deposit and final balance only when those events exist in the records.
For each event, record its type, amount, currency, date, status and private reference linking it to the order. Identify whether it was a collection, an authorization, a refund or another adjustment. A label such as deposit on an order is a description of purpose; the provider record is what establishes the associated payment’s state.
Keep an outstanding balance separate from collected history. An order commitment can exceed what has been collected so far, and more than one collected payment can relate to that commitment. Those differences are information the application may need, not differences to remove by collapsing all rows into one amount.
Do not count the authorization and capture as two collections
Stripe’s authorization-and-capture documentation distinguishes holding an amount from capturing it. Default capture takes the authorized amount, while capturing less normally releases the remainder. Most payments allow one capture; retaining and capturing the remaining amount requires supported multicapture. Those rules mean that an authorized amount plus a captured amount is not automatically a sum of two payments.
Use the actual captured amount for a collection record, then preserve the authorization as its related earlier stage. If a deposit was a completed payment and the later balance was another completed payment, retain the two collections. If the record instead shows a partial capture from one authorization, do not label the released remainder as a collected deposit or an unpaid final-balance transaction.
This is a reconstruction of recorded events. It does not authorize taking another payment, splitting a purchase to avoid limits or assuming the account supports multiple captures. Another gateway’s event names and capabilities must be established from that gateway’s own records and guidance.
Keep the reporting unit and period consistent
A count of underlying purchases and a count of collected payment events answer different questions. For an order-based view, keep the purchase as one underlying record and show its payment history alongside it. For a payment-based view, keep each qualifying collection as its own event while preserving the shared order reference. Do not add the purchase total to its deposit and final balance: that would count the same obligation again.
Ask the requester whether ticket size means the full purchase obligation, each completed payment, or another specified measure. Also confirm which date assigns a record to the period, which currency basis to use, and how refunds, incomplete orders and failed attempts should be treated. If a deposit and a final balance fall in different periods, preserve their real dates; moving one to force a complete order into the period would change the history.
Stripe’s balance summary report covers a selected period in settlement currency and separates gross, fee and net activity. Its itemized transactions can help trace the amounts, but the report does not define a provider application’s ticket-size field and does not associate payouts with payments. A net payout cannot establish either the original order size or each collected payment’s size.
Report the chosen measure with its supporting map
After clarification, select the relevant records from the preserved map and retain the definition beside the reported figure. If the request asks for an average, use the amount sum and count from the same defined unit, period and population. Do not divide order totals by payment-event counts or mix currencies without the requester’s specified basis. If it asks for a largest ticket, choose the largest qualifying record under that same definition.
If the definition remains unanswered, label the order-based and payment-based summaries separately for discussion rather than silently entering one as the requested measure. Explain that the records include deposits and later balances, and identify the exact field needing clarification. This preserves usable history without inventing a provider rule.
For a Prism processing consultation, describe the actual payment sequence and the ambiguous application field. The consultation can help organize the business description; the requesting provider decides the reporting definition and sufficiency of the evidence. Scope, responsibilities, fees and terms are confirmed before work. Do not send invoices, customer lists or full payment references through the public form.
Order-to-payment measurement map
Use this with actual orders and their payment histories. Keep a separate event entry for every relevant payment, linked to its underlying order in your private working record. The final column is for your findings. Do not calculate the application figure until its reporting unit and inclusion rules are established.
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.
Order-to-payment measurement map. The last column is for temporary notes.
Measurement fact
Evidence to retain
What it prevents
Your record
Underlying order reference
Evidence to retainA safe internal order label, agreed purchase amount, currency and documented amendments.
What it preventsCounting a deposit and final balance as unrelated purchases or losing the original obligation.
Payment event type
Evidence to retainThe actual provider type and status, with its role as deposit, balance collection, authorization or adjustment.
What it preventsTreating every historical row as a completed payment.
Collected amount record
Evidence to retainEach verified collected amount and date linked privately to the order and any related authorization.
What it preventsAdding a hold to its capture or counting an outstanding balance as collected.
Order and payment counts
Evidence to retainSeparate counts of the underlying purchases and qualifying collected events.
What it preventsUsing an order-based numerator with a payment-based denominator.
Period and currency
Evidence to retainThe source records’ dates and currencies, including the settlement currency of any Stripe balance export.
What it preventsMoving payments across period boundaries or adding unlike currency amounts.
Requested definition
Evidence to retainThe exact application field and whether it asks for an order, a collected payment, an average or a largest amount.
What it preventsChoosing a ticket-size formula from the label alone.
Provider clarification
Evidence to retainThe requester’s written definition, date basis and rules for refunds, incomplete orders and unsuccessful attempts.
What it preventsPresenting an unconfirmed interpretation as the provider’s requirement.
Final reported basis
Evidence to retainThe selected records, matching count and amount basis, and safe references to the supporting map.
What it preventsLosing the explanation of how the application figure was produced.
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
No universal ticket-size definition is established here. The requesting provider determines the measure required for its application.
Stripe capture behavior and reports apply to the documented Stripe products. Historical records do not authorize a payment action or establish multicapture eligibility.
Keep card data, private payment links, bank details, customer invoices and full transaction references out of the worksheet and public consultation form.
Stripe authorization and capture: partial capture boundary — checked 2026-09-29. Default capture takes the authorized amount; partial capture normally releases the remainder. Most payments allow one capture, and retaining or capturing the remainder requires supported multicapture. This does not establish an application’s ticket-size definition or authorize additional payment actions.
Stripe balance summary report — checked 2026-09-21. The report covers a selected period in settlement currency and provides itemized activity with gross, fee and net components. It does not associate payouts with payment transactions or prescribe how a provider measures order versus payment size.
Discuss my processing options
Want to talk through your own processing situation?