Whose Name Is on the Payment, Cloud and App Store Accounts? The Most Expensive Invisible Clause in an Outsourcing Contract

Fourteen months after launch, she discovered the payment account was not hers

A pet supplies e-commerce brand paid NT$620,000 for an order and membership system. It ran smoothly for 14 months. In month 15 they wanted to move to a new vendor, and only then found four things: the payment gateway merchant application was filed under the vendor's company, the SMS provider account was tied to the vendor's tax ID, the AWS root account email was dev@vendor-domain, and the App Store listing used the vendor's developer account. The migration took 38 working days and an extra NT$210,000 (our own estimate from cases we handled). The worst part was not the money. It was the 12 working days of re-applying for and clearing payment gateway review, during which a settlement cycle slipped and NT$1.8 million in sales sat in someone else's account. Nobody acted maliciously. It all started with one sentence: it is faster if we register the accounts.

Five things most people believe about account ownership that are wrong

• Myth 1: I paid for it, so the accounts are mine. Ownership follows the registered legal entity and the contracting party, not who funded development. The counterparty to a payment gateway merchant agreement is the company named on the application, and settlement only ever lands in that company's bank account.
• Myth 2: The contract says I own the source code, so the accounts come with it. Code and accounts are separate. Under Article 12 of Taiwan's Copyright Act, for a commissioned work, if the contract is silent on economic rights, those rights vest in the commissioned party and the commissioning party merely obtains a right to use. Even the code default is not on your side, so third-party accounts certainly do not transfer automatically.
• Myth 3: Register under the vendor now, change it later. Whether you can change it depends on the service provider. Domain registrant changes, cloud account migration between organizations, and app developer legal-entity identity are three completely different processes, and payment and app store accounts are usually re-applications rather than transfers.
• Myth 4: This does not belong in the free quote stage. That is the most expensive silence in the project. The cheapest moment to decide ownership is before signing, when it costs one sentence. After launch it costs the 38 working days above.
• Myth 5: Small projects do not need this rigour. Small projects fail here most often, because sharing the vendor's account, one test SMS sender ID and one API key across clients looks like a saving until you cannot even separate the invoices.

The core framework: an 8-category ownership matrix

Sort every third-party service into three tiers using one question: if this account goes dark, does my business stop? If yes, it is registered to the client. No exceptions.

The rule fits on one line: L1 and L2 are registered and paid for by the client, with the vendor holding access only; L3 belongs to the vendor as long as the artefacts are exportable. Paste this table into the RFP and it is settled before quoting starts.

Three companies, three different conclusions

• A 6-person apparel store (no IT, owner doubles as finance): the owner opened every L1 account personally in one 90-minute guided video call. Because nobody could administer cloud infrastructure, we manage it, but the root email is ops@client-domain and billing is reimbursed monthly at cost. Roughly NT$6,000 of extra coordination buys the ability to take control back at any moment.
• A 75-person parts manufacturer (one MIS staffer): capable of administering accounts but short on time. All L1 and L2 accounts sit with the company, the MIS staffer is the sole owner, and we work through IAM sub-accounts with a quarterly access review. Their real problem was never ownership. It was that a departed MIS employee still held root MFA.
• A 240-person restaurant chain (IT department and procurement): policy requires all cloud spend on a corporate card with a purchase requisition, which makes it the simplest case. We hold IAM roles and deploy permissions only, and our quote drops by roughly NT$30,000 because account setup, vendor onboarding and expense reconciliation all sit on their side.

The hidden costs nobody prices in

Registering under the vendor saves two hours before signing. Here is what it costs later (ranges are our own estimates from past engagements):

• Re-applying for payment processing: 8 to 15 working days with no collection or a dual-running period, and rates get renegotiated. The official ECPay fee page states that online payment rates are set per merchant after risk assessment with 5% business tax added, so a fresh application will not necessarily match your old terms.
• Re-publishing the app: a new developer account means a new review, users must re-download, ratings reset to zero and existing subscriptions cannot be transferred. For the required D-U-N-S number, Google Play's official guidance warns it can take up to 28 days, while Apple's documentation cites around 5 business days. Both belong on the schedule.
• Cloud migration: if the account itself can move (AWS account migration between organizations is an invite-and-accept flow), budget 3 to 6 hours. If resources must be rebuilt, a mid-sized system runs 40 to 80 hours, about NT$32,000 to NT$64,000.
• Recovering the domain: at best a registrant change, and you can confirm the current state through TWNIC's WHOIS and accredited registrar lookup. At worst it becomes a dispute proceeding with legal fees.
• Data you cannot take: SMS and email sending history is usually non-portable and simply resets to zero.
• Lost negotiating leverage: the most expensive item. When the critical accounts sit with the other side, a 20% renewal increase is not really a negotiation. This cost never appears on any quote.

Ten questions to ask before you sign (vendor scorecard)

Score each 0 (cannot do it), 1 (possible for an extra fee) or 2 (standard practice), out of 20. Below 12 means this vendor's default is to keep the accounts.

Clauses you can paste into a contract or quote

