Building a Client's Checkout: Whose Merchant Account Should It Be?

On this page 8 sections

1. Who Owns the Payment Account on a Client Website?
2. Why Clients Must Own Their Own Merchant Account
3. Why Your Agency Stripe Account Shouldn't Take Client Sales
4. Setting up a Payment Gateway for a Client Website Without Their Passwords
5. Using Developer Access, API Keys, and Test Mode Safely
6. Documenting the Payment Setup at Handoff
7. What to Do When a Client Leaves and You Hold the Keys
8. Next Steps

Key takeaways

• The client, not the agency, should own the merchant account and gateway account that collect their sales.
• Processing a client's sales through your own Stripe or PayPal account puts chargebacks, payout holds and tax reporting in your name.
• Get developer access through user invitations and API keys the client generates. Never ask for their login credentials.
• Document every payment setting at handoff, and revoke and rotate access when the relationship ends.

When you're setting up a payment gateway for a client website, the fastest path is often to paste in your own Stripe or PayPal keys and promise to "sort it out later." That shortcut creates real problems. This guide covers who should own the payment account, the specific risks of running client sales through your agency's account, how to connect a payment processor to a client site without collecting their passwords, and how to document and hand off the setup so nobody is stuck when the project ends.

Who Owns the Payment Account on a Client Website?

The short answer is that the business selling the goods or services owns the account. That applies to the merchant account, the gateway account and the processor relationship. Your agency builds and maintains the checkout, but the money, the customer relationship and the legal responsibility belong to the client.

Here's how ownership usually breaks down on a typical build:

If your contract is unclear on these points, fix that before the next project. A one-paragraph clause stating that the client opens and owns all payment accounts prevents most of the disputes below.

Why Clients Must Own Their Own Merchant Account

A merchant account is underwritten for a specific business. That means a specific legal entity, tax ID, owner, product line and expected sales pattern. The processor approves that business to accept cards for those products. When the client is the account holder:

• Payouts land directly in their bank account. You never touch their revenue.
• Disputes and refunds are theirs to manage. Their name and history are on every transaction.
• Tax reporting matches reality. Processors report payment volume under the account holder's tax ID, so the client's sales show up on the client's records, not yours.
• They can leave you without leaving their checkout. Switching agencies doesn't mean rebuilding payments.

There's a practical benefit for you as well. A clean web developer merchant account setup for each client keeps your own processing history limited to your design and maintenance invoices, which is what your processor approved you for. For more on what those invoices should cost you to process, see our guide to web design agency card fees. To pick a tool for sending those invoices, see our comparison of the best invoicing software for web design agencies. If some of those invoices go to clients abroad, see our comparison of fees for getting paid by international web design clients.

Why Your Agency Stripe Account Shouldn't Take Client Sales

Using an agency Stripe account for a client, or routing their orders through your PayPal, can feel harmless when the volume is small. Here's what can go wrong.

Chargebacks Land on You

Every dispute filed against a client's product is filed against your account. If the client ships late, sells something defective or goes out of business, you absorb the chargebacks and refunds. Your dispute ratio is what the processor monitors, not theirs. For more on how disputes work in this industry, see winning chargebacks after a site launches.

Payout Holds Freeze Everyone

A sudden jump in volume or an unfamiliar product category can trigger a review or hold on your account. That freezes the client's sales revenue and your own agency income at the same time. If you've dealt with this before, our guide on why Stripe holds large web design payments explains the mechanics.

It Usually Violates Your Processor's Terms

Standard merchant agreements generally prohibit accepting payments on behalf of another business unless you've been approved as a platform or payment facilitator. Processing a third party's sales through your account can be treated as transaction laundering. That can lead to account termination, and in some cases to being placed on the MATCH list. A MATCH listing can make it difficult to get a merchant account anywhere.

This matters most when the client is in a category that requires its own underwriting, such as supplements, CBD or vape products. Putting those sales under your approval isn't a workaround. It's exactly what processors are built to catch. Those clients should apply directly with a provider that handles high-risk merchant accounts.

Taxes and Bookkeeping Get Messy

Gross sales volume reported under your tax ID can look like agency income. You'd then need to document that the money passed through to the client. This is general information, not tax advice. Talk with a qualified tax professional if any client revenue has already run through your account. For how sales tax applies to your own agency invoices, see our guide on whether web design is taxable by state.

The Relationship Becomes Hostage-Prone

If the client's revenue flows through you, every disagreement about invoices or scope becomes a disagreement about their money. That's a bad position for both sides.

Illustrative example: An agency launches a boutique's online store on the agency's own processor account "temporarily." A few months later, the boutique has a run of returns and disputes, and the processor places a reserve on the agency's account. The agency's own monthly retainer payments are held along with the boutique's sales, even though the agency sold nothing.

Setting up a Payment Gateway for a Client Website Without Their Passwords

The right way to connect a payment processor to a client site keeps credentials in the client's hands from day one. A clean process looks like this:

