Letting an agency talk to your payment provider: set the boundary first

Specify the conversation and the action it permits

Write down the provider, the merchant account being discussed using a non-sensitive internal label, the agency participant and the purpose of the contact. Identify whether the participant may ask a technical question, receive a response, supply factual evidence, request a change or accept a decision. These are separate permissions. An authorization to explain the installed gateway should not silently become authorization to change settlement details or agree to account terms.

Use the merchant’s agreement with the agency to define what the merchant is authorizing, then check the provider’s requirements for recognizing that representative. If the provider requires an additional authorization or a particular account role, record that requirement before including private account information. Merchant permission alone does not guarantee that the provider will disclose account details to the agency.

Set a review or end point for the authorization and name the merchant contact who will handle questions beyond it. Keep the authorization reference with the conversation record. This makes an ongoing arrangement usable between projects without granting every future request automatically.

Match the topic to the person who can substantiate it

Technical integration questions can be prepared from facts the agency is authorized to inspect: the platform, installed payment extension and version, relevant configuration and an existing error or event reference. The agency should distinguish what it observed from a proposed explanation. Neither a visible payment method nor a completed technical connection establishes the provider’s approval of the research-only business.

Website-review feedback can be mapped to the provider’s exact wording, the public URLs involved, the requested response and any genuine published changes. The merchant confirms the business facts and authorizes changes within the agreed process. Sending evidence of an edit does not mean the provider accepted it; record the actual reply or leave acceptance unresolved.

For identity or account-verification requests, the agency can help identify which request remains outstanding if it has permission to see it. The person responsible for the relevant declaration or record must answer through the provider’s accepted process. Do not let the agency assert ownership or sign an attestation simply because it can open the screen. Where delegated submission is allowed, document that authority and the approved secure route; do not turn it into blanket authority over all verification.

Payout or reserve questions require the relevant provider record and the appropriate account contact. An agency may help describe a technical mismatch or join a discussion when authorized, but authority to receive an explanation does not authorize moving funds, changing bank details or accepting revised terms. Assign those decisions explicitly to the account holder or the provider-recognized authorized representative.

Use named provider access and the right support route

Stripe’s teams documentation describes invitations, assigned roles, least-permission access and activity logging. For a Stripe account, compare the proposed work with the role’s actual permissions before granting access. Name the user, role and reason in the register. The existence of a role does not establish that Stripe will treat that person as authorized for every legal statement or account decision.

For Stripe used through a third-party platform, Stripe’s support guidance directs account contact through the logged-in account Dashboard. It describes references such as charge identifiers beginning with ch_ or py_ and transfer identifiers beginning with tr_. Use the appropriate existing reference only in the authorized support conversation. Those prefixes identify record types; they are not an instruction to invent a reference or include full card details.

Another provider or platform may use a different contact process. Record its documented route rather than assuming a Stripe invitation or Dashboard workflow applies. A website administrator login alone is not evidence of provider-side authorization. If the agency lacks the required access, it can prepare a factual brief for the merchant’s authorized contact without impersonating that contact.

Keep secrets out and preserve the response boundary

Stripe’s API-key documentation says secret and restricted keys must not be shared through email, chat or other unencrypted channels. Its platform support guidance also says never to send full card numbers or CVCs. A support request should identify the connection and the existing record, not expose the credential that lets software act on the account. Keep passwords, authentication codes, identity documents and full bank details out of the conversation register and public consultation form.

After an authorized exchange, record who spoke, the date, the question, the provider’s response and any action still requiring the merchant’s decision. Preserve a written confirmation where an answer changes the scope or authorization. A recommendation from support and an authorized instruction to implement it are different records; do not mark the change approved merely because it was discussed.

When the assignment changes or ends, have the authorized account administrator compare continuing access with the work still permitted and amend or remove access through the provider’s process as appropriate. Keep the conversation history available to the merchant. A person leaving the project should not take the only record of an unanswered account question.

For a Prism checkout consultation, summarize the technical or website issue and who is authorized to participate. Confirm scope, responsibilities, fees and terms, including any proposed provider-contact assistance, before work. The inquiry itself does not create agency authority or authorize anyone to send a provider message.

Authorized-conversation register

Complete a record for each provider and agency participant. In the last column, name the authorized speaker, permitted action, provider route and merchant decision owner, with the authorization reference and review date. An unconfirmed permission remains pending. Keep this as an access-and-topic record, not a store of private account documents or credentials.

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.