Design rider drop-off and recipient collection
Specify DROP-OFF ONLY for riders and collection by recipient booking code or personal authentication.
Before you begin
- Treat this as a solution design. The current drop-off code can reopen the compartment after deposit.
- Record the intended recipient, delivery, compartment, and booking window, with a separate depositor grant.
- Choose recipient collection by booking Pick-up code or by an implemented personal authentication method.
Solution design based on integrate-nekospaze-app at 5d1abe32660e, reviewed 8 September 2026. Rider DROP-OFF ONLY and recipient personal collection are not enforced by the current application.
Step by step
Separate the depositor and recipient
The required policy is DROP-OFF ONLY for the rider. Issue a deposit grant bound to this delivery and compartment. Give collection authority only to the recipient, through a private booking Pick-up code or a personal credential linked to that recipient's delivery.
Authorize one deposit operation
The implementation must validate the rider's deposit grant, booking period, target compartment, and awaiting-deposit state before opening. Define when the physical deposit is confirmed and consume the grant as part of that transition so it cannot be replayed to reopen the door.
Make the occupied stage recipient-only
After deposit, deny every rider attempt to reopen or collect. The current DropOff path only records occupiedAt and keeps its code active; it therefore does not enforce this requirement. Renaming a code or hiding the Pick-up share button cannot change that behavior.
Offer the recipient's collection methods
For code collection, validate the recipient's private booking Pick-up code for this occupied delivery. For personal collection, verify the recipient's face, QR, card/MIFARE/NFC, phone-and-passcode, or email-and-password credential, then authorize that person for this delivery. Personal collection requires integration in the current kiosk.
Complete collection and revoke access
Require the deposited state before collection, open only the authorized compartment, confirm the defined collection outcome, and revoke further delivery access. The current kiosk completes on PickUp without requiring prior deposit or physical collection confirmation; those transitions need implementation.
Verify repeat use and exception paths
Test rider replay after deposit, early pickup, wrong recipients, code collisions, expiry, cancellation, failed opening, disconnect, and staff intervention. Keep maintenance authorization separate from delivery credentials.
You’re ready when
A testable handoff policy where riders deposit only and recipients collect by booking code or personal authentication, with the current implementation gaps explicitly identified.
Troubleshooting
- A rider's Drop-off code opens the door again
- This is a current implementation gap: occupancy does not consume the DropOff access row. The proposed policy requires a consumed deposit grant and a phase check before every physical open.
- Pick-up works before anything has been deposited
- The current kiosk does not check prior occupancy on its PickUp path. The proposed flow must reject collection until deposit is confirmed.
- A personal credential is recognized but collection is denied
- Verify both credential-to-person resolution and the person's recipient entitlement. Reader capture and account login do not currently provide that locker decision.
- The same digits match multiple actions or bookings
- The current code namespace is scoped by project, service, and overlapping actions, while kiosk matching uses code and mapped resource. Implement an unambiguous credential lookup and reject ambiguous matches before opening.
Technical details
- Acceptance: rider deposit
- A valid rider deposit grant opens only its assigned awaiting-deposit compartment. It cannot request pickup, another compartment, or a staff operation.
- Acceptance: no rider reopen
- After the confirmed deposit, the same rider credential is denied before any physical open, including replay after a restart or under the approved offline policy.
- Acceptance: recipient code
- The intended recipient's private Pick-up code opens only the deposited delivery within its allowed lifetime, then cannot be reused after completed collection.
- Acceptance: recipient identity
- An enrolled recipient can collect their deposited delivery using each implemented personal method. A different authenticated user is denied even if they know the compartment number.
- Acceptance: ordering and ambiguity
- Reject pickup before deposit and any credential lookup that resolves ambiguously across actions, bookings, services, or devices. Do not send a command on denial.
- Acceptance: lifecycle and failure
- Test cancelled and expired bookings, consumed credentials, command failure, unknown door acknowledgement, and reconnect reconciliation. A failed handoff must not be reported as a completed physical collection.
- Acceptance: staff intervention
- An authenticated, scoped maintainer can perform only permitted exception actions with a recorded reason. Rider and recipient credentials cannot enter maintenance.
Common questions
- Can the rider physically collect using the current Drop-off code?
- The code can reopen the same occupied compartment while the booking remains active, so the current implementation cannot guarantee that the rider cannot remove its contents.
- Does the recipient need an account if using a booking code?
- The current kiosk accepts the booking PIN without identifying the person. The proposed code option remains access by possession of a private recipient credential; it must also enforce the correct delivery, phase, and lifetime.
- Are two labelled codes sufficient for the required separation?
- No. The system must enforce action, compartment, phase, consumption, and revocation before opening. Numeric values are not globally unique across the current action and service namespaces.
- Can personal collection work without showing a booking code?
- That is an allowed solution option: authenticate the recipient and find only their collectable delivery. It is not connected to the current parcel kiosk and needs implementation.
Still stuck? Tell support what happened and which step you reached.
Email support