Scope a prepaid integration before you estimate the build
A build estimate should cover what happens before and after the API call. Who approves an order, how does it get funded, and who checks the statement if the response never comes back? Answer those questions before asking for a price.
| Workstream | Define before estimating |
|---|---|
| Catalogue | Products, values, identifiers |
| Funding | Wallet or invoicing assumptions |
| Orders | Inputs, approval and reference |
| Outcomes | Status checks and exception owner |
| Closeout | Statement and reconciliation |
By Freepaid · Published
Break the build into work packages
Take a batch of 500 orders. Price the work to validate the file, prevent duplicate purchases, handle a batch that only partly completes and save the records finance needs. Those are separate jobs with different dependencies.
Draw the flow or write out the steps. Name who creates and approves the batch, where you check funds, how you assign references and who reviews the results. Check what the current app already does, then price what’s missing, such as credential storage, logs, alerts, safe retries and reconciliation. Ask the supplier about rate limits, maintenance notices and what support needs to trace a case.
Build an estimate from deliverables
Break the estimate into discovery, catalogue mapping, authentication, order submission, status retrieval, finance export, monitoring, support procedures and release. Mark what the supplier provides and what your application must own. Estimate integration and operational work separately so that recurring support is visible.
For a single-product workflow, catalogue mapping may be small, but approval, reference generation and reconciliation still need decisions. For multiple products, include validation rules and how the user sees differences between airtime, data and voucher products.
If the supplier has not explained its pending status, find out how to check the original order before you estimate retries. Record which confirmed failures are eligible for resubmission and which assumptions or missing answers could change the estimate.
Put numbers against the work packages
For each part of the estimate, name who owns it and what has to happen first. Check the work to import products, authenticate, validate orders, approve them, assign references, send them, check status and reconcile. Price monitoring, the support guide and deployment too. Ask the supplier for its test environment and support process.
For a 500-order month, consider what happens if 5 orders contain invalid data. Say who corrects those records and when they can send the corrected orders. Measure that handling time along with file validation, duplicate checks, report exports and incident support.
Get the supplier to demonstrate any uncertain behaviour before you put a fixed price on it. In particular, agree how staff check the original reference after an unclear response and what evidence and approval they need before sending a replacement.
Agree what the estimate excludes
Ask the delivery team to identify which tasks are already supported by existing software. Do not estimate duplicate functionality. For each dependency, name the supplier contact, expected response and decision date. If any supplier behaviour remains unclear, carry it as a discovery risk rather than disguising it as a fixed build assumption. Revisit the estimate when the catalogue, order states or finance data contract is confirmed.