Client payments

Client payments let your clients pay the invoices you send them by card or bank transfer, online, through a payment processor account you own. The money goes from your client to your processor account and on to your bank. Outpost never holds it. This page explains how online payment works, which processors you can connect, and what each one means for your PCI assessment.

Client payments are for the invoices you send your own clients. Your Outpost subscription is paid in the Outpost portal. See Invoices, taxes, and payments.

How a client pays

Once you connect a processor, every invoice email carries a pay link. Your client can pay in three ways:

Way	What the client does
Pay link	Opens the link in the invoice email and pays without signing in. The link stops working a set number of days after the due date, 90 by default.
Client portal	Signs in to the client portal, opens the invoice, and pays with a new or saved method. See Client portal.
Autopay	Authorizes you once to charge a saved method on each invoice’s due date. The authorization is its own step, never a checkbox on a payment. See Set up autopay for a client.

You can also charge a client’s saved method from the console, and record payments that arrive any other way, such as a check, as before. See Send pay links and charge saved methods.

The payment is recorded on the invoice when the processor confirms it, and a receipt is emailed to the client’s billing contact. A bank payment (ACH) takes 3 to 5 business days to clear. Until it does, the invoice shows it as Processing, not yet paid, never as paid, and overdue reminders for that invoice are held. If the bank returns it, the payment is taken off the invoice and the client is emailed.

Caution

Do not record a payment by hand for an invoice with a payment in progress. If both land, the client has paid twice. The invoice’s Online payments card warns you when this applies.

Choose a processor

Connect the processor you already have a merchant account with. You can connect more than one.

Processor	Cards	Bank payments	How card details are entered	PCI SAQ	Card surcharge possible
Stripe	Yes	Yes	Stripe’s fields inside the page	A	Yes
Square	Yes	Yes, one-time only	Square’s fields inside the page	A	No
Braintree	Yes	Yes, through a bank sign-in	Braintree’s fields inside the page	A	Yes
Authorize.net	Yes	Yes	Authorize.net’s own payment form, inside the page	A	No
QuickBooks Payments	Only after you acknowledge SAQ A-EP	Yes, the default	Fields on a page your Depot serves	A-EP	No

• Square cannot keep a bank account on file, so a Square client can save only a card for later payments and autopay.
• Card surcharge possible depends on whether the processor can tell a credit card from a debit card before the charge. Only Stripe and Braintree can. See Add a card surcharge.
• QuickBooks Payments connects by signing in to Intuit rather than by pasting keys. It cannot be asked about a payment that timed out, so you settle those by hand. See Resolve a payment with an unknown outcome.

What PCI DSS means for you

No card number, security code, or bank account number reaches Depot. Card and bank details are typed into fields the processor serves, and Depot receives only a token that stands for them.

The self-assessment questionnaire (SAQ) your practice completes depends on how those fields are served:

• SAQ A. The processor serves the fields inside the page, so card data never touches a page you serve. Stripe, Square, Braintree, and Authorize.net work this way.
• SAQ A-EP. QuickBooks Payments has no hosted card fields. Card details are typed into a page your Depot serves and sent from the browser to Intuit. That puts the longer SAQ A-EP on your practice. Bank payments through QuickBooks are not affected, which is why cards stay off for a QuickBooks provider until you acknowledge it.

This is guidance on how Outpost handles card data, not a PCI assessment. Your acquirer or assessor decides which SAQ applies to your practice.

Payment pages in the client portal ask the client to confirm who they are again after 15 minutes without activity, as PCI DSS 8.2.8 requires. The session itself is not cut short.

Primary and per-client providers

New payments and new autopay authorizations go to your primary provider. You can send one client to a different provider from their billing profile, for example a client who pays a different entity of your business. A method a client saved stays with the provider it was saved on.

To move every client to a new processor, you make the new one primary. The old one keeps charging the methods saved on it while each client is asked to set up again. See Switch payment providers.

Who can do what

Task	Permission
See providers (keys masked), payment profiles, attempts, and refunds	psa:read
Connect, change, and retire providers; change payment settings; choose a client’s provider; resolve an unknown outcome; see payment events	psa:payments
Charge a saved method, email a pay link, stop a client’s autopay, remove a saved method, email an autopay set-up link	psa:invoice
Refund a payment	psa:refund

Every role that holds psa:admin also holds psa:payments and psa:refund. Payment actions are never available to AI tools, including Pioneer AI and connected MCP clients.

Related

• Connect a payment provider
• Send pay links and charge saved methods
• Set up autopay for a client
• Refund a payment
• Add a card surcharge
• Payment settings and emails
• Invoice clients