What we tested in ReturnPath /
The tests behind ReturnPath: inputs, actions, observed results and the limits of that evidence.
Evaluate return eligibility against versioned policies, reserve quantities and track received goods without duplicate processing.
Internal local testing, using synthetic inputs and owned assets. The results below establish the observed software behavior in those scenarios. They do not establish customer ROI, uptime or external deployment readiness.
Nine acceptance groups passed
The local ReturnPath HTTP run passed nine groups spanning authentication, order validation, versioned policies, concurrent authorisation, receipt replay, cancellation, policy expiry, approval expiry and workspace isolation. The combined Dispatch and ReturnPath report contains 120 requests. It does not provide an independent request count for ReturnPath.
Competing requests respected the remaining units
A fixture had three units still available and two cases each requesting two units. Concurrent authorisation allowed one case and rejected the other as ineligible. A subsequent receipt moved the order's already-returned quantity from one to three exactly once. Repeating the successful receipt did not add another two units, and cancellation of the received case was blocked.
Expiry was observed over elapsed time
The harness tested an already-expired policy and also waited for a short-lived approval to expire before attempting authorisation. The later action was rejected. This checks that a stale review state cannot authorise a return after the deadline, rather than merely checking that an expiry field exists in the record.
Exports and boundaries stayed honest
Cancellation released reserved units for another request. A carrier-label action returned the configured blocked state, while the PDF identified internal return authorisation instead of a prepaid label. Separate workspaces could not use each other's order and policy references. No real shipping, refund, warehouse receipt or customer communication occurred in these tests.
What this evidence does not establish
Orders and policies in the evaluated flow are entered locally. There is no verified live commerce sync, so an operator must establish how fulfilment and historical returns are kept accurate before using real data.
The RMA is a local authorisation reference. Carrier-label generation is blocked without a provider; a PDF export does not buy postage, arrange collection or communicate with the customer.
Receipt records that an authorised quantity arrived. The tested flow does not automate condition grading, restocking, disposal, replacement shipment, payment reversal or a refund decision.
The tests cover policy and quantity rules with synthetic cases. They do not establish fraud-detection performance, consumer-law compliance, production load or a complete team administration and recovery process.
A similar problem in your business?
Bring a real workflow, representative inputs and the result that needs to be reliable.
Shape a project brief