1. Have the client apply in their own name. They provide the business documents, ownership details and bank information. You can help them understand what to expect, but they submit the application themselves.
2. Confirm what they sell and how. Make sure the application accurately describes their products, pricing model (one-time, subscription, deposits) and fulfillment. The account should match what the checkout actually does.
3. Pick a gateway that fits their platform. Match the gateway to their cart, whether that's Shopify, WooCommerce, BigCommerce, Magento or a custom build. Our WooCommerce payment gateway checklist is a useful starting point for WordPress stores.
4. Ask the client to invite you as a user. Most gateways and processors let the account owner add team members with defined roles. Request the narrowest role that lets you configure the integration.
5. Have the client generate or approve API keys. Ideally the client creates the keys and sends them through a secure channel, or you generate them under your invited user while the client keeps ownership.
6. Never accept the owner login. If a client offers you their username and password, decline politely and walk them through the invitation process instead.

If a client doesn't have a processor yet, MannyPay offers merchant accounts and payment gateway options, including Authorize.net and NMI, with integrations for common carts. The client applies directly, and underwriting decides approval.

Using Developer Access, API Keys, and Test Mode Safely

Once you have access, treat the client's keys like their bank PIN.

Build in Test Mode First

• Use the gateway's sandbox or test credentials for all development work.
• Run test transactions for every path: successful payment, decline, refund, partial refund and, if relevant, subscriptions or saved cards.
• Don't run real cards through a live account to "check if it works" unless the client has approved a specific live test and knows to refund it.

Handle Keys Carefully

• Store keys in environment variables or a secrets manager, not in your code repository, theme files or project chat threads.
• Keep test and live keys separate, and label them clearly in your config.
• Use restricted keys with only the permissions the integration needs, where the gateway supports it.
• Verify webhook signatures so your site only trusts genuine payment notifications.
• Don't keep personal copies of live keys after deployment.

Keep Card Data off the Server

Hosted payment fields, embedded checkout forms or redirect checkouts keep raw card numbers off your client's server. This generally reduces how much of the PCI DSS compliance burden falls on the site. Ask the processor which integration method fits the client's compliance needs. For in-store or phone orders, a virtual terminal can let staff key in payments without building custom card forms.

Documenting the Payment Setup at Handoff

A good handoff document means the client, their next developer or their processor's support team can understand the checkout without calling you. Include:

• Account details: Processor and gateway names, account owner and where to log in. Leave out passwords.
• User list: Every person with dashboard access and their role, including you.
• Integration method: Plugin or app name and version, or the custom code location.
• Key inventory: Which keys exist, where they're stored and who created them. Don't record the key values themselves.
• Webhook endpoints: URLs, the events subscribed and how signatures are verified.
• Settings that affect money: Capture timing (authorize-only versus immediate), currency, fraud filters, address verification and 3-D Secure settings.
• Recurring billing: How subscriptions or saved payment methods are configured.
• Testing record: What you tested and when.
• Offboarding steps: How to remove your access and rotate keys.

Have the client sign off that they received it. If you offer ongoing support, you can fold payment monitoring into a care plan. See our guide on automating monthly retainer billing for maintenance plans. If hosting is part of that plan, see our guide to reselling hosting to clients, including billing, markups and failed payments.

What to Do When a Client Leaves and You Hold the Keys

Clients move on. How you exit protects your reputation and limits your liability.

If the Client Owns the Account

1. Remove your user from their gateway and processor dashboards, or ask them to remove you.
2. Recommend they rotate any API keys you handled, and help them update the site config.
3. Delete local copies of credentials, .env files and backups that contain keys.
4. Send the handoff document and a short written confirmation that your access is gone.

Don't withhold access or keys as leverage over an unpaid invoice. Our article on whether you can legally take down a non-paying client's site covers safer options. Confirm specifics with an attorney. If the client cancels before the project is finished, see our guide to web design kill fees and getting paid when a client cancels mid-project.

If Sales Have Been Running Through Your Account

Fix this deliberately rather than abruptly:

1. Have the client open their own merchant account in their name.
2. Switch the checkout to the new account and test it before cutting over.
3. Keep your old account open long enough to handle refunds and late disputes on past orders.
4. Reconcile and pass through any remaining funds with clear records.
5. If the site uses saved cards or subscriptions, ask both processors whether stored payment data can be migrated. Don't simply cancel and hope customers re-enter cards.
6. Get tax guidance on how the passed-through volume should be reported.

Next Steps

The rule is simple: build the checkout, but let the client own the account. Put that in your contracts, use invited access instead of passwords, keep keys out of your repos, and document everything at handoff.

If you're comparing processors for your own agency billing, start with our breakdown of Stripe, PayPal and Square for web designers. For client builds that need a merchant account and gateway in the client's own name, see MannyPay's payment solutions for web design agencies, or request a free quote. A MannyPay specialist responds within one business day.

ME

About the author

MannyPay Editorial Team

Beyond the Swipe's editorial desk researches the publication's guides and news and cites its sources in every article. Articles reviewed by a named MannyPay editor carry that editor's byline.

This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.