Business logic testing: prove the approval boundary

Start with a transaction state model

Document who can create a draft, change a delivery destination, approve a version and authorise release. Include machine identities, batch interfaces and operational staff. The policy should explain whether changing a material field invalidates an earlier approval and how that decision is enforced server-side.

Test the service principal explicitly

Use an approved synthetic order and an agreed service context. A role intended for orchestration may have acquired broader write permissions over time. Compare the expected operation set with actual API decisions, preserving the token audience and role description while redacting credential values.

Prove persistence and attribution

A 200 response alone can be misleading. Read the object back through a separate request and inspect its version and audit principal. Record the result at each stage. A denied release authorisation request matters because it bounds the demonstrated outcome and identifies an effective independent control.

Retest both separation and normal processing

Validate that a maker or orchestration identity cannot approve its own material changes while a correctly authorised flow still completes in the test arrangement. Avoid a fix that blocks all orders. Use the result to improve the policy and regression cases, not just the user interface.

Build a small transaction-state model

List the relevant states of a synthetic order: draft, submitted, approved, amended, rejected and released, using the product's actual terminology. For each transition, identify the permitted role, ownership context and required prior state. Prepare distinct test identities rather than switching roles in one account without recording the change. The expected result should be agreed with the order owner because products differ in how they handle amendments, delegated approval and cancellation.

This model makes subtle questions visible. Can the creator approve through a separate endpoint? Does changing a delivery destination invalidate an earlier approval? Does a service account have broader authority than the user whose action initiated the workflow? Each question needs its own bounded comparison.

Observe the persisted result

A rejected request does not by itself prove that no downstream state changed, and an accepted request may represent a queued operation rather than a released order. Correlate the API response with the synthetic transaction state and relevant audit events. Use an environment and fixture that cannot dispatch real goods. Where production validation is necessary, establish explicit safeguards and stop at the approved evidence point. Do not improvise a live order as a convenient test object.

For platforms that also process payments, the payment webhook replay-testing guide addresses duplicate or delayed messages. The same evidence discipline applies to order processing: check the persisted business effect independently from message delivery.

Retest separation and normal processing together

After a fix, repeat the prohibited transition using the original role and state, then verify that a different authorised approver can complete the legitimate flow. Include the agreed adjacent transitions, such as amendment after approval, only within the scope. Record the application version and any service-policy changes. A fix that simply blocks the affected endpoint for everyone may remove the demonstration while breaking the business process.

For APIs spanning several customer organisations, consult the tenant isolation testing guide to add ownership comparisons without mixing them up with role separation. The report should identify whether the failure concerned actor, organisation, state, or a combination of these controls.

Put the guidance to work

Use the readiness checklist to document assumptions, or inspect the fictional Meridian Group AG report for evidence and treatment-plan examples. Contact Atlant Security with a non-sensitive description of your scope.