Dealokr logoDealokr
Payment and final handoffUpfront payment

Upfront payment and protected delivery for your freelance projects.

The client funds the fixed-price project before production. You can present the work for review, handle agreed adjustments and organise access to hosted final files after the transfer is confirmed.

Understand the workflow

When payment is still expected after handoff, you have already committed time and supplied the result. Dealokr offers a different order for fixed-price work: a clear agreement, full client payment upfront, then review and final handoff in the same project.

The value is in distinguishing when the project is funded from when final files become accessible. Your client can examine a preview and specify feedback before that handoff. To place these stages in the wider project, explore how Dealokr works.

You remain responsible for preparing the deliverables and requesting transfer under the project conditions. The client follows an understandable sequence, with a review framework explained before they pay.

Two professionals review a laptop in a shared workspace.
What you connect in the same project.
  • Agreement on the result, amount and review conditions.
  • Initial payment of 100% of the fixed-price project, confirmed before work.
  • A preview to examine and revisions connected to the project.
  • A transfer request under the conditions, then access to hosted final files at confirmation.
01 · Prepare a funded start

Change the payment order before production begins.

Collecting payment before production changes what you rely on at the start. For a fixed-price Dealokr project, the client pays 100% of the agreed project amount before work. You can therefore prepare production after that payment is confirmed, with the scope and final handoff already explained to the client before either party moves forward.

A professional presents budget elements on a whiteboard.

Agree on the workflow before the commitment

Present this order during scoping: what will be created, the fixed price, the deliverables and how the client will review the work. Upfront payment should be understood alongside those conditions rather than introduced partway through a project already started under a different arrangement.

The project and signed agreement give both parties a reference. For visual work, for example, you can identify the versions to examine, formats to deliver and revisions included. The client funds a described result; you know the basis for organising production and preparing the first review.

Reduce the wait for payment after delivery

The practical benefit is avoiding a start based only on a payment promise, followed by discovering a problem after sending the files. It does not remove every possible dispute, but it changes when initial funding is checked.

This organisation should be proposed for work whose fixed price can be defined. If the requirement is still uncertain, clarify the deliverables and decisions needed before asking for payment. Full funding does not make an unclear scope easier to carry out. A client should be able to describe what they will receive and what will be reviewed without relying on assumptions left outside the agreement.

02 · Read the relevant state

Check client payment without confusing it with a bank payout.

The project is funded when client payment is confirmed in the workflow, not when a promise or screenshot is sent to you. Stripe Connect processes payment in the Dealokr platform’s Stripe balance. Transfer to your connected account and payout to your bank account happen afterwards, as two separate events to identify and follow.

Two people use a bank card and a laptop for an online payment.

Three events answering three questions

EventQuestion to checkWhat it does not mean
Client paymentHas the project amount been paid upfront?The freelancer has already received that amount in the bank.
TransferHas the requested transfer to the connected account been confirmed?The bank payout has already arrived.
Bank payoutHave funds arrived in the bank account?Every other project stage has the same date.

Before producing the work, consult the project state and match it to the correct client and agreement. A payment link sent, or a payment still pending, should not be described as confirmed funding. Where a state requires action, address it before announcing the start of production.

Prepare your side of the payment workflow too

Check the information and requirements applicable to your connected Stripe account. Account availability and provider checks may affect subsequent operations. The expected bank arrival cannot be inferred solely from the day on which the client pays.

Read the fees and conditions displayed before payment. Do not confuse the project amount with a net amount available in your bank. To follow the arrival of funds, consult the relevant Stripe account state and payout schedule instead of assuming one confirmation covers all three events.

03 · Show the work for review

Let the client examine a preview before final-file access.

Full upfront payment does not remove the client’s review stage. You present a preview that allows them to examine the result and request the agreed revisions. Hosted final files remain separate, so reviewing the work and handing over the agreed package follow identifiable stages within the project rather than becoming one uncontrolled file send.

A photographer reviews work on a laptop beside prints and photographic equipment.

Provide enough material for a decision

Choose a preview suited to the deliverable: a readable version, a presentation of the result or material that allows the agreed criteria to be checked. Identify the reference and points under review. The client needs to understand what they are approving, rather than merely seeing that a file was added.

Protecting final handoff should not make review unusable. Separate what the client needs to respond from the final package: production exports, editable files or documentation under the agreement. Prepare both sets of material before the end of the project.

Connect revisions to a version and the scope

The client can approve the preview or request a revision in the portal. A precise request names the location, issue and expected result. You can then address the agreed adjustments or discuss a new requirement that changes the deliverables.

The preview, responses and revision requests stay connected to the project. This helps locate the decision without reconstructing the exchanges. Recorded approval is a decision about the work; it does not mean the transfer of funds has automatically taken place. Keep the next action visible when explaining what happens after a response.

04 · Separate request from confirmation

Request the transfer when project conditions allow it.

The freelancer requests the transfer from Dealokr following approval or the applicable review conditions. That action remains separate from the client’s initial payment. Project state, any open dispute and payment-account availability matter: sending a request or reaching a date is not enough to announce that a transfer has been confirmed and the next stage completed.

A professional checks notes beside a laptop in a bright office.

Follow the conditions and the actual state

Check the next available action in your workspace together with the review and payment information. An open dispute blocks release in the normal workflow. If the client requests a revision, address the point under the agreement and prepare the next version rather than treating that response as approval.

If the client stops replying, check the review conditions provided for the project. Their application may allow a release request under the workflow conditions; the end of a period does not automatically trigger money movement.

Milestones funded upfront, without successive new client charges

Where the project is organised into milestones, the initial client payment funds the fixed-price amount. The stage amounts then serve the corresponding transfer requests. This is not a route for asking the client for successive deposits or charging a new portion at every approval.

Milestone transfers remain subject to applicable conditions. The first does not make every project file accessible. Explain progress through the deliverables expected at each stage, without promising an automatic transfer on a date or as soon as a positive comment appears. A milestone should describe an agreed part of the work, not create a payment promise the workflow does not make.

05 · Prepare final access

Open hosted final files after the transfer is confirmed.

Transfer confirmation enables access to final files hosted in Dealokr under the project workflow. You therefore prepare the correct deliverables and check their version before that stage. For the client, handoff should match the package described; for you, final access and bank payout remain two different pieces of information to check separately.

A professional hands a document to a colleague across a table.

Prepare handoff as carefully as payment

Review the agreed formats, filenames, version and supporting material. If the agreement includes source or editable files, identify them; if it provides exports only, make that scope understandable from the beginning. The access workflow does not decide on your behalf what you owe the client.

The client should be able to identify the available items and their use. A clearly named archive, inventory or opening note may help depending on the service. Prepare these to match the client’s needs and check that the files open before completing the package.

Check external-file permissions separately

The protection described concerns files hosted in Dealokr. For a Drive link, Figma file, code repository or another service, permissions remain managed by that provider. An already public link does not become private because it is added to the project.

A person viewing a preview may also capture what they can see. Present suitable review material and check external permissions separately. The benefit is an organised handoff according to project state, not an absolute inability to copy visible content or proof that the funds have already arrived in your bank account.

06 · Choose a shared arrangement

Explain the benefit and limits before inviting your client.

This workflow is useful when you and the client can agree on a fixed price, a result and a review before work begins. Present it as a shared arrangement: funding upfront, a preview to examine and conditional handoff. The client should understand what they pay for and what they can check, without a promise of absolute protection.

Two colleagues discuss work around a laptop in an office.

Anticipate the commercial questions

A client may ask how they will examine the work, who gathers feedback or how their accounting team handles initial payment. Answer through the scope, workflow and accepted conditions. A different internal procedure requires discussion before commitment rather than a condition changed after production.

Daily-rate projects follow another workflow; do not automatically apply the full initial payment rule described for fixed-price work. For a project whose result remains to be defined, start by clarifying what can be agreed and presented to the client.

A protected workflow, with real responsibilities remaining

A completed payment may still face a bank dispute, refund or provider restrictions. Dealokr organises the project and its stages; it is not a regulated escrow service and does not guarantee the outcome of a disagreement or chargeback.

The agreement, previews, revisions and timestamped history help explain what happened. They do not replace your documents, accounting or assessment of a particular case, and do not guarantee decisive court evidence. To prepare the next project, start with conditions your client can read and understand before paying.

Initial payment changes when you verify funding for the fixed-price project. The preview and revisions retain a place for the client’s decision, then the transfer request and its confirmation organise access to hosted final files. Each stage remains identifiable for both parties.

Back to the reference points
Sources and verification
  • Dealokr — Initial payment for fixed-price projects
  • Dealokr — Agreement, preview and revision requests
  • Dealokr — Payment states and transfer conditions
  • Dealokr — Milestone transfers after full initial funding
  • Dealokr — Hosted-file access and external permissions
  • Dealokr — Operational project history and responsibilities

This page describes the fixed-price project workflow. Client payment, transfer to the connected Stripe account and bank payout remain separate. Initial funding and protection of hosted files do not remove dispute risks or the payment provider’s conditions.