Budget the merchant's retained cost separately from the customer's refund
A customer receives a full refund, yet the merchant's account does not return to the position it held before the sale. That can be correct under the merchant's actual processing terms. A cost estimate that assumes every charge disappears when an order is refunded can therefore understate the cost of operating the service.
This worked budget uses expressly fictional merchant terms and test figures. It does not describe Vipps pricing or any other provider's current fees, and it does not decide a customer's refund rights. The purpose is to show which commercial facts an implementation and operating estimate need to keep separate.
Read the terms for the relevant operation
The fictional merchant sells an item for NOK 1,000. Its reviewed provider quotation charges NOK 30 to process the original payment. The agreement says that this fee is retained when the merchant later refunds the full customer amount. For this example, no additional refund fee applies.
The finance owner records those assumptions explicitly. A different merchant arrangement could return the original fee, charge an additional amount or apply another structure. The project must use the actual approved terms rather than borrow a percentage from a demonstration.
The customer refund is NOK 1,000. The retained merchant processing cost is NOK 30. Describing the order as fully refunded answers the customer-money question; it does not establish that the merchant's original fee has been reversed.
Reconcile one transaction before estimating a month
In the fictional ledger exercise, transaction P-61 records the original sale, processing charge and full refund as distinct entries. Before other operating costs, the sequence is:
| Entry | Effect on the merchant balance in the exercise |
|---|---|
| Customer payment | +NOK 1,000 |
| Original processing fee | −NOK 30 |
| Full customer refund | −NOK 1,000 |
| Net effect of these entries | −NOK 30 |
The review confirms that the customer receives the entire NOK 1,000 while the merchant retains a NOK 30 cost. It does not reduce the customer refund to recover the fee or change the meaning of full refund. Any customer-facing policy is a separate decision for the business and its appropriate advisers.
A second transaction, P-62, remains an ordinary completed sale. Its own fee and balance are unchanged by P-61's refund. An uncertain refund outcome remains unresolved until the actual provider evidence establishes it; a budget assumption cannot be used to mark a financial operation complete.
Make a completed budget choice
The merchant plans a fictional first operating period with 80 payments of the same amount and 8 full refunds. Under the stipulated fee terms, the 80 original processing fees total NOK 2,400. The eight refunded sales account for NOK 240 of that total; refunding them does not reduce the processing-fee budget to NOK 2,160.
The finance owner therefore approves a NOK 2,400 processing allowance for this narrowly defined volume scenario, alongside a separate allowance for other operating costs. This is not a quotation or a forecast of actual customer behaviour. It is an internally consistent planning example based on explicitly chosen volumes and terms.
The team also records the review trigger. If transaction volume, refund frequency, average payment amount or provider terms differ from the assumption, the budget is recalculated from the relevant agreement and observed records. An unusually high refund rate may justify investigation of the offer or customer journey; it does not by itself authorise changing the customer's financial treatment.
Reflect the distinction in the software scope
The staff tool should let the finance owner identify the payment, refund and fee evidence appropriate to the account. It should not overwrite the original fee with zero merely because the customer-money state changes. Reports need labels that reveal whether they show gross sales, returned customer funds, processing costs or a defined net figure.
This is also a question for the integration estimate. Can the supported provider interface supply the needed fee information, or does finance reconcile it from a separate statement? If the first delivery uses an approved manual statement process, record who performs it and what the software does not calculate.
Development and acceptance use provider-permitted test facilities or designated data. The figures here do not justify live charges or refunds, and project approval is not a substitute for provider permission. The technical demonstration and any later permitted operational verification have separate evidence.
Bring the commercial document to the scope review
Ask the account owner to identify which fees apply to the original transaction, what happens on refund and where the evidence appears. Then compare the expected operating volume with the actual budget model. This produces a more useful estimate than assuming that a fully reversed customer payment means a cost-free transaction.
For commerce development, bring the relevant provider arrangement and the decision staff need to make. The pricing and scope page explains how those continuing costs sit beside the development work itself.