Clause X. Ownership of third-party service accounts
1. All third-party services used in this project that fall under Tier L1 (payment gateway, e-invoicing, domain names, SSL, business email, mobile app store listings) or Tier L2 (cloud compute and storage, SMS, transactional email, push notifications, map and other metered APIs, analytics and monitoring) shall be registered in the name of the Client and paid for directly by the Client. The Vendor shall hold only the minimum access necessary to perform the work, as an invited member or sub-account.
2. The Vendor shall not register such accounts in its own name. Where a provider's onboarding process genuinely requires temporary registration under the Vendor, this shall be recorded in writing and transferred to the Client within thirty days of go-live, with liquidated damages of NT$1,000 per day of delay.
3. At each delivery the Vendor shall provide an account register listing service name, registered entity, payment method, administrative contact and current access holders.
4. On termination or expiry the Vendor shall, within ten working days, remove all of its own access, return keys and administrative control, and confirm completion in writing. Unpaid final invoices shall not be grounds for refusing or delaying this handover.
5. Economic rights in the software works delivered under this project shall vest in the Client upon payment in full, as agreed pursuant to Article 12 of the Copyright Act. The Vendor retains rights in its pre-existing general-purpose components and frameworks and grants the Client a perpetual, non-exclusive licence to use them.

Clause 5 is the one that matters. A blanket "all copyright transfers to the client" forces vendors to hand over their own reusable libraries, so most will refuse or reprice. Written as above, both sides can sign and you lose nothing you actually needed.

Three things studios do not say out loud

• Accounts in our name make clients harder to lose. Nobody writes this in a proposal, but it is a real commercial design choice. The only meaningful difference between vendors is whether someone raises it before signing.
• Fronting cloud and SMS bills carries margin. Reimbursement arrangements often hide a 10 to 20% markup that the client never sees at the line-item level. We pass metered costs straight through at zero margin, which also means the client handles a few more card reconciliations each month. That inconvenience is real.
• Making the client open accounts is annoying in month one. D-U-N-S takes time, payment applications need extra documents, cards need international transactions enabled. Honestly, it delays kickoff by 5 to 10 working days. Whether a vendor is willing to absorb that delay is the most honest signal of professionalism you will get.

Startup playbook: a 90-day timeline for putting accounts in the right name

• D1 to D5, signing week: complete the ownership matrix and list every third-party service the project will use. Name one account owner on the client side (usually finance or the founder, not an admin assistant). Start the D-U-N-S application immediately, since it is the longest wait on the path.
• D6 to D20, provisioning: client completes L1 registrations, payment and e-invoicing applications are filed, domain and business email go live. The vendor develops against sandbox and test keys and is never blocked.
• D21 to D45, integration: L2 services are provisioned and least-privilege keys issued. Keys live in environment variables and a secrets manager, never in Git. First version of the account register is published.
• D46 to launch: production keys replace sandbox keys, and the client's account owner personally signs into each console once to confirm they really have access. Nobody may do this step on their behalf.
• Day 90 review: run an access audit. List everyone with access, remove departed staff and closed engagements, refresh the register, and run one live drill: with the vendor fully offline, can the client reset their own passwords? If not, the work is not finished.

Decision checklist: 12 self-checks

• ☐ I know how many paid third-party services this system uses
• ☐ The payment gateway merchant application is under my company tax ID
• ☐ Settlement lands in my company's bank account
• ☐ The domain registrant is my company, not any individual
• ☐ The cloud root account email is on my domain and I receive its verification mail
• ☐ Cloud and SMS invoices come to me directly, not re-issued by the vendor
• ☐ App Store and Google Play accounts are registered to my company
• ☐ I hold an account register that was updated within the last six months
• ☐ I can sign into at least three critical consoles without telling the vendor
• ☐ The contract states a handover deadline in working days after termination
• ☐ No production key is shared with another client
• ☐ Access for former employees and former vendors has been fully revoked

Three or more answers of "no" means you are not currently the effective controller of your own system.

FAQ

Everything is already in the vendor's name. Can this still be fixed?

Yes, but handle the categories separately. Domains and cloud accounts can usually be transferred and are a procedural matter. Payment and app store accounts generally require a fresh application, so plan 8 to 15 working days and a dual-running period. Suggested order: open the new payment account and test it end to end, then move the domain and DNS, then deal with the app. Do not move everything in one week or you will not know which change broke what.

The vendor says registering under them is faster. Is that a lie?

It is not a lie. It genuinely saves 5 to 10 working days at kickoff. The problem is that the convenience is paid for with your future optionality. The fair compromise is contractual: temporary registration under the vendor, full transfer within 30 days of go-live, with liquidated damages attached. A vendor willing to sign that clause is usually not hiding traps elsewhere either.

What is the risk of letting the vendor front cloud costs?

Three risks. You cannot see the original invoice, so you cannot tell whether there is a markup. If the vendor's card fails, your service stops with it. And on the day you part ways, resources can be shut down before you finish migrating. If you must use reimbursement, require the original provider invoice each month and a contractual 30-day written notice before any suspension.

Will these clauses make the quote more expensive?

Yes, but not by much. Our estimate is that fully implementing the ownership tiers adds 3 to 6 hours of coordination, roughly NT$4,000 to NT$8,000, or under 1.5% of a mid-sized project. Set against the NT$210,000 and 38 working days at the top of this article, it is the highest-return investment in the whole engagement.

Next step

If you are not sure how many of your accounts are in someone else's name, we offer a free 30-minute ownership audit: bring your current contract and consoles, and we will build the register with you, mark the risk level of each item, and tell you what can be transferred versus what must be re-applied for. No sales pitch, and no requirement to replace your current vendor.

• Email：[email protected]
• 電話：0916-224-047
• LINE：@ufv9089p

In fairness, three kinds of clients are a poor fit for us: those who want us to own the accounts and the bills so they never have to think about it; organisations unwilling to name a single account owner; and projects that ask us to reuse a previous vendor's accounts without written authorisation. In those three cases we will tell you to hire someone else.