Stripe operations cross several timelines. The customer sees an authorization or refund, the commerce system records an order, Stripe creates payment and balance objects, webhook deliveries notify internal services, a payout later reaches the bank, and finance closes a reporting period. When those timelines disagree, a support team that searches only by customer email or amount can easily refund twice, fulfill an unpaid order, or explain the wrong payout to accounting.
The remedy is an operational trace built from durable identifiers and explicit ownership. Each case should connect the business order or reservation to the relevant Stripe PaymentIntent, charge when present, Balance Transaction, refund or dispute, payout context, API request ID, event ID and delivery attempt, internal deployment, and accounting entry. The trace distinguishes a failed financial operation from a successful payment whose event, application update, report, or bank settlement is delayed.
This runbook is designed for Georgia retail, restaurant, ecommerce, and finance teams using Stripe. Keep it alongside ALLMSP's [Stripe software support resources](https://www.allmsp.com/category/software-support/software-support-stripe/), [Retail and Restaurants coverage](https://www.allmsp.com/category/retail-and-restaurants/), and general [Software Support guidance](https://www.allmsp.com/category/software-support/). Adapt every decision to the payment method, country, account structure, payout schedule, and current Stripe documentation that applies to the transaction.
Key decisions at a glance
- Use a stable business reference to connect the Stripe PaymentIntent or charge, Balance Transaction, payout, refund or dispute, API request, event delivery, and internal order.
- Choose the Stripe Balance report or Payout reconciliation report to match the accounting model, payout schedule, and question being answered.
- Treat refunds and disputes as controlled financial cases with approval, customer communication, deadlines, evidence, event monitoring, and ledger updates.
- Use Workbench request logs and event-delivery attempts to diagnose integration transport while checking the Stripe payment object before changing customer or order state.
- Recover uncertain operations by preserving identifiers, freezing duplicate actions, reconciling authoritative state, replaying only idempotent work, and documenting closure.
Create an Operational Trace and Triage the Right Layer
Put a stable internal order, reservation, invoice, or case identifier into approved Stripe metadata where appropriate, and store the resulting Stripe object IDs in the system of record. Capture the PaymentIntent and charge relationship used by the integration, amount and currency, customer-facing status, Balance Transaction, API request ID, relevant event IDs, internal release, and timestamps in UTC with a local-time display for operators. Never place card data, sensitive authentication data, or secrets in metadata, logs, or support notes.
Triage by layer. First determine the authoritative Stripe payment state in the correct account and mode. Then check the internal order or booking state, webhook event and delivery attempt, application queue and worker result, Balance Transaction, refund or dispute objects, payout and bank evidence, and accounting entry. A failed webhook does not reverse a successful payment, and a pending payout does not mean the originating payment failed. Write the observed state at each layer before taking a compensating action.
Build searchable support fields and retain them according to legal and business requirements. Operators should be able to start from an order, PaymentIntent, charge, refund, dispute, payout, Stripe request ID, or event ID and reach the same case. Limit screenshots to what is necessary, redact customer information, and prefer exported object or report references over manually transcribed amounts. Assign one incident owner and one finance owner so customer communication and ledger decisions do not diverge.
- Record business reference, Stripe account and mode, object IDs, request and event IDs, amount, currency, timestamps, and internal release.
- Confirm the Stripe payment object before changing fulfillment, issuing a refund, or asking a customer to pay again.
- Separate financial state, event transport, application processing, payout settlement, and accounting close in the triage record.
- Use least-privilege access and redaction when exporting logs, reports, payloads, or screenshots for a support case.
Reconcile Stripe Balance Activity and Payouts Deliberately
Select the report that matches the accounting method. Stripe describes the Balance report as a bank-statement-like view for reconciling activity and ending Stripe balance, while the Payout reconciliation report groups transactions included in automatic payout settlement batches. Manual or instant payout workflows can require a different approach because the business controls timing or Stripe cannot identify a fixed transaction bundle in the same way. Document the chosen report, report parameters, time zone, settlement currency, payout schedule, and accounting account before comparing totals.
For each payout, match the bank deposit to the Stripe payout record and report period, then explain the underlying payments, refunds, disputes, fees, adjustments, reserves, and ending unsettled balance. Preserve the report generation time and filters because daily data availability and late financial events can change what a later export shows. Use custom metadata or internal order references when they are available, but do not force a one-payment-to-one-payout assumption when Stripe's balance activity groups many transactions.
Investigate a missing or failed payout from the payout object outward. Verify the account, bank destination, schedule, expected arrival, status history, email or Dashboard notice, and bank confirmation. Stripe notes that a payout can initially appear paid and later become failed after the bank returns it, so avoid closing the case on the first status alone. Correct bank details only through an authorized procedure, validate the change independently, and do not resend or reroute funds based solely on an urgent email.
- Document whether finance reconciles Stripe as a clearing account, by automatic payout batch, or through another approved method.
- Match the bank deposit, payout object, Stripe report, balance activity, and accounting entry before resolving a difference.
- Explain refunds, disputes, fees, adjustments, reserves, and ending balance rather than treating gross payments as expected cash.
- Escalate bank-detail changes and failed payouts through verified contacts with dual review and preserved status history.
Control Refunds and Disputes as Financial Cases
A refund request needs the original payment, requester identity, business reason, amount, prior refunds, fulfillment state, policy, approver, idempotency record, and customer communication. Stripe refunds return to the original payment method, and available Stripe balance can affect processing state. After submission, monitor the Refund object and relevant events until the result is final; do not assume that clicking refund completed the bank-side outcome. If the status is pending, failed, or canceled, follow the current Stripe guidance and coordinate an alternate resolution without duplicating reimbursement.
A dispute is not an ordinary refund. Record the Stripe dispute ID, charge and order, reason category, amount and fee, response deadline, customer claim, evidence requirements, communications, and decision to accept or challenge. Stripe's Dashboard guides the response, but the issuing bank decides the outcome. Evidence should answer the specific claim with a concise chronological record—receipt, delivery or service proof, policy acceptance, authentication evidence, and customer communications—rather than a large unrelated attachment dump.
Connect the case to finance and operations. Freeze automatic duplicate credits, mark inventory or loyalty implications, record the balance impact, and track the dispute or refund through final status and reporting. If a customer says they withdrew a dispute, continue following Stripe's evidence and deadline process because withdrawal is not itself a final win. Review recurring reasons by store, channel, product, descriptor, delivery method, and workflow so prevention work targets the actual failure pattern.
- Require approval and a stable case identifier before a refund, then retain the Stripe Refund ID and final status.
- Check existing refunds and disputes before compensating a customer through another channel or creating a second Stripe action.
- Build dispute evidence around the reason code, customer claim, timeline, transaction, fulfillment, policy, and communications.
- Update customer service, inventory, loyalty, accounting, and fraud controls when the financial case changes state.
Diagnose With Workbench, Recover Safely, and Prove Closure
Use Stripe Workbench to inspect API request logs, events, and webhook delivery attempts in the correct account and environment. Filter request logs by time, status, method, endpoint, source, account context, API version, or error details, then correlate the Stripe request ID with application logs. For an event problem, inspect the event object, destination, delivery status, HTTP response, retry timing, and payload version. A manual resend is a transport action; the consumer still needs deduplication and idempotent business logic.
For an incident, preserve the earliest reliable time, affected channels, business references, Stripe object and request IDs, event deliveries, error responses, queue state, deployment and configuration changes, payout or report evidence, and customer impact. Pause only the risky automation, not every unrelated payment path. Do not delete a destination, rotate all credentials, replay every event, or refund every uncertain order before establishing scope. If unrecognized key use or account changes appear, incorporate ALLMSP's [Cybersecurity guidance](https://www.allmsp.com/category/cybersecurity/) and contact Stripe through verified support channels.
Recovery begins with authoritative state. Reconcile uncertain orders against Stripe, restore the last known good code or configuration, repair the endpoint or worker, replay only verified and idempotent work, and monitor new transactions plus the backlog. Closure requires zero unexplained operations in the incident window, completed refund or dispute follow-up, balanced payout or accounting impact, customer communication where needed, restored monitoring, and a corrective action owner. For help connecting Stripe evidence to the wider commerce stack, use the ALLMSP [contact team](https://www.allmsp.com/contact-us/).
- Correlate Workbench request logs, events, delivery attempts, application logs, queues, deployment history, and business records.
- Resend an event only after confirming the target consumer is idempotent and the underlying Stripe object still supports the action.
- Reconcile every uncertain operation before retries, refunds, fulfillment, bank changes, or customer requests for another payment.
- Close with verified financial totals, restored controls, documented customer outcomes, lessons learned, and assigned remediation dates.
Vendor documentation and ALLMSP resources
- Stripe: Receive Payouts
- Stripe: Reporting
- Stripe: How to Select a Report
- Stripe: Balance Summary Report
- Stripe: Payout Reconciliation Report
- Stripe: Refund and Cancel Payments
- Stripe: Disputes
- Stripe: Respond to Disputes
- Stripe: Workbench Overview
- Stripe: Manage Event Destinations
- Stripe: Integrate With Events
- ALLMSP Stripe Software Support
- ALLMSP Retail and Restaurants
- ALLMSP Software Support
- ALLMSP Cybersecurity
- Contact ALLMSP
Frequently Asked Questions
Which Stripe identifiers should a payment support case record?
Record the Stripe account and mode, internal order or reservation, PaymentIntent, charge when present, Balance Transaction, refund or dispute, payout context, API request ID, event IDs and delivery attempts, amount, currency, UTC timestamps, and internal release. Capture only what the case needs, redact personal data, and never include card details or credential values.
Does a failed Stripe webhook mean the customer's payment failed?
No. A webhook delivery is a notification attempt, while the Stripe payment object holds the financial state. Confirm the PaymentIntent or related payment object first, then inspect the event destination, delivery response, internal queue, and business record. Do not ask the customer to pay again or reverse fulfillment solely because the webhook endpoint returned an error.
Should finance use the Stripe Balance report or Payout reconciliation report?
Use the Balance report when treating Stripe like a bank or clearing account and reconciling activity plus ending balance. Use Payout reconciliation when automatic payout batches are the accounting unit and finance needs the transactions settled in each deposit. Manual and instant payout workflows need special consideration. Document the selected method, filters, time zone, currency, and schedule.
Why does a Stripe payout not equal gross sales for the same day?
Payouts reflect available balance and the account's payout timing, not a simple same-day gross-sales transfer. Fees, refunds, disputes, adjustments, reserves, currency conversion, pending funds, and transactions from different processing dates can affect the amount. Reconcile the bank deposit to the payout and report rather than comparing it only with the point-of-sale sales total.
What should we check when a Stripe payout is missing or failed?
Verify the correct account, payout object, bank destination, schedule, expected arrival, status timeline, Dashboard or email notice, report, and bank response. A payout can change from paid to failed after a bank return. Re-enter bank details only through an authorized, independently verified process, then follow Stripe's current guidance for resuming payouts or contacting the bank.
Can a Stripe refund be sent to a different card or bank account?
Stripe refunds return to the original payment method; they are not a way to redirect money to another destination. If the original method is unavailable, the issuer or payment-method process determines handling. Track the Refund object and events through final status. Use a separately approved customer-remediation process if Stripe reports that the refund failed.
What information belongs in a Stripe refund approval?
Include the original payment and order, requester and customer identity checks, business reason, amount, prior refunds or disputes, fulfillment state, policy, approver, idempotency record, Refund ID after creation, customer message, and accounting treatment. Checking prior compensation prevents duplicate reimbursement across Stripe, cash, gift card, bank transfer, or another support channel.
How should a retailer organize Stripe dispute evidence?
Answer the specific dispute reason with a short chronological package. Include the transaction and order, accurate product or service description, customer acceptance of applicable terms, delivery or usage proof, authentication evidence where relevant, refund history, and customer communications. Follow the deadline shown by Stripe, keep within current network limits, and avoid irrelevant documents that obscure the response.
When is it safe to manually resend a Stripe event?
Resend only after confirming the event belongs to the correct account and destination, understanding why the original delivery failed, and verifying that the consumer deduplicates the event and applies an idempotent state transition. Inspect the current Stripe object before replay. A resend should repair notification transport, not recreate the underlying payment, refund, shipment, or accounting entry.
What proves a Stripe payment incident is fully recovered?
Closure requires authoritative Stripe and internal states for every uncertain operation, no unexplained duplicates, processed or safely dismissed event backlog, reconciled refunds and disputes, verified payout or accounting impact, correct customer and fulfillment outcomes, restored monitoring, and assigned corrective actions. Preserve the final evidence and use ALLMSP's [contact team](https://www.allmsp.com/contact-us/) when multiple commerce systems need coordinated remediation.
