Start with a permitted transfer
An account purchase should be treated as a defined product transaction, not as a favour or an informal exchange of login details. The product may be an advertising account, a business asset that includes an account, or access to an account type that the platform permits to be transferred. Those are not interchangeable arrangements. Before discussing payment, both parties need to establish what is being transferred and whether the platform’s terms and available tools allow that transfer.
This point matters on platforms such as Meta and Google, where advertising access is connected to platform policies, business relationships and account controls. A seller’s willingness to hand over credentials does not, by itself, make a transfer authorized. If an account cannot be transferred through ordinary, platform-sanctioned steps, do not treat a password change as a substitute for permission. Consider a permitted alternative, such as receiving authorized access to a business asset, or creating an account under the buyer’s own business instead.
At this stage, the seller should identify the account and explain the proposed transfer method. The buyer should have a written note recording what is being transferred and the platform-approved basis for the handover. A common failure is to treat “account included” as a sufficient description, then discover that the seller meant temporary access, an account that cannot be reassigned, or an asset the buyer cannot lawfully control.
Put the specification in writing
The written description is the transaction’s specification. It should identify the platform, the account or business asset, its intended role, and the precise access or ownership being delivered. If the purchase concerns a Meta advertising setup, for example, distinguish the ad account from related assets such as a business portfolio, page or pixel. For Google Ads, distinguish the advertising account from any linked manager account or other business property. Name only assets that are actually part of the deal.
The seller acts by describing the product accurately and listing any limitations or dependencies. The buyer acts by checking that the description matches the job the account is meant to do. The buyer’s record should be a dated written agreement or order confirmation that both sides can refer to, together with any relevant asset identifiers and the agreed handover method. Keep the description factual; do not rely on claims about likely performance or future income.
Vague wording is a frequent source of disagreement. “Ready to run ads” might mean only that an account exists, not that the buyer has the required permissions, billing setup, or access to connected assets. A seller may also describe a bundle without clarifying which parts belong to another business. The detailed article on account selection can cover how to match an account type to a job; here, the central point is to define the item before money changes hands.
Make payment traceable
Payment should follow the written specification and use a method both parties can document. The buyer acts by paying the agreed amount through the documented channel; the seller acts by confirming receipt and keeping the transaction connected to the agreement. The buyer should retain the payment confirmation, the seller’s acknowledgment, and the version of the written specification that applied when payment was made.
Payment is not proof that an account has been delivered, and it does not establish that the buyer has accepted the product. It is one stage in the sequence. If the transaction depends on a particular transfer method or a staged release of funds, those terms should be written down beforehand, rather than improvised after a problem appears. Avoid sending additional payments based only on an urgent message that changes the original arrangement.
Common problems include paying before the parties have settled what “handover” means, losing the connection between a payment and the specific account, or having no record of what the seller promised. A payment receipt alone cannot resolve those questions. The buyer should be able to place it alongside the written specification and see that the payment relates to the same transaction.
Deliver the agreed access
Delivery is the seller’s act of transferring the agreed account or authorized business access by the method available on the platform. It may involve an invitation, a role change, an asset assignment or another supported process. The buyer should not ask for, or rely on, a method designed to conceal a transfer, evade platform checks or defeat account security. Nor should the seller represent shared credentials as ownership when the agreement promises a formal transfer.
The buyer’s record at delivery should include the platform’s confirmation or other ordinary evidence that the invitation or assignment was made, plus a note of which assets and permissions arrived. The buyer should check that the access is associated with the intended business identity and that the role matches the specification. The seller should retain a delivery confirmation and avoid claiming that the transaction is complete before the agreed assets are available.
Delivery often fails through missing components or mismatched permissions. The buyer may receive access to an ad account but not to the business asset needed to administer it, or may be given a role that permits routine work but not the control promised in writing. An invitation can also go to the wrong account identity. The detailed handover guide can address platform-specific screens; the general lesson is to compare what arrived with the list of what was promised.
Run an acceptance check
Once access arrives, the buyer acts by checking the delivered product against the specification before treating the transaction as complete. This is an operational check, not an attempt to bypass the platform’s review or security processes. Confirm that the account or asset is the one described, that the buyer can open it through normal platform access, and that the expected permissions and linked assets are present. Review visible settings and account notices through the platform’s ordinary interface.
The buyer should keep a concise checklist, screenshots or platform-generated confirmations that show what was checked and what remains unresolved. Do not capture or circulate sensitive information unnecessarily. If the account’s status, access or connected assets differ from the written description, record the discrepancy and notify the seller through the agreed channel. The seller should respond by clarifying the issue or completing the promised delivery, not by asking the buyer to ignore a warning or work around a platform control.
A rushed check can miss a mismatch, while an overly broad assumption can turn a minor omission into a dispute. An account may be accessible but still lack a promised asset; conversely, a buyer may expect a feature that was never included. The specification is the reference point. A separate article on acceptance checks can explain how to inspect an account type in more detail without replacing this transaction-level comparison.
Take control of recovery and administration
After the initial check, the buyer and seller should complete any remaining authorized changes needed to put ongoing administration under the buyer’s control. This can include updating administrative contacts or recovery details where the platform permits, confirming that the buyer’s own business identity has the appropriate role, and removing the seller’s access when the agreement and platform process allow it. The seller acts by assisting with the authorized handover; the buyer acts by verifying each change in the platform itself.
The buyer should retain confirmation of role changes and updated administrative details, without storing passwords or recovery codes in the transaction record. Mailboxes and phone numbers used for registration or recovery need particular care: the buyer should understand who controls them, whether they are part of the permitted transfer, and whether the platform allows them to be changed. A mailbox or number that remains under the seller’s control can leave the buyer dependent on someone else, even when the account appears accessible.
The usual failure is confusing access with control. A buyer may be able to work in an account while the seller still controls an administrator identity or recovery channel. Another risk is changing details in a way that triggers a platform security process, then treating that process as a reason to bypass verification. Use the platform’s normal settings and support routes. The detailed article on recovery contacts can cover those choices separately.
Define the seller’s check window
Some agreements allow a seller a limited check window after delivery to confirm that the buyer has received the specified assets and that the agreed handover is complete. This is a transaction safeguard, not a platform guarantee and not permission for the seller to retain hidden control. The parties should write down when the window begins, what each side is expected to verify, how a problem must be reported, and what happens if neither side raises an issue.
During this stage, the buyer should keep the acceptance checklist and any messages about unresolved discrepancies. The seller should confirm the delivery items that remain within their responsibility and respond to documented problems. Both sides should use the same written channel where practical, so there is a clear record of whether an issue was reported and what response followed.
A common failure is leaving the check window undefined, then arguing about whether a complaint was timely or whether a particular omission was covered. Another is treating silence as acceptance when the agreement never says that it is. A clear process helps avoid both assumptions. The article devoted to seller check windows can explore the wording and workflow; the essential principle is to settle the process before payment, not during a dispute.
Record acceptance and close the handover
The account is considered accepted when the conditions written into the transaction have been met and the buyer records that conclusion through the agreed process. That may mean confirming that the described account and assets arrived, the required access works, and any agreed corrections were completed. It should not mean that the buyer waives concerns that were reported within the agreed check window, or that acceptance guarantees future platform access, advertising performance or compliance outcomes.
The buyer acts by sending a clear acceptance notice, or by recording the remaining exceptions if the agreement provides for partial acceptance. The seller acts by acknowledging completion and closing any outstanding delivery tasks. The buyer should keep the final acceptance message with the specification, payment record, delivery confirmations and notes of the check. Together, those documents make the transaction understandable without relying on memory or informal assurances.
The handover is not complete merely because money has moved or a login works. Nor should it be left open indefinitely after the agreed checks are finished. A well-defined close records what was bought, what was delivered, what was verified, and when the parties treated the delivery as accepted. That sequence gives a new media buyer a practical map: define the product, document payment, verify delivery, take authorized control, and close the transaction on the terms both sides agreed.