Subscription process: choosing your payment and signature order

Overview

By default, payment comes first. Funds must be received and processed before a transaction's documents can be signed — the e-signature is blocked until then.

That default can be released. Marking a payment deferred lets signature proceed without waiting for the money. So the order is a deliberate decision per payment, not a free choice of sequence.

One thing is never blocked either way: preparing documents. Generation and review can run throughout.

What you'll learn

• The default: payment gates e-signature

• What marking a payment deferred actually does

• Why preparation is never blocked, and why that distinction matters

• How to read a status that looks stuck but is not

• Three questions that settle the decision

The default: payment gates signature

Funds arrive, your team verifies them, and the transaction becomes signable. Until that happens the signature is held, and the envelope shows Waiting payment proof.

Note what verification means here: payment is made outside the platform. The participant transfers the money and provides proof of payment, and the status stays Waiting payment proof until your team has confirmed that proof and completed whatever internal procedure applies (A8.13). So the gate opens on your confirmation, not on the arrival of the funds themselves.

Deferred payment: releasing the gate

Where signature must not wait for the money, mark the payment deferred. The signature is released, and the documents can be signed with funds still outstanding. The toggle sits on the transaction in Transactions Setup, and can also be set from the import file — A8.12.

That is the mechanism behind every order other than payment-first:

• Signature before payment — defer, sign, then collect. Choose this where the signed subscription is what creates the obligation to pay, which is the more usual legal reading in many transactions.

• In parallel — defer, and let both run at once. Choose this when the timetable is tight and both are expected to land in the same window.

The payments table carries a Deferred flag and a "Deferred payment only" filter, so the deferred set can be found again as a group rather than tracked elsewhere. Use it: a deferred payment is an outstanding obligation on a document that has already been signed, which is precisely the thing not to lose track of.

What is never blocked

Document preparation. Templates, generation and review proceed regardless of payment state. What waits is the signature, not the paperwork — so a process is never idle for want of funds.

Where the choice actually lives

There is no global switch. The gate applies per payment and is released per payment.

The consequence you will see on screen: an envelope reading Waiting payment proof is not stuck. It is held by the default gate, and it moves when either the payment is confirmed or the payment is deferred. Equally, a transaction can sit at Ready for E-Signature or Waiting for E-Signature while payment is already done.

How to decide

Three questions:

1. What does the legal documentation assume? If the subscription agreement is what creates the payment obligation, defer and sign first.

2. How well do you know the participants? The default protects against signed paper going out to someone who will not fund. Deferring gives that protection up deliberately.

3. How compressed is the timetable? Deferring and running both at once is fastest, and carries the most coordination overhead.

Whichever you choose, decide it before you start sending requests. Unpicking a half-sent process is considerably harder than planning one — and a deferred payment nobody chased is worse than a slow process.

Related

• A8.13 — Subscription process: payments · sending and verifying payment requests

• A8.10 — Subscription process: tracking signatures and sending reminders · where "waiting payment proof" appears

• A8.1 — What is a subscription process · the stages this reorders

• A1.6 — Nothing is sent without you · the control principle behind it