What agencies should know before adding payments to a client project.

It usually arrives as a line in a brief: 'we would also like customers to be able to pay by stablecoin'. It sounds like a checkout plugin. In practice it introduces keys, uptime, reconciliation, and a support burden that lasts long after the agency invoice is paid.

This guide is for agencies and freelancers who build for clients and want to say yes to payments without accidentally becoming responsible for someone else's money.

The responsibility map

Before quoting, decide who owns each piece. The table below is the conversation to have with every client.

The line to hold

If your agency can move the client's funds, you have taken on a different kind of business. Keep keys and signing with the client.

Three ways to add payments

A self-hosted product such as StablePay can be deployed for a client they already operate, with a branded checkout. The software is theirs to run; the studio and the agency are not custodians and do not process payments as a service.

Scoping the work

1. 01

   Ask what the payment is for

   Orders, invoices, subscriptions, donations. The flow decides the integration.

2. 02

   Agree on networks and tokens

   One of each to start. Only enable what the software implements and tests.

3. 03

   Write the confirmation policy with the client

   When does an order count as paid? This is a business decision they must own.

4. 04

   Define the handover

   Runbook, fire drill, and a named person on the client's side.

5. 05

   Price post-launch support separately

   A bounded retainer for payment incidents, with response windows in writing.

Contract language worth including

• Custody exclusion. The agency does not hold, move, or have access to client funds or keys.
• Scope of support. What is covered after launch, in what hours, and at what cost.
• Third-party dependencies. Networks, RPC providers, and wallets are outside the agency's control.
• Compliance. The client is responsible for its regulatory, tax, and legal obligations.

Have a lawyer review your own contract. The list above is a prompt for that conversation, not legal advice.

A launch sequence that protects everyone

A statement of work template for payments

Put the responsibilities in the contract, not the launch email. The skeleton below is a starting point for your own lawyer to adapt; it is not legal advice.

1. SCOPE
   Agency will integrate the client's website/app with the client-operated payment gateway
   ("Gateway"), including checkout, event handling, and order updates.

2. CLIENT RESPONSIBILITIES
   Client operates the Gateway, holds all keys and credentials, and is responsible for funds,
   confirmation policy, reconciliation, tax, regulatory and legal obligations.

3. CUSTODY EXCLUSION
   Agency does not hold, move, or have access to Client funds, signing keys, or wallets.

4. DELIVERABLES
   Integration; runbook; fire-drill session; documentation.

5. POST-LAUNCH SUPPORT
   Optional, separately priced, bounded: <hours>, <response window>, <exclusions>.

6. THIRD-PARTY DEPENDENCIES
   Networks, RPC providers, and wallets are outside Agency's control.

Support tiers that do not overpromise

Do not imply availability you do not staff

A line like "we're always here" in a launch email becomes a contractual expectation the first time a payment fails on a weekend. Say exactly what you will and will not do.

An incident communication template

When something goes wrong, clients need short, factual updates on a predictable rhythm. Prepare the template before you need it.

SUBJECT: [Payments] <short description> — update <n>

Status:      Investigating | Identified | Monitoring | Resolved
Impact:      <who is affected, what they see>
Funds:       <confirm whether funds are affected or safe, only if known>
What we know: <facts only>
Next update: <time>
Action for you: <if any>

Branding and white-label considerations

• Checkout appearance. A self-hosted gateway can present a branded checkout; confirm what the software allows and what is customised in your integration.
• Terms and receipts. Payment terms, receipts, and refunds policies belong to the client's business and should be written by them.
• Support routes. Decide who a customer contacts about a payment: the client, not the agency.

The handover meeting

1. 01

   Walk the architecture

   Where the gateway runs, where secrets live, and where your integration sits.

2. 02

   Walk the runbook

   Follow two entries live in staging.

3. 03

   Run the fire drill

   The client's operator repeats a failure recovery without help.

4. 04

   Confirm responsibilities

   Read the responsibility map aloud; correct anything that has drifted.

5. 05

   Schedule the review

   Book the thirty-day check-in before the meeting ends.

The twelve-factor methodology ^[1] and the SRE practices on being on-call ^[2] are good shared vocabulary for this conversation, especially with a client whose team has not operated a payment system before.

If you build for clients and want a payments component you can deploy on their infrastructure, the StablePay product page describes the licences, the event contract, and what the software deliberately does not do.