Search the documentation

Find a page by title or section.

Go to dashboard
Tasks and proof

PIN verification

A six-digit PIN emailed to the recipient and checked by the server when the driver hands over.

Updated

PIN verification proves that the person who received the goods is the person who was expecting them. Cooriroo generates a six-digit PIN for the task, emails it to the task’s contact, and the driver types it in at handover. The check happens on the server — the PIN is never sent to the driver’s device, so it cannot be read out of the app.

Like every other proof, the PIN belongs to a task, not to a stop or a trip. Two tasks at the same address get two different PINs and two different emails.

Who can do this

Role
Any signed-in user
Permission
stop-tasks:write

An admin configures PIN proof on the task. The driver assigned to the task, or driving its trip, enters the PIN. Nobody in the product is shown the PIN itself except the recipient, in their email.

Setting it up

PIN is one of the proof options on any task, on a stop or standalone.

  1. 1

    Set the required proof to PIN

    The contact fields open as soon as you do, because the next step is not optional.

  2. 2

    Give the task a contact email

    This is the address the PIN goes to, so it must be the recipient’s, not yours. Contact name and phone stay optional; the name is only used to make the email read naturally.

  3. 3

    Save

    The PIN is generated at this point — six digits, randomly, by the server. Nobody chooses it and it is not shown back to you.

When the PIN is sent

Delivery timing depends on what the task is attached to, and it is the part operators most often mispredict:

  1. A task on a trip — the PIN is emailed when the trip starts, in one sweep across every PIN task on that trip. Building the trip a week early does not warn the recipient a week early.
  2. A standalone task — there is no trip start to wait for, so the PIN goes out as soon as the task is created or assigned.
  3. A task edited mid-trip — if a task on an already-started trip newly requires a PIN, or its contact email changes to a different address, the PIN is emailed there and then. Edits that touch neither send nothing.

The email names the task and, for trip-bound tasks, the trip reference, so a recipient expecting several deliveries can tell the PINs apart.

At the door

Completing the task opens a keypad. The driver enters what the recipient reads out, and the app sends it to be checked. Three things follow from where that check happens:

  1. A wrong PIN is a normal answer, not an error — the app says so and offers another try.
  2. There are three attempts in total, then the task is locked out.
  3. A PIN cannot be verified offline. The completion is queued and only goes through once the device reconnects and the server confirms the PIN; until then the driver is told plainly that the task is not complete.

Re-entering a PIN that has already been accepted succeeds again rather than spending an attempt, so a driver who taps twice is never punished for it.

When it goes wrong

Common PIN situations

The recipient says they never got a PIN email
Cause

The trip has not started yet, the address on the task is wrong, or the send failed.

Check the trip’s timeline first: a successful sweep records that PINs were emailed, and a failed send records a warning against the task. If the trip has not started, nothing has been sent yet and nothing is wrong. If the address is wrong, correcting the contact email on the task re-sends the PIN when the trip is already underway.

The driver is locked out and the customer is standing there
Cause

Three wrong attempts. The lockout is permanent for that task.

An admin can waive the PIN requirement on that one task, which lets it complete on whatever else it requires; the waiver needs a reason and is recorded on the trip’s timeline. If the handover should not go ahead at all, fail the task instead and let the reason explain why.

The PIN task was created but the driver never saw a PIN step
Cause

The task was skipped at creation because it had no contact email.

This is the bulk-apply case: a template or destination default that asks for a PIN without an email is dropped rather than created. Add the email to the blueprint, then add the missing task to the stop by hand.

A recipient wants their PIN re-sent
Cause

Nothing re-sends on demand; sends are triggered by trip start, creation or an edit.

Changing the contact email to a different valid address on a task whose trip is already underway sends the PIN to the new address. If the address is already right, forward them the original email rather than editing the task.

Can we choose our own PINs?
Cause

PINs are generated by the server, six digits, and are not editable in the product.

Customer-chosen PINs are not supported. If you need a shared secret you control, a recipient-name or signature proof is usually the better fit.

Terminology

Your organisation can rename these. If your screens say something else, this is what they mean here.

Task
One unit of work. The PIN, the contact email and the verification all belong to it individually.Rename it in Customization → Terminology
Trip
One journey with an ordered list of stops. Starting it is what sends the PINs for its tasks.Rename it in Customization → Terminology