Orders and support

A refund request from someone else needs an authorized handoff

Record what the person is asking and their claimed relationship to the order, then use the merchant’s actual verification procedure to establish whether they may request that action. Keep claimed authority, verified authority and refund approval as separate findings. An order reference or a relationship claim does not settle all three. Do not collect card numbers, authentication codes or identity documents in the worksheet. If authority is unresolved, assign the case to the merchant’s decision owner without promising a refund or revealing the order’s private details.

For: A research-only merchant’s support team receiving an order-refund request from someone other than the contact it already recognizes for that order.

Updated 2026-10-01

Get help with store operations

Separate the request from the relationship claim

A person may describe themselves as acting for the buyer or the purchasing business. Capture that description as a claim, alongside the requested action and an internal case reference. Do not silently change it to “authorized representative” because the person knows an order number or can quote the request’s amount.

Identify what the request would change. Asking whether a request has been received, asking for a refund, and asking to send money to a new destination are different instructions. Keep them distinct in the case record. A verified relationship for one purpose does not, by itself, answer whether the merchant’s procedure permits the particular action now requested.

Until the merchant establishes the permitted scope of the conversation, acknowledge receipt without sending customer records or payment details. The support note can say which decision is pending; it does not need to repeat private order information back to an unverified requester.

Use the procedure the merchant actually operates

Find the merchant’s existing procedure for verifying a person who acts for a buyer, including who may resolve exceptions. Record its name or internal location and the check actually performed. If that procedure specifies a known contact or an established account channel, use that route as instructed rather than treating a new address supplied in the same request as verified.

The worksheet should record the outcome and a pointer to evidence held in the authorized support system, not copies of identity papers or a full conversation. Keep the claimed relationship visible beside the verified finding. If the procedure is missing or does not address this request, mark authority unresolved and assign the gap to the merchant’s decision owner. Do not invent a document requirement or declare a legal right from this page.

Verifying authority to request a refund is still separate from deciding whether the refund is approved under the merchant’s actual policy and the order’s facts. The person who verifies the request may not be the person who approves it or operates the payment account. Name those responsibilities in the handoff instead of allowing a support acknowledgment to become an instruction to return funds.

Do not turn verification into a request for payment secrets

The PCI Security Standards Council’s FAQ 1085 states that unprotected primary account numbers must not be sent through email, instant messaging, SMS or chat. That rule concerns card numbers; it is not a general prohibition on ordinary support messages. There is no reason to put a card number into this authority worksheet.

Do not ask for a full card number, security code, login password or one-time authentication code to make the refund request seem more credible. Nor should the worksheet become a collection point for identity documents or bank details. Record the procedure’s non-sensitive result and where the authorized evidence is retained. If the requester offers sensitive information, avoid copying it into another note or forwarding it through the public consultation form.

Keep the original-payment rule separate from the identity check. Stripe refunds return to the original payment method and cumulative refunds cannot exceed the original charge. A requester naming a different recipient or bank destination does not change that rule. Any genuine method-specific instruction must come from the provider’s actual process; this page supplies no alternate-route workaround.

Give the next owner a decision that is still accurately labeled

The handoff should distinguish authority unresolved, authority verified but refund decision pending, and a documented approved or declined decision. These are suggested internal descriptions for the worksheet, not provider status codes. Include the requested action, the verified scope of authority, the merchant’s decision owner and the next action that owner has actually assigned.

If the refund is approved, the authorized operator still has to match the actual payment and any earlier refunds before acting. After action, support should use the provider’s recorded refund state. Approval is not money returned, and a requester’s expectation is not an arrival date. Stripe’s refund outcome and statement timing depend on the payment method and bank; do not promise an arrival date from the support handoff.

For a Prism checkout-review consultation about a recurring handoff problem, describe the website, research-only products and the point where authority or ownership becomes unclear. Keep the case file and customer records in the merchant’s systems. Confirm the scope of any requested workflow review, responsibilities, fees and terms before work begins. The public form leads to email follow-up; submitting it does not approve the request, book work or submit a processing application.

Third-party request record

Use one copy for one actual request. The final column records non-sensitive findings or internal evidence pointers, never identity files or payment secrets. Claimed authority remains unverified until the merchant’s real procedure produces a finding; refund approval remains a separate decision.

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 request record. The last column is for temporary notes.
Request detailEvidence to recordHow it affects the handoffYour finding
Order referenceInternal case/order pointer located by authorized staff; omit customer details.Connects the request to a record without treating knowledge of a reference as authority.
Requester relationshipThe relationship the requester claims and whether it has been verified.Keeps a claimed representative separate from one recognized by the merchant’s procedure.
Actual authorization evidenceProcedure used, check outcome, permitted scope and an internal pointer to evidence.Shows what the merchant verified without collecting card data or identity documents here.
Requested actionRefund amount or scope requested and whether a destination change was also requested.Separates permission to discuss an order from permission to request a particular action.
Decision ownerMerchant role responsible for authority exceptions and the refund decision.An unresolved procedure goes to a named owner rather than becoming an assumed approval.
Refund decision and operatorActual approved, declined or pending decision and the authorized operator, if assigned.A verified requester does not itself establish that a refund was approved or executed.
Next communicationNon-sensitive status the team may communicate under its procedure and who will send it.Avoids disclosing private records or promising funds before the relevant decision and provider outcome exist.

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 worksheet organizes the merchant’s existing procedure; it does not determine legal agency, mandate an identity document or decide a person’s entitlement to a refund.
  • Stripe’s refund destination and amount limits apply to Stripe payments. They do not define every provider’s process or establish processing eligibility.
  • Do not enter card numbers, authentication codes, passwords, bank details, identity documents or customer records in this worksheet or the public consultation form.

Related guides

Sources

  • PCI SSC FAQ 1085 — checked 2026-09-21. PCI SSC FAQ 1085 prohibits unprotected primary account numbers in email, instant messaging, SMS and chat. It addresses card-number transmission, not a universal refund-authority procedure.
  • Stripe refunds — checked 2026-09-29. Stripe refunds return through the original payment method and total partial refunds cannot exceed the original charge. Actual method and refund state matter, and bank timing is not a merchant guarantee; these facts do not establish a third party’s authority.
  • Prism solutions — checked 2026-09-21. Prism publishes storefront review, processing preparation and help with provider website questions. Any requested workflow work needs an agreed scope, fees and terms; the provider decides account eligibility and terms.
  • Prism contact — checked 2026-09-21. The consultation form asks for the website, products and question and excludes payment details, passwords and customer records. Email follow-up does not make the request a booking, purchase or processing application.

Get help with store operations

Need help with the order, email or fulfillment step itself?

Get help with store operationsAll resources