ZAMBO.

Direct answer

They want the keys before the final payment. Stage the handover of access.

The project is nearly done, the balance is still open, and the client asks for the passwords and admin access now: the admin login, the hosting panel, the account you built everything under. Handing it all over today removes the last practical reason to settle the balance, and does it in the worst possible way, with a shared password nobody can later untangle. Refusing flatly sounds like a hostage note and can spook a client whose real worry is being locked out of their own system. Both instincts are wrong because both treat access as one lump. Access is a ladder: being able to look, being able to work, and being the owner are three different rungs, and they can move at three different times, tied to the two events that structure the whole job, acceptance and payment. Here is the ladder and how to run it.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated October 31, 2026. First published October 31, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service.

Step 1. Find out what the client actually needs today

Ask, in a friendly tone, what the access is for right now. The honest answers cluster: they want to review the finished work inside the system, their own IT person or next provider wants to prepare, or they are afraid, sometimes from a past bad experience, of being stranded without control of something their business runs on. Almost none of those needs requires owner-level access today. Review needs a viewer seat. Preparation needs a read over the setup, or a named account with limited rights. The stranded fear needs a written transfer plan with a date and a trigger, which answers it better than a password sent in a chat ever will. Name the need back to them and meet that need on its own rung, so the conversation is about which access, for whom, for what, instead of a yes or no over everything at once.

Step 2. Split access into three rungs and put dates and triggers on each

Rung one, look: viewer or reviewer access to the delivered work, reports, and settings in read form. This moves immediately; the client should never have to pay to see what they are being asked to accept. Rung two, work: operating accounts the client's named people use day to day, moved when the delivery is accepted, so they can run what they bought while the final accounting settles. Rung three, own: owner and admin control, password resets, billing seats, and the removal of your own access, moved at final payment, in one sitting, to a named person. Write the ladder down in the thread with the trigger for each rung, not as a threat but as the transfer plan it is. A client who can see exactly when each rung moves, and what settles it, stops hearing a refusal in the space where the plan now sits.

Step 3. Read the two states the delivery can sit in while access is argued

The ladder's triggers are acceptance and payment, and acceptance is a state a record shows, not a mood in a thread. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the states a delivery can carry:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

An accepted record, 4 of 4 steps checked, decided_by client, release_hint ok_to_release, decided 2026-10-16T14:31:51.146Z in that example, is the delivery the client side has closed on: rung two moves, and rung three is waiting on exactly one thing, the final payment, which the record names as the release condition. A pending record, 5 of 5 steps checked and release_hint hold, is checked work still awaiting its decision, and there the order protects both sides: get the acceptance recorded first, because access transferred ahead of acceptance scrambles who is responsible for the state of the system from that day forward.

Step 4. When a rung is due, transfer like an adult: named accounts, never your password

However the timing lands, the mechanics are not negotiable. Never send your own password, by chat, email, or any other channel; a shared password means neither side can later show who did what inside the system. Instead, invite the client's named person to their own account, raise that account to the rung being transferred, watch them log in and set their own password and recovery options, then adjust or remove your own access in the same sitting, as the plan states. For systems with a single owner seat, transfer the ownership to their account rather than handing over yours. Then record the event in writing the same day: the system, the rung, the named person who received it, and the date. Record the event, never the secret: no password, code, or key ever goes into a message, a document, or a receipt.

Step 5. If the pressure keeps coming, offer the doors instead of a wall

Some clients push because the balance itself is the problem, and access is the lever they have found. Answer with doors, all of them open today. Door one: settle the balance now, in the ordinary way, and rung three transfers in the same sitting, today, with you on the call while it happens. Door two: a part payment that reflects the work already accepted, against rung two moving now and rung three on the balance, with the dates in writing. Door three: if trust is the sticking point rather than money, a neutral written arrangement both sides sign that fixes the transfer date and trigger in advance, so the client holds a commitment with a date on it instead of a promise. What never helps is sending one password as a goodwill gesture; goodwill you cannot take back, attached to the account everything runs on, is not goodwill, it is the whole position given away for a thank-you.

Step 6. Write the access ladder into the next agreement from day one

One short block in the next quote ends this negotiation before the work starts: client receives reviewer access on delivery, operating accounts for named staff on acceptance, and owner and admin transfer on final payment, to a named person, by account invitation, never by shared password; the provider's access is removed at transfer and the transfer is confirmed in writing the same day. Add the neighbouring line while you are there: the client's own data and exports are available to them throughout, because the ladder governs control of the system, not access to their information. Clients who intend to pay sign this happily, because a dated ladder protects them from the far more common failure, a provider who vanishes with the only login. A client who demands every key before any payment, and rejects the ladder in writing, has shown you the risk while it is still free to walk away from.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove who holds a password, cannot move access between accounts, and must never contain a password or any other secret. Zambo does not hold client funds or client credentials. The written access ladder, the acceptance state, and the same-day transfer confirmation are what the conversation stands on. This page is general information, not legal or security advice; a system carrying sensitive data deserves a proper security review.

Frequently asked questions

My client wants the passwords and admin access before they have paid in full. Should I hand it over?

Not as one lump, and never your own password. Split access into rungs: reviewer access to the delivered work moves now, because a client should never have to pay to see what they are accepting; operating accounts for their named staff move at acceptance; owner and admin control moves at final payment, in one sitting, to a named person, by account invitation, with your own access adjusted in the same session. Put the ladder in writing with the trigger for each rung, and record each transfer the day it happens, system, rung, person, date, never the secret itself. If they need it sooner, the door is simple: settle the balance and the top rung transfers the same day. A written ladder answers the fear of being locked out without giving away the last reason to pay.

Is keeping admin access until final payment just holding the client's system hostage?

No, provided two things are true: the client can see and review everything they are being asked to pay for, and their own data and exports are available to them throughout. Control of the system and access to the work are different things. Builders, platforms, and providers of every kind transfer owner control at settlement as an ordinary delivery term, the same way final files and rights move at payment; what would be wrong is blocking review, blocking their data, or moving the date after the fact. The ladder was stated in advance, each rung has a named trigger, and the top rung moves the moment the balance settles. That is a schedule, not a hostage note, and writing it down in the agreement is what keeps it one.

Can I safely give the client some access before payment, as a middle way?

Yes, and you should: it is rung one and half of rung two. Give a named person at the client a viewer or reviewer seat over the delivered work, any reports they need, and, where the tool allows it, a limited account that can prepare without being able to change ownership, billing, or who else has access. Named and limited are the two words that make early access safe: named, so every action inside the system belongs to a person, and limited, so the account cannot transfer the system to itself or lock anyone out, including you. Avoid shared logins at any rung; the day a shared password is used, neither side can show who made a change, and that fog outlasts the payment question by years.

The client says their IT department requires admin access now for a security review. What do I do?

Treat it as the preparation need it usually is, and meet it precisely. Ask what the review needs to inspect: configuration, user list, data handling, integrations. Most reviews are satisfied by a read-only admin view, a screen-share walkthrough with you driving, or an export of the settings, each of which can happen today without transferring ownership. Get the reviewer's name and scope in writing, grant the narrowest seat that covers it, and set the seat to expire or be reviewed on a stated date. If a reviewer genuinely needs full admin, that is a transfer event: it follows the ladder, happens to a named account, and is recorded the same day. A real security team respects that discipline; it is, after all, what their review is checking for.

How do I set up the next project so access is never negotiated mid-job?

Write the ladder into the agreement and let the delivery record carry it: reviewer access on delivery, operating accounts on acceptance, owner transfer on final payment, each transfer recorded as a step with its date and named recipient, the event only, never a secret. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, so the acceptance that triggers each rung sits on the same record as the work itself, and neither side argues from memory about whether a rung is due. New users get 20 calls and 1 wrap-up free every day, and picking up work in another AI is always free. For $0.99, run the next delivery that way and let the record call the rungs: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related