Transitions and provider reviews

Confirm the dependencies in a provider-led migration

Use the migration notice and applicable agreements to identify the existing and proposed parties, the accounts and services affected, any action required from the merchant, access to historical records and ownership of open financial obligations. Confirm the contractual change separately from the operational handoff. A vendor's migration announcement alone does not establish consent requirements, transfer of approval, continuous payment acceptance or release from earlier obligations.

For: A research-only merchant receiving a vendor notice about moving its payment accounts to a new acquiring arrangement.

Updated 2026-10-01

Identify what the provider is actually moving

Keep the received notice, its date and its stated effective date together. Extract the legal companies it names, the merchant accounts it covers and the services it says will change. A portfolio announcement can describe the provider's project without answering every question for an individual merchant. Mark an account or service unconfirmed if the notice does not identify it clearly.

Compare that notice with the current acquiring relationship and the proposed one. Keep the acquirer, contracting payment company, gateway and platform as separate entries where the records name separate roles. An unchanged checkout plugin or dashboard brand does not establish an unchanged contract. A changed acquirer does not, on its own, establish that every software connection must change.

For a business with more than one domain, payment method or account, list which are expressly included. Do not silently extend a notice for one account to the rest of the business. The result of this step is a defined migration scope, with missing account-level confirmations still visible.

Read the relevant party's assignment and action terms

Determine whether the documents describe assignment of an agreement, amendment of existing terms, a new agreement or a different change. Record which party is taking that action and the clause the notice relies on. These are questions to answer from the documents, not labels to choose from the vendor's use of the word migration.

Stripe's general terms illustrate why the full agreement matters: general, service and incorporated terms work together, regional terms depend on account country, and section 11.10 includes consent provisions and a conditional successor-assignment route. That does not establish that this merchant's provider-led migration requires its consent or qualifies for that route. Read the provision for the party and transaction actually involved, together with the applicable regional and service terms.

Separate the notice's requested merchant action from your interpretation of its legal effect. Record any signature, confirmation, information request, deadline and stated consequence exactly as they apply to this account. If the notice says no action is needed but another account-specific document requests action, retain the conflict for written clarification. Questions about legal effect or enforceability require advice on the actual agreements; a public terms page cannot decide them.

Confirm both future processing and earlier obligations

Build two handoff lists. The first concerns new activity: which account can accept which payment methods, what configuration changes are required, and what the provider has confirmed about availability on the stated date. The second concerns existing activity: who handles prior refunds and disputes, outstanding balances, fees and any reserve obligations shown in the account's records. A reply about new sales does not close the second list.

Stripe's Payments terms state that obligations on existing transactions continue after those terms end and that new transactions must not be accepted through the services after termination. Regional terms prevail on conflict. This supports keeping old-transaction responsibility separate from a new processing arrangement; it does not establish that a particular migration terminates the old agreement or transfers those obligations to a successor.

Ask for the stated handling route and responsible party for each open item, using the relevant agreement and actual account records. Do not assume an old reserve, refund obligation or fee disappears because the new dashboard works. Likewise, do not describe the new account as approved for the research-only catalog solely because a provider announced a portfolio move. Obtain the account-specific scope and conditions.

Make the handoff usable after the announced date

Identify where staff will retrieve earlier statements, transaction references and case histories after the change, and what legitimate access they will retain. Check the retrieval route while it is available. Record a known access end date only if the notice or provider gives one. If history will not be accessible through the proposed system, the unresolved dependency is how the business preserves and uses those records, not simply whether a login works.

Assign an owner to each merchant action and unanswered dependency. Treat a row as confirmed only when its supporting document or observed operational record answers the question. A row about record access needs a usable retrieval path; a row about an open dispute needs a responsible party and case route. Do not use an announced migration date as evidence that either is complete.

The next decision is which required actions the merchant can complete and which unresolved dependencies need clarification before it treats the handoff as complete. For a Prism processing consultation, provide a non-sensitive summary of the notice, affected business scope and open questions. Confirm assistance, responsibilities, fees and terms before work. The consultation does not determine contractual enforceability, grant processing approval or promise continuous acceptance.

Provider-led migration dependency map

Read the received notice alongside the agreements for the actual account and country. Record document references and named owners, without full account or bank details. A general announcement does not close an account-specific row; preserve contradictions and mark missing confirmations unresolved.

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.

Provider-led migration dependency map. The last column is for temporary notes.
DependencyEvidence to compareWhat must be establishedYour confirmation or open question
Existing acquiring relationshipCurrent agreement and account records naming the payment company, acquirer and merchant entity.Identify the present parties and roles without using the gateway logo as the contracting name.
Proposed relationshipMigration notice and any proposed account-specific agreement or amendment.Identify the new parties, affected accounts, methods and domains; mark any scope not explicitly covered.
Contractual mechanismThe clause relied on for the change, its party-specific conditions and relevant regional or service terms.Distinguish assignment, amendment or new agreement and leave legal interpretation unresolved where necessary.
Merchant action requiredThe actual request, stated deadline, submission route and consequence in the notice.Name the authorized owner for each required action and reconcile contradictory instructions.
Future payment activityWritten account-specific availability and scope confirmations, plus any stated configuration requirements.Separate announced migration timing from confirmed readiness and eligibility for the actual business.
Historical record accessCurrent retrieval route, provider statement about later access and any stated end date.Identify how staff will retrieve old transactions, statements and cases after the change.
Open financial responsibilityExisting transaction obligations and actual open refund, dispute, balance, fee or reserve records.Name the handling party and route for each item; do not infer release or transfer from the migration announcement.

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.

Limits

  • Stripe terms are a provider-specific reference. Their clauses do not establish the rights or duties under another provider's migration or decide legal enforceability.
  • There is no universal consent requirement, migration deadline, record-transfer promise or inherited processing approval established by this worksheet.
  • Keep agreements and financial records in controlled storage. Public consultation messages should omit full account and bank details, credentials, customer lists and identity documents.

Sources

  • Stripe Services Agreement general terms — checked 2026-09-29. The recorded September 28, 2026 version combines general, service and incorporated terms, with regional terms based on account country. Section 11.10 includes consent provisions and a conditional successor-assignment route. These clauses require the actual party and agreement context; they do not establish a universal merchant-consent rule.
  • Stripe Payments terms — checked 2026-09-21. After Stripe Payments terms end, existing transaction obligations remain and new transactions must not be accepted through those services; regional terms prevail on conflict. This does not establish whether a particular migration ends an agreement or transfers obligations.
  • Prism solutions — checked 2026-09-21. Prism can discuss processing preparation, with scope, responsibilities, fees and terms confirmed before work; the provider determines eligibility and account terms.

Discuss my processing options

Want to talk through your own processing situation?