Calculate First-Order Contribution Before You Scale an Ecommerce Offer

Revenue tells you what was sold. It does not tell you what remains after delivery and acquisition. Before scaling an offer, calculate the contribution from the first order using a consistent unit and period. Then check whether the checkout actually creates the order and fulfillment action you think it does.

This model does not predict lifetime value, repeat purchase or net profit. It leaves fixed overhead, tax, financing and cash timing outside the calculation. Add those separately before making a business decision. Use your actual refund and cost treatment without counting the same adjustment twice.

1. Define the unit and net revenue

Choose one order or customer cohort and one currency. Record the amount collected for the product after applicable discounts and the refund allowance or actual refunds for that cohort. Decide how taxes and customer-paid shipping are treated, and keep that treatment consistent with your accounts. Do not mix a tax-inclusive selling price with tax-exclusive costs without understanding the difference.

For a planning model, label refund assumptions as estimates. For a completed cohort, use observed data where available and explain whether later returns are still possible. Net revenue is not the same as the advertised list price or the amount before a discount.

2. List variable delivery costs

Include product cost, packaging, pick/pack, shipping subsidies, transaction fees and other costs that change with the order. Use a documented allocation for mixed costs rather than assuming they are zero because the bill arrives monthly. Keep fixed overhead separate so you can see what contribution must cover.

Refund processing and reverse logistics may create costs even when revenue is returned. Decide whether they are already included in your refund allowance or need their own cost line. The goal is a complete consistent model, not a particular margin percentage. Ask your finance owner to reconcile definitions with the business accounts.

See the actual example

3. Add fully loaded acquisition cost

Include relevant ad spend, creative, commissions, attributable sales labor and acquisition tools for the same cohort. Divide by new paying customers when calculating CAC. Do not divide acquisition cost by every historical customer or by unpaid signups. If there are no new customers, CAC is undefined rather than zero.

The calculator below estimates per-order contribution using your entered values. It is not connected to a store or ad account. A positive result means contribution remains before fixed costs; it does not prove the offer is ready to scale or that the modeled acquisition cost can be achieved.

4. Test payment and order creation separately

In your provider’s authorized test environment, complete a successful checkout and a failed or canceled attempt. Confirm the payment state and the order state independently. A browser success page is not a reliable fulfillment trigger because the customer may never return to it or may reload it.

Stripe’s fulfillment guidance describes using supported server-side events and making fulfillment safe when invoked more than once. Follow your actual provider’s integration and signature-verification requirements. Never mark an order paid solely because a query parameter says success, and do not run live charge/refund tests without appropriate authorization.

Worked example — illustrative or dated as stated

Illustrative first order: $100 collected, $10 expected refunds, $30 product cost, $8 shipping, $3 fees and $25 acquisition cost. Contribution is $24 before fixed overhead and tax treatment. If refunds were already deducted from the entered collected amount, subtracting the $10 again would understate contribution.

5. Verify fulfillment, refund and duplicate handling

Write cases for delayed payment, repeated event delivery, refund and cancellation. Define which system owns each transition. A duplicate webhook should not create a second shipment. A refund should update the financial and operational state according to your process, not merely change the text on a dashboard.

Keep a secure internal reference linking the order, payment and fulfillment records. Do not expose payment credentials, card data or customer details in screenshots or analytics. Save test evidence with fictional or provider-issued test data and verify the actual destination record, not only the visible page.

6. Review contribution and cash before increasing volume

Compare the modeled order with actual cohort results. Look at refunds, fees, shipping differences, customer support and acquisition quality. Investigate a variance rather than replacing the original assumption after the fact. Repeat purchases can improve economics, but they should be supported by observed cohorts before funding acquisition against them.

Check cash timing and capacity: supplier payments, payment settlement, return windows and fulfillment workload can create problems even with positive contribution. Choose a bounded next experiment and assign a review owner. Scaling an unverified process multiplies its errors as well as its sales.

Sources and scope

Primary-source guidance checked October 27, 2026. Interfaces and policies can change; consult the linked current source. Practice screenshots and modeled examples are labeled and are not client campaign results.

• Stripe checkout fulfillment guidance
• Acquisition cost guide

Your next step

Continue with the related implementation lesson →