Recording business changes before a processing application or review

A change log keeps both versions

An application answers for the business as it is now. A reviewer can still see the old domain, the old name, or a prior notice. If those facts are omitted, the current answer and the older record disagree. The log is the place that shows the date the fact changed and the document that shows the change. It is not a new biography that starts on the day the website was redesigned.

Checking the current application against the current site is a separate pass. This page is the history that pass can miss. Do not collapse a domain change, an ownership change, a catalog change, and an operations change into one word such as rebrand. They are different facts and may have different dates.

What changed, and what the record is

For a domain, keep the old URL and the date the new URL became the site buyers use. For a trade name or legal name, keep both strings and the formation or filing record that changed them. For the catalog, keep what the business offered before and what it offers now, including a product that was removed only on paper. For operations, keep who held the goods and who shipped them before the change, and who does those things now.

If you do not know the date, say the date is unknown. Do not invent one so the log looks complete. A prior provider notice stays in the log even if you would rather discuss only the current application.

Notice to a provider is not the same thing as a clean start

Stripe's prohibited-uses section says that if any personal or business information changes, you must notify Stripe immediately. It also prohibits using Stripe with false, manipulated, inaccurate, or misleading information about identity, the business entity, or the nature of the business, and processing for products or services that were not disclosed. Use that as Stripe's instruction to keep Stripe's information current and accurate. Do not read it as permission to open a new description and drop an earlier restriction, a prior account, or a product you still sell.

Another provider may require a different notice, or written approval before a change. This page does not have that provider's rule. Ask, in writing, whether the change must be reported and whether the earlier event still matters.

When the change answers a provider's request, log the response too

A change made because a provider asked for it has more parts than the change itself. The log needs the provider's issue in its own words, the affected URL, the before-state a reviewer could see, the person who made the change, the date the new version was actually public, and the date you verified it live. An intended edit is not a published change.

Then the log waits on the provider. Record whether the provider accepted the change, asked for more, or did not answer. Silence is an unresolved item, not a closed one. Bringing that log to a consultation is more useful than a summary from memory: the request, the published change, and the open items are all dated.

A new domain keeps the business history attached

A domain move is not only a URL pair. Entity continuity, catalog continuity, the policies and contact pages, and the checkout all cross over or they do not. Record whether the same legal entity sells the same catalog at the new address, whether the policy and contact pages came across unchanged, and where the checkout and its payment flow now live.

Tell the provider about the new domain through its own channel, and keep the answer. A new address does not retire the old one from the story: the provider that reviewed the old domain can still find it, and an application that presents only the new domain invites the mismatch the log exists to prevent.

A materially new product category is a change to ask about before it goes live, not after. Write the provider the current disclosed business and the proposed category, and file the written answer. Launching first and disclosing later is concealment risk, not a rollout.

An entity change is a tax fact and still part of the story

The IRS instructions for Form SS-4 say that if a sole proprietorship incorporates or enters a partnership, a new EIN is required. Line 10 includes a reason for a change in type of organization, and the instructions give the example of moving from a sole proprietorship to a partnership. Line 11 says that if you are changing the form of ownership, you enter the date the new ownership entity began. Those sentences belong in the log when they describe what happened. They do not say a new EIN retires a payment-provider issue, and they do not say the old name can be left off an application that asks about prior business.

You can assemble the pairs and the questions you still need to ask the provider. You cannot decide that the new domain or the new entity is eligible. A Prism consultation can help you put the history in ordinary language for that question. Scope, fees, and terms are discussed before work. The inquiry is not an application, and it is not a way to hide the earlier version.

Dated change log

Each row is one kind of change. Keep the earlier fact even when the current fact is the one you want reviewed. Leave the row blank if that fact did not change and you have no prior version.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.