Establish who actually sells to the buyer, whose account would take payment and who would receive the proceeds. Describe those parties and the proposed flow to the provider before using your account for the partner’s sales. Stripe prohibits processing for another undisclosed merchant. Stripe Connect is designed for payments among multiple parties, but its existence does not approve this partner, catalog or arrangement. The decision is whether you have a specifically supported, accurately disclosed arrangement; a working payment link or a plan to forward the funds does not answer that question.
For: A research-only merchant considering a partner’s request to collect the partner’s customer payments through the merchant’s existing account.
Read the offer, order terms and invoice that the buyer would receive. Identify the business promising the goods, the business shown as the seller and the party expected to handle fulfillment and buyer questions. Compare those records with the partner proposal. If they identify different sellers or leave the seller unclear, preserve that contradiction for resolution before collecting payment.
Then identify the account holder named in the processing relationship and the intended recipient of the customer proceeds. These roles may differ in a documented platform arrangement, but the difference needs to be explicit. A shared brand, a close business relationship or permission from the partner does not establish the payment provider’s permission.
Keep a resale arrangement, where your business is actually the seller under its own documented offer, separate from a proposal merely to collect another seller’s receivables. Do not rewrite the buyer’s terms to make the second arrangement appear to be the first. Where the parties disagree about the legal role, obtain qualified advice on that question rather than resolving it through a checkout setting.
Disclose the proposed collection before relying on the account
Stripe’s prohibited and restricted businesses page prohibits processing for another merchant that has not been disclosed. Its rules also prohibit misleading information about the business and processing for undisclosed products. Identify the partner and the real research-only catalog when asking about the proposal. Approval of your existing business cannot be treated as an answer about sales by a different business.
The disclosure should describe who contracts with the buyer, which website presents the sale, whose account would take payment, how proceeds are intended to reach the partner and who is proposed to handle refunds and disputes. Use the actual countries, products and sales channels involved. An omitted party or an inaccurate catalog leaves the provider evaluating a different proposal.
Disclosure is necessary to obtain a meaningful answer; it is not itself acceptance. Keep the provider’s written response with its named entities, products, conditions and applicable service. Stripe’s published policy does not establish that every research-only merchant is approved or that every such merchant is rejected. Another provider’s position must come from its own applicable terms and response.
Use Connect as a model to investigate, not assumed permission
Stripe presents Connect for platforms, marketplaces and other businesses managing payments and moving money among multiple parties. Its overview distinguishes a software platform serving businesses that collect from their own customers from a marketplace collecting payments and paying portions to sellers or service providers. Those are different operating descriptions, so first identify which description, if either, resembles the proposed flow.
The overview treats connected-account onboarding, capabilities, verification, charges, balances and payouts as separate integration concerns. That is enough to show why forwarding money after using an ordinary checkout does not establish that a supported multi-party arrangement exists. It is not enough to choose a charge type, allocate liability, determine legal merchant-of-record status or establish eligibility.
If a provider proposes Connect or another platform product, ask for the account arrangement and documentation that support the specific proposal. Keep the commercial and verification conditions separate from the software design. Do not describe the business as already using Connect solely because several parties, websites or bank accounts are involved.
Turn the role map into a decision before collecting
The collection proposal is unresolved when the seller cannot be identified, the account disclosure omits the partner or the provider’s response does not cover the proposed flow. Keep it out of operation while those dependencies remain open. If the provider says the partner must use its own account or a particular supported platform arrangement, document that route and its prerequisites rather than continuing through the existing account as a temporary measure.
If a supported arrangement is documented, compare it against what the buyer will actually see and what the store will actually do. Record the agreed roles for fulfillment, refund decisions, dispute responses and reconciliation. An agreement between you and the partner can describe responsibilities, but it does not replace the payment provider’s terms or resolve a legal question those terms leave open.
For a Prism processing consultation, bring a plain-language map of the parties and the unanswered provider question. Ask for help organizing the business description and proposed scope. Confirm responsibilities, fees and terms before work; the consultation does not authorize third-party collection or promise a provider’s approval. Keep contracts, credentials and private payment records out of the public inquiry.
Third-party collection scope record
Complete this for the proposed arrangement before any partner sales are collected. Use role names, document references and match or mismatch findings. Keep the detailed flow and private contracts in authorized records. A missing provider answer remains an unresolved dependency even when the two businesses agree with each other.
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.
Third-party collection scope record. The last column is for temporary notes.
Role or condition
Record that identifies it
Question to resolve
Your finding
Actual seller
Record that identifies itPartner proposal compared with the published offer and order terms.
Question to resolveWhich business is actually making the sale, and do all of these records name that same business?
Buyer agreement
Record that identifies itTerms and invoice the buyer would receive for the partner’s products.
Question to resolveWho promises the goods and handles buyer obligations; is the role clear before payment?
Account holder
Record that identifies itEntity named on the processing agreement and the account intended to take the payment.
Question to resolveDoes the provider know whose sales this account is proposed to collect?
Proceeds recipient
Record that identifies itWritten proposed flow from customer payment to each business recipient, without bank details.
Question to resolveWho receives funds at each stage and which provider-supported arrangement permits that flow?
Disclosed arrangement
Record that identifies itThe provider inquiry and response naming the parties, catalog, countries and sales channels.
Question to resolveDoes the response address this proposal or only the existing merchant’s business?
Platform dependencies
Record that identifies itProvider-specified account, verification and integration requirements, if a platform product is proposed.
Question to resolveWhich prerequisites are complete, and which still prevent operation of the described arrangement?
Refund and dispute responsibilities
Record that identifies itPartner responsibilities compared with the provider’s applicable account terms.
Question to resolveWho may decide and act, and where is a conflict or unanswered liability question recorded?
Decision before collection
Record that identifies itThe documented permitted route and any remaining conditions.
Question to resolveProceed with preparation only within the supported scope; keep collection unresolved until its requirements are met.
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
This page does not authorize collecting or forwarding funds for another business, determine legal merchant-of-record status or allocate refund, dispute or other liability.
Stripe Connect’s overview supports the multi-party model only. Detailed account behavior, pricing, country availability and catalog eligibility require the applicable documents and provider decision.
Do not disguise the seller, narrow the disclosed catalog inaccurately or treat an existing account as a way around a partner’s restriction. Keep payment credentials and private banking or customer records out of the worksheet and public form.
Stripe prohibited and restricted businesses — checked 2026-09-21. Stripe prohibits misleading business information, undisclosed products and processing for an undisclosed merchant. This does not decide eligibility for the proposed partner or catalog.
Stripe Connect — checked 2026-09-29. Connect supports platforms, marketplaces and other businesses managing payments among multiple parties. Its overview distinguishes software platforms from marketplaces and identifies onboarding, verification, capabilities, charges, balances and payouts as separate concerns. It does not establish the permissions or liability of this proposed arrangement.
Discuss my processing options
Want to talk through your own processing situation?