Signature

do_action( 'mam_check_in' );                       // app api_call subaction (priority 1 handler)
do_action( 'mam_wc_pv_complete_order_check_in' );  // PV "Complete" action (priority 10 handler)

Both actions run the same handler (mam_wc_delivery_order_management::check_in()); neither passes PHP arguments. The contract is in the request:

mam_check_in is dispatched by mam-main’s app gate when the app sends subaction=mam_check_in (the check-in button on an order). mam_wc_pv_complete_order_check_in is fired by mam-woocommerce-product-vendors when a vendor taps the Complete action on an order screen — this plugin re-routes it onto the same ladder.

What one advance does

1. Authorize — the acting user (from the app token) must pass user_can_manage_order_transport() or user_can_claim_order(); otherwise the handler replies {"status":"failed","message":"Not authorized"} and stops. See Hooks: transport authorization.
2. Locate the current rung in the order’s ladder (delivery or pickup, per location_type meta; missing transport_status is treated as accepted_order).
3. Fire the rung’s side effects: a Product Vendors order-history entry (mam_wc_pv_order_history with the rung title), the rung’s customer notification (via mam_notification_send_message), and the transport option — at driver_assigned this is the driver claim/assignment (atomic lock, fee-line conversion, driver notification) or the external dispatch via mam_wc_delivery_request_driver.
4. Write the next rung: transport_status is set to the next stage and transport_status_<stage> is stamped with the time.
5. If the current rung was the last one, the WooCommerce order is set to Completed instead.
6. Respond with {"status":"success","jsonData":<refreshed phone data>}.

Server-side alternative

Server code (e.g. a delivery service integration) should not fake a request; use the dedicated action instead:

// Advance order 123 from 'driver_assigned' to the next rung:
do_action( 'mam_wc_delivery_set_delivery_status', 123, 'driver_assigned' );

mam_wc_delivery_set_delivery_status walks the same ladder (firing customer notifications, completing on the last rung) but skips the request-based authorization — it trusts its caller. The special status cancelled_by_doordash instead rolls the order back to prep_started and fires the assignment-failed notifications.

Notes

• Both handlers terminate the request (wp_send_json + die()); don’t expect code after the do_action to run in the app-gate path.
• The button title the app shows for the current rung comes from the mam_main_content_element_check_in_args filter, which this plugin fills from the ladder.
• Calling the bare actions without checkinloc resolves order 0 and fails authorization safely.

Related articles

• Recipe: Transport statuses and customer notifications
• Hooks: transport authorization (mam_wc_delivery_user_can_manage_transport)
• Plugin: mam-woocommerce-delivery

Metadata