Updated October 26, 2026. A drone that can carry a package is not, by itself, an order-fulfillment system. Merchants still have to decide which orders qualify, coordinate preparation and packaging, request a compliant flight from an authorized operator, handle exceptions, communicate with customers and reconcile successful deliveries. The commercial software challenge is connecting those steps without handing safety-critical flight decisions to a retail checkout application.
This independent drone delivery dispatch software checklist is for retailer technology teams, last-mile logistics providers, enterprise architects, drone operators and systems integrators procuring an orchestration layer. It offers a copyable requirements framework, a sample event contract, 12 acceptance tests and a weighted vendor scorecard. The example event schema and scoring weights are illustrative procurement tools, not industry standards or production-ready integration code.
The market direction makes this timely. In its September 30, 2026 DoorDash Air announcement, DoorDash described an Autonomous Delivery Platform that evaluates order weight, distance, weather and ground conditions when choosing among delivery modes. That is a company description of its own approach, not a published open API specification. Separately, Wing and Walmart announced on October 5 plans to expand to Denver and Seattle in 2027, toward a network exceeding 270 Walmart locations. A multi-site retailer should plan for software that manages sites and exceptions, not just a single demonstration flight.
1. Separate merchant orchestration from aviation operations
A dependable solution has at least four distinct responsibilities. The merchant’s point-of-sale (POS), ecommerce and order-management systems (OMS) own order intent, payment and inventory. A delivery orchestration layer determines whether to offer an authorized delivery option and tracks fulfillment. A qualified UAS operator owns flight safety, aircraft readiness and its applicable aviation approvals. Site staff and infrastructure complete loading, handoff and recovery. One vendor may supply more than one layer, but a contract should identify the accountable party for each.
| Layer | Main responsibility | Evidence to request |
|---|---|---|
| POS / ecommerce / OMS | Valid cart, inventory, payment, promised customer experience | Order states, API ownership and rollback design |
| Dispatch / orchestration | Eligibility evaluation, reservation, delivery-mode selection, status mapping and fallback | Workflow map, event definitions, exception logs and service levels |
| Authorized drone operator | Aircraft, crew or oversight model, airspace, weather and flight go/no-go | Applicable FAA certificates, exemptions, waivers and operating limitations |
| Ground-site and merchant operations | Packaging, identity check, loading, safe launch-site interface, delivery evidence | Handoff checklist, staffing plan and site approvals |
| Finance / customer service | Charges, refunds, incident escalation and dispute trail | Reconciliation exports, audit retention and dispute workflow |
Procurement red flag: a vendor calls its aircraft-control dashboard a complete delivery management platform but cannot demonstrate order capture, no-fly exceptions, merchant fallback, proof of delivery or accounting reconciliation. Use the complete UAV system RFQ template to evaluate hardware and support alongside the software layer.
2. Build an explicit order-eligibility decision, not a vague “AI score”
Eligibility should be observable and repeatable. Require vendors to show the inputs, which party supplies each input, when it refreshes and how a disqualifying result is displayed. A practical first-pass decision checks: eligible merchant and operating hours; customer address and approved drop-off area; available inventory; packed payload mass, dimensions and handling restrictions; airspace and the operator’s applicable approvals; weather and local conditions; site staffing and launch capacity; aircraft or network capacity; routing distance; delivery time promise; and customer consent where needed.
Classify each outcome as eligible, ineligible with a reason, pending operator acceptance, or temporarily unavailable. A merchant-visible “eligible” flag must not override an operator’s go/no-go decision. If the destination or package is not eligible, the system should preserve the order’s economics and send it to an explicitly agreed ground-delivery path or ask the customer to select another option.
A vendor should document whether screening occurs at product detail, cart, checkout, post-payment or final dispatch. Doing it only after a customer has paid can create avoidable refunds and service complaints. Re-evaluate material conditions before dispatch; for example, a weather or airspace change can invalidate an earlier estimate.
3. Specify the order-to-flight event contract
The critical integration deliverable is a shared event lifecycle, not a glossy map of aircraft icons. Define what each state means, the system of record, expected latency, the party permitted to transition it and the action when an event arrives twice or out of order. One illustrative lifecycle is:
ELIGIBILITY_REQUESTED— merchant asks for a delivery-option assessment.OPTION_OFFERED— eligible service and quoted window are displayed, subject to final acceptance.ORDER_RESERVED— customer commits and fulfillment capacity is tentatively held.PACKOUT_VERIFIED— staff confirms the actual sealed package and handling checks.OPERATOR_ACCEPTED— the authorized operator accepts the mission under its own procedures.HANDOFF_COMPLETE— documented custody transfers at the launch interface.IN_TRANSIT— fulfillment is underway; tracking exposure remains governed by privacy and security policy.DELIVERED— operator supplies defined completion evidence.EXCEPTION_RECORDED— a failure, hold, cancellation or safety no-go is logged.FALLBACK_ASSIGNED/REFUNDED— the merchant executes the agreed exception outcome.
Illustrative webhook event, not a standardized vendor format:
{
"event_id": "evt-demo-018",
"order_ref": "merchant-demo-order-042",
"occurred_at_utc": "2026-10-26T18:00:00Z",
"state": "FALLBACK_ASSIGNED",
"reason_code": "WEATHER_NO_GO",
"fulfillment_mode": "ground",
"operator_ref": "operator-demo",
"schema_version": "example-v1"
}
Demand an agreed dictionary of states and reason codes, documented customer-notification rules, an immutable event identifier and timestamps suitable for cross-system reconciliation. Use pseudonymous external references where possible; do not copy customer addresses, contact details or precise flight telemetry into every event by default.
4. Ask how the APIs behave when real operations go wrong
An API integration demonstration that only processes a successful order says little about enterprise readiness. Give each vendor these engineering controls to address in writing:
- Authentication and authorization: least-privilege service identities, credential rotation, scoped access and separation between merchant status APIs and safety-critical operator systems.
- Webhook integrity: authenticated callbacks, payload verification, replay protection and a documented secret-rotation procedure.
- Idempotency: duplicate reservations or callbacks must not cause duplicate dispatches, charges, refunds or customer messages.
- Ordering and recovery: events can arrive late or out of sequence; define replay windows, event sequence handling, retry backoff and dead-letter investigation.
- Versioning: schema evolution, deprecation notice, test environment, published compatibility policy and rollback route.
- Audit and privacy: minimum necessary order data, access logs, retention schedules, deletion handling, incident notification and cross-border data controls.
- Observability: traceable request identifiers, error categories, per-site dashboards and exports usable without proprietary screenshots.
Use NIST SP 800-228, updated March 13, 2026, as a reference for cloud-native API risk and controls. It provides general API security guidance; it does not certify a particular drone vendor or replace aviation operational safety requirements.
5. Preserve the flight operator’s authority and regulatory boundary
In the United States, compensated BVLOS carriage of someone else’s property remains a specialized aviation activity. The FAA’s drone package delivery guidance describes the Part 135 certification process and associated exemptions, waivers, airspace authorizations and other reviews. A software vendor’s ability to schedule a mission is not evidence that the proposed operator is authorized to fly that route, aircraft, payload and operating model. Verify certifications and their applicable scope, and keep a human and/or operator-controlled safety no-go override in the architecture.
Systems commonly distinguish merchant orchestration, flight operations and low-altitude airspace or UAS Traffic Management (UTM) services. Procurement documents should say which vendor supplies each function, what data is exchanged and what happens when an airspace service or site connection becomes unavailable. Do not treat proposed BVLOS rulemaking, software marketing claims or a successful flight elsewhere as automatic local authorization.
6. Write a delivery-mode fallback policy before connecting the first store
A drone may be unavailable because of weather, package limits, address geometry, regulatory limitations, operator capacity, maintenance, an inaccessible drop area or a delayed merchant handoff. Without a fallback rule, the customer becomes the integration test.
Specify which conditions trigger ground courier, customer re-consent, pickup, rescheduling, cancellation or refund. For each, define who pays, who contacts the consumer, whether the promised delivery window is recalculated and how custody is transferred. Make the policy testable, with a target time from operator rejection to alternate fulfillment. Avoid publishing service guarantees until measured at the proposed sites.
For cost comparisons, use completed orders, not attempted flights, as the denominator. Our drone delivery cost-per-order worksheet separates site overhead, fulfillment volume, failed attempts, fallbacks and merchant contribution.
7. Request evidence for service levels and total cost
Compare pricing on the same scale: one pilot site and an agreed multi-site expansion case. Itemize software platform fees, per-order or per-event charges, aircraft/operator charges if bundled, integration development, launch-site hardware, telemetry or mapping costs, data retention and export charges, support coverage, incident response, change requests and termination assistance.
Ask for measured service levels for: API availability; eligibility-response latency; time from customer checkout to operator acceptance; timely event delivery; successful merchant reconciliation; fallback initiation; and order completion. Separate a business-system outage from a safety-related no-flight. A vendor should not be penalized for a justified safety decision in a way that encourages unsafe operations. Require service-level definitions, exclusions, reporting interval, support escalation and remediation terms rather than accepting unqualified “99.9%” marketing language.
8. Run these 12 pilot acceptance tests
Use synthetic orders and a safe test environment before live commercial flights. Ask the responsible operator to control any flight-specific test under its own procedures and approvals.
| # | Test | Pass evidence |
|---|---|---|
| 1 | Eligible small parcel, valid address | Correct offer and operator reservation; complete audit trail |
| 2 | Overweight or oversized packaged item | Rejected before checkout commitment with explanatory reason |
| 3 | Restricted or unapproved item | Blocked under the applicable operator and shipping policy |
| 4 | Weather turns unfavorable after initial eligibility | Operator-controlled no-go recorded; merchant workflow updated |
| 5 | Delivery zone or site becomes unavailable | No false promise; alternate option shown |
| 6 | Duplicate eligibility, booking or callback event | No duplicate charge, dispatch or notification |
| 7 | Status events arrive out of sequence | Correct order state reconstructed or flagged for review |
| 8 | Store or launch-site connection is lost | Bounded retry, safe stop and recoverable work queue |
| 9 | Operator declines a previously offered mission | Fallback or cancellation invoked under agreed time policy |
| 10 | Package handoff fails quality check | Flight request held; custody and corrective step recorded |
| 11 | Delivery confirmation evidence is missing | Order not silently marked delivered; dispute route preserved |
| 12 | Customer requests cancellation during handoff | Permitted transition, fees and notifications documented |
Keep the evidence—request/response logs with sensitive data masked, screenshots, event identifiers, operator signoffs and defect closures—in a pilot acceptance report. A successful tabletop test is not proof of authorization or real-world reliability.
9. Copyable 100-point vendor scorecard
These weights are illustrative. Make safety/compliance and data protection pass/fail gates before scoring a low-cost supplier.
| Dimension | Points | Proof required |
|---|---|---|
| Eligibility and order workflow | 20 | Live demonstration with clear rejection reasons |
| Operator integration and safety boundaries | 20 | Architecture, permissions, applicable operator authority |
| Exceptions, fallback and customer communications | 15 | Replayed rejection and no-service scenarios |
| API security, privacy and audit | 15 | Security design, tests, incident and retention policies |
| Event quality and reconciliation | 10 | Idempotency and out-of-order replay evidence |
| Merchant onboarding and multi-site operations | 10 | Site activation plan, staff procedures, support model |
| Commercial terms and data portability | 10 | Complete pricing, exit clauses and data-export sample |
| Total | 100 | Comparable evidence from every shortlisted vendor |
Do not average away a fatal deficiency. If a solution cannot show who has authority to dispatch a flight, how a restricted package is blocked or how customer data is protected, resolve that failure before assigning a weighted score.
10. Paste this mini-RFP into a supplier questionnaire
Mission and deployment. Identify delivery category, merchant count, planned sites, eligible parcel types, intended service territory and expected daily completed orders. Distinguish live operating markets from a proposed pilot.
Integration. List supported POS/OMS/ecommerce systems, real-time eligibility calls, event/webhook catalog, sandbox access, test data, versioning policy and ownership of order state. Attach a representative event schema and a sample reconciliation export.
Operator and site. Name the proposed air carrier, applicable Part 135 authority and other required permissions, aircraft/payload limits, ground-interface design, safety decision rights, site approvals and local operating constraints. Do not substitute a generic FAA certificate for route-specific diligence.
Security and continuity. Provide access-control architecture, signing and encryption approach, data residency, retention, breach escalation, fail-safe behavior, recovery objectives and relevant independent assessments. Identify critical subcontractors.
Commercial. Quote an identical one-site pilot and ten-site expansion assumption, including software, operations, support, integration, minimum commitments, data access and exit costs. Present a service-level schedule tied to measurable outcomes and a joint incident-resolution process.
Acceptance. Respond to the 12 test cases above with the exact demonstration, document or test evidence that will prove each item. Include named responsibilities and remediation deadlines for failed criteria.
Buyer FAQ
Is drone fleet management software the same as delivery dispatch software?
Not necessarily. Fleet software may focus on aircraft telemetry, maintenance or missions. Delivery orchestration must also connect merchant orders, address and item eligibility, operator acceptance, handoff, proof of delivery, customer updates, exceptions and financial reconciliation. Some integrated suppliers cover both, but the boundary and evidence need to be explicit.
Does a merchant need its own air carrier certificate to call an operator API?
A merchant buying an authorized delivery service and the entity actually conducting flight operations play different roles. The operator’s permissions and the intended commercial arrangement must be evaluated; an API connection by itself creates no aviation operating authority. Seek qualified aviation counsel when structuring the arrangement.
Can software automatically reroute any rejected drone delivery to a ground robot?
Only where a compliant, available ground mode exists and the merchant has agreed to its operational and customer-service rules. Sidewalk and road robots face different local restrictions, capacity constraints and customer handoff requirements. “Autonomous” is not interchangeable with “universally available.”
Which part should a buyer evaluate first?
Begin with the real merchant order flow and operator authority, then test eligibility, exception handling and reconciliation. Procurement teams choosing a whole aircraft-and-ground system can pair this software annex with the UAV system RFQ; retailers should also use the merchant integration checklist, while package engineers can apply the forthcoming payload qualification worksheet after publication.
Primary sources and editorial independence
The factual market and regulatory context draws on DoorDash Air’s September 30, 2026 announcement, Wing and Walmart’s October 5 expansion statement, FAA package delivery and Part 135 guidance, and NIST SP 800-228’s March 2026 revision. All were reviewed October 26, 2026. The event model, test plan and scoring system are original editorial examples, not representations of any company’s proprietary interfaces. UAVPackage.com is independent; citations are not paid endorsements. Organizations interested in strategic acquisition or use of the developed site may visit the private inquiry page.
