In this piece
Both software vendors say they’re done. What should you test before signing off?
Customers had paid. Their orders never arrived. When they contacted support, the operator looked at its own software and saw the payments as outstanding. The payment webhook had never been configured. Without monitoring for that discrepancy, the operator learned about it from a stream of support requests.
That case comes to mind when a buyer asks me how to accept a release that spans two vendors. A payment can succeed in one system while the business has nothing to deliver in the other. When Wavect is one of the suppliers, I expect the buyer to ask us the same question I’d ask any other team. Can we follow one transaction all the way through?
What result did you buy from the two vendors?
Write down the outcome the operator needs before opening either test report. For a checkout, my acceptance criterion would be that a buyer can pay once and the operator can find exactly one paid order ready for fulfilment. Both teams can now work backwards to the agreed requirements, including what happens when a step fails.
Agree on the operating conditions too. Ten thousand customers in a month and ten thousand people arriving together for a product drop are different test briefs. Ask the business what peak it expects, which actions those people perform at the same time, and what a delay would cost. That gives the engineering team a realistic target.
How do you prove a successful payment became an order?
For a joint acceptance run, I’d ask both vendors to use their intended release versions in a shared test environment. Take one reference through payment, the server-side notification and the order store. Then ask someone in operations to find the order with the tools they use on shift. In a hosted checkout, the buyer can close the browser before returning to the shop. Stripe’s fulfilment guide explains why server-side payment events matter in that situation.
In a controlled test, delay the notification and deliver it again. Can the team see the discrepancy, recover the missing order and show that a second delivery creates no duplicate? Stripe’s webhook documentation describes delivery attempts, retries and duplicate events. A provider’s delivery log and the merchant’s paid order answer different questions. Our walkthrough of a payment that stays pending in the shop goes into the technical diagnosis.
What belongs in a joint acceptance record?
I’d use one shared record for the business flow. Each supplier can attach its component tests. A named owner follows the same reference across the boundary and records what the operator saw. Here is a template for the checkout example. The buyer can fill in the last column during the demonstration.
| Field | What to ask both vendors to show | What to record |
|---|---|---|
| Requirement and scope | One captured payment produces one order ready to fulfil. | Requirement ID, both build versions and environment. |
| Successful purchase | Trace the same purchase from the provider to the operator’s order view. | Test reference, observed final state and evidence link. |
| Interrupted purchase | Show who sees a delayed event and how processing recovers. | Alert, responsible person, recovery and duplicate check. |
| Decision and follow-up | Identify remaining exposure and who can accept it. | Decision, owner, open items and retest date. |
How much checking is enough for a reliable vendor?
A trusted developer changing a button label can usually show me the change in the normal review. Requiring three people to repeat it costs time and tells a reliable colleague their judgment counts for little. A change that moves customer money warrants a repeatable end-to-end test and someone other than the implementer reading the evidence. A first release may have few users and still handle a payment that hurts to get wrong.
For a critical flow I’d also have someone test it manually, including the support operator’s view. An adversarial AI review can suggest a missed assumption, such as what the system does if an event arrives twice. A human decides which concern matters and verifies it against the release. Google’s SRE guidance on monitoring explains why it helps to observe both the user-visible symptom and the system’s internal signals.
Who can accept the delivery, and who owns the next failure?
Ask each vendor what it tested, which version the evidence covers, and where its responsibility ends. Name the person who can accept the delivery for the buyer and the person who can authorize production deployment. For a paid order the operator cannot find, I would hold the affected flow until there is a successful joint retest and a way for support to spot a recurrence.
Before signing, check the agreed defect and maintenance terms. If a vendor offers 30 days of fixes, establish which defects qualify, who investigates a problem between suppliers and who takes the call afterwards. The cost of more testing, the cost of an undetected failure and the vendor’s track record are what I’d weigh when choosing the depth of the review.
Our Polity case study describes how we reviewed deliveries across several teams on a separate project. For the rest of a release, see our pre-launch QA checklist. Our first-month QA benchmark covers how to judge an ongoing engagement. If you need independent software QA for a specific handover, bring the flow and the two vendors’ existing test results.