> For the complete documentation index, see [llms.txt](https://docs.hyperswitch.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hyperswitch.io/integration-guide/control-center/operations.md). # Operations ## Operations **Operations** is your day-to-day command center. It's where support and ops teams spend most of their time: looking up transactions, issuing refunds, fighting disputes, and managing customers and payouts. Everything here respects your current **mode (Test/Live)** and **selected profile** — see Getting Started if that's new to you. The Operations section contains: * Payments * Refunds * Disputes * Customers * Payouts *** ### Payments The **Payments** screen lists every payment attempt for the selected profile and mode. #### Finding a payment * **Search** by payment ID, connector reference, customer email, or amount. * **Filter** by status, connector, payment method, currency, or a date range. * **Saved views** let you save a filter combination (e.g. "Failed card payments today") and reuse it with one click. * **Customize columns** to show the fields your team cares about, then export the list if you need it in a spreadsheet. #### Payment statuses at a glance | Status | Meaning | | ---------------------------- | -------------------------------------- | | **Succeeded** | Payment completed and captured | | **Requires capture** | Authorized, waiting for you to capture | | **Processing** | In flight at the processor | | **Requires customer action** | Awaiting 3DS / redirect / next action | | **Failed** | Declined or errored | | **Cancelled** | Voided before capture | #### Payment details Click any row to open the full payment view. Here you can see: * **Summary** — amount, currency, status, customer, connector used. * **Timeline** — an event-by-event history (created → authorized → captured → refunded), useful for debugging. * **Attempts** — if routing retried across connectors, each attempt is listed. * **Connector response** — raw processor codes and messages for troubleshooting declines. * **Actions** — depending on status: **Capture**, **Refund**, or **Cancel/Void**. > 💡 A declined payment's **connector response code** is the fastest way to understand *why* it failed. Pair it with the timeline to see exactly where it stopped. *** ### Refunds The **Refunds** screen lists all refunds and their status. You can also start a refund directly from a payment. {% embed url="" %} #### Issuing a refund 1. Open the payment (Operations → Payments → click the row), or go to **Refunds → Create**. 2. Choose **full** or **partial** refund and enter the amount. 3. Add an optional reason/note for your records. 4. Confirm. The refund is sent to the processor and appears with a **Pending** status until the processor confirms. #### Refund statuses | Status | Meaning | | ------------- | -------------------------------------------- | | **Pending** | Sent to the processor, awaiting confirmation | | **Succeeded** | Funds returned to the customer | | **Failed** | Processor rejected the refund | > Refund capabilities depend on the connector — some support partial refunds, some don't. If the refund action is disabled, check the connector's capabilities. *** ### Disputes When a customer challenges a charge with their bank, it becomes a **dispute** (chargeback). The Disputes screen helps you track and respond to them. #### The dispute lifecycle | Stage | What it means | Your move | | --------------------------- | ---------------------- | ---------------------------------------------- | | **Opened / Needs response** | Bank raised a dispute | Gather and submit evidence before the deadline | | **Under review** | Evidence submitted | Wait for the bank's decision | | **Won** | Resolved in your favor | Nothing to do | | **Lost** | Resolved against you | Funds are debited | #### Responding to a dispute 1. Open the dispute to see the reason code, amount, and **respond-by deadline**. 2. Review the linked payment for context. 3. Submit **evidence** (receipts, shipping proof, customer comms) if the connector supports it through Hyperswitch. 4. Track status until it resolves. > ⏰ Disputes are deadline-driven. Sort by respond-by date and handle the soonest first. *** ### Customers The **Customers** screen lists the customers created against your account and their saved details. From here you can: * **Search** customers by name, email, or ID. * Open a customer to see their **profile**, **saved payment methods / tokens**, and their **payment history**. * Understand a customer's full relationship with you in one place before taking a support action. > Saved payment methods and tokens tie into the **Vault** — see the Vault section for how tokenization works. *** ### Payouts If payouts are enabled for your account, the **Payouts** screen manages money going *out* to recipients (sellers, contractors, users). Here you can: * View **payout transactions** and their status. * Create a payout to a recipient using a configured **payout processor**. * Track lifecycle from initiated → in-transit → succeeded/failed. > Payouts require a **payout processor** connected under Connectors, and can use **Payout Routing** to pick the best rail. See the Connectors and Workflow sections. *** ### Where to go next * **Connectors** → connect the processors that power these payments. * **Workflow** → set up routing, 3DS, and fraud rules that shape payment outcomes. * **Analytics** → aggregate views and trends across all this operational data. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.hyperswitch.io/integration-guide/control-center/operations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.