How to Take Payment When a Contract Is Signed

Updated 30 September 2026

The moment a customer signs is the moment they are most willing to pay. Most sales teams waste it. The contract comes back signed, someone in finance raises an invoice a few days later, the customer’s accounts team queues it for the next payment run, and the deposit that was agreed on the call arrives a month after the deal closed. Taking payment when the contract is signed closes that gap: the buyer signs, pays by card in the same sitting, and the deal is closed and funded at once.

This guide explains when payment at signature makes sense, the ways to set it up, how it works with Salesforce, and what to check so the amount charged always matches the amount agreed.

When to take payment at signature

Payment at signature works best when the amount is known when the document goes out and the buyer can pay it by card:

• Deposits and set-up fees on services, installations, events and projects, where work should not start until money has arrived.
• Order forms and one-off purchases for training places, memberships, subscriptions paid upfront or equipment.
• Applications with a fee, where an online form, a signed agreement and a payment are one process.
• Small and mid-market deals where the buyer holds a company card and would rather pay now than raise a purchase order.

It fits less well when the customer’s procurement rules demand an invoice and bank transfer, when the amount depends on work not yet done, or when payment terms such as 30 days are part of the deal. In those cases, send the invoice from your finance system and keep the signature flow for the agreement.

Three ways to take payment when a contract is signed

1. Sign first, then send a payment link

The simplest route: the contract is signed in your e-signature tool, and someone creates a payment link in Stripe, PayPal or your accounting system and emails it. It needs no new software, and it works. Its weaknesses are the manual step, the delay between signing and paying, a link that can carry a mistyped amount, and a payment status that lives outside Salesforce unless somebody updates the Opportunity by hand.

2. An e-signature tool with a payment field

Several e-signature products can collect a payment as part of signing. DocuSign Payments, for example, adds a payment field to the envelope and charges through a connected gateway such as Stripe or Braintree; DocuSign makes it available on its Business Pro and Enhanced plans. PandaDoc offers payments on its paid plans, with processing fees. These remove the manual step. Check how the amount is set, who can change it after sending, and whether the payment status reaches Salesforce or stays in the signing tool.

3. A sign-and-pay flow inside Salesforce

In an app inside Salesforce, the payment is configured on the same document the rep sends from the Opportunity, the amount can come from a Salesforce field, and the result of the payment is written back to Salesforce as a record you can report and automate on. This is how SalesSign Sign & Pay works, and it is the worked example below.

How sign-then-pay works inside Salesforce

1. Set the amount while you build. In the proposal’s Payment tab, choose where the amount comes from: a number field on the linked Salesforce record such as the Opportunity amount or a Quote total, a custom amount with its own description for a deposit or set-up fee, or one or more products and prices from your own Stripe catalogue. Choose who pays when there is more than one signer.
2. Send, and the price is locked. At send, the amount, line items and currency are frozen into the payment record, and the signed PDF gains a Payment terms block listing each line and the total due on signature. Editing the proposal or the Salesforce record afterwards cannot change what the customer is charged.
3. The customer signs and pays. The payer’s button reads “Sign & Pay” with the amount beside it. Once every signer has finished, the payer goes straight to Stripe’s hosted checkout in your brand and pays by card. With several signers, nobody pays until the last one has signed.
4. Salesforce updates itself. A SalesSign Transaction record is created and kept current: status, amount received and refunded, fee, currency, payer, dates and the Stripe IDs. The proposal carries a Payment Status and Amount Paid, “Signed” stays separate from “Paid”, and Flow can trigger on either.
5. Reminders chase unpaid signers. Payment reminders, separate from signature reminders, go out every 3, 7 or 14 days up to 1, 3 or 5 times, and “Send reminder now” is one click from the proposal’s Pay tab.

The money is a direct charge on your own Stripe account, paid out on your usual Stripe schedule, with your name on the customer’s card statement. Card details are entered on Stripe’s hosted checkout and never reach SalesSign or your team.

What it costs

Every route carries the card processor’s own fees. On top of those, the options above differ:

What to check before you switch it on

1. Is the amount frozen at send? The number the customer pays should be the number in the signed document, read from a record created at send, not from whatever the Opportunity says a week later.
2. Does the document say what will be charged? The signed PDF should state the amount and that it is due on signature. SalesSign also warns before sending if the document does not seem to mention the amount, which catches a proposal that says £12,000 with a payment set to £1,200.
3. Whose account receives the money? Prefer direct charges on your own Stripe account, so payouts, refunds and disputes stay in the dashboard your finance team already uses.
4. Does the status reach Salesforce? Paid, refunded and disputed should all be visible on the record, on fields Flow and reports can use, without anyone copying them across.
5. What happens with several signers? Payment should wait until the last signature and go to the one person who pays.
6. How are refunds handled? Refund from your payment dashboard and check that the Salesforce record and any platform fee follow. In SalesSign the fee is returned in proportion to the amount refunded.