Refunds often need to happen in the middle of customer conversations. When a refund request comes in, teams need context fast: who the customer is, what was paid, and what’s happened so far, without jumping between systems.
For many teams, issuing a refund still means leaving Salesforce, logging into a payment portal, and stitching the outcome back together later. Service teams work in one system. Finance reconciles in another. The connection to the original payment can get lost along the way.
FinDock brings refund initiation into Salesforce so refunds can be handled from the same place as the customer record and the original payment, alongside the cases, payments, and customer records teams already manage.
This is especially useful for service and finance teams that process refunds while working cases, payment plans, or billing questions.
Refunds belong in Salesforce
Handling refunds from Salesforce keeps the full customer and payment context in one place, while giving teams tighter control over how refunds are issued, including clear control over who can initiate them.
Refunds are initiated against a specific payment, which reduces the need for broader checks or handoffs and keeps the scope of the action clear. Service teams can issue refunds while they’re working on the customer record and receive confirmation back from the payment processor without switching tools.
Finance teams can trace each refund directly back to the original payment, making follow-up and reporting more straightforward. Refunds become part of the same workflow as the customer conversation that triggered them, instead of a separate process owned by a single team.
From full refunds to partial refunds
With FinDock, teams can initiate full or partial refunds directly from Salesforce and receive feedback on the outcome. The component surfaces eligible payments, flags any prior refunds, and presents customizable refund reasons, so agents have the context they need before confirming.
FinDock integrates refunds deeply into your broader returns process, with different options depending on how much flexibility your team needs:
- Native component. An out-of-the-box Lightning web component that can be deployed directly on an Installment, Opportunity, or Gift Transaction record. No custom development needed to get started.
- Flow action. Refunds can be triggered from a Salesforce Flow, making it straightforward to embed refund handling into existing service or billing workflows.
- Custom LWC. For teams that need full control, the refund action is available as an Apex invocable that can be called from a custom Lightning component. Code examples are available in the FinDock Knowledge Base under Integrating Refunds.
This makes it possible to align refunds with existing service and finance workflows, instead of forcing teams to adapt to a separate refund tool.
A unified customer view for refunds
Refunds in FinDock are handled as first-class records in Salesforce, so they sit alongside the customer record and the original payment, not as disconnected events.
When a refund is initiated, FinDock creates a refund record that stays linked to the original payment. Status updates from the payment processor are processed through inbound reports, so Salesforce reflects whether a refund is pending or completed without manual reconciliation.
Teams can also layer their own eligibility rules on top of FinDock’s processor-level validation. Beyond checking whether a payment can technically be refunded, you can define internal criteria for when a refund should be allowed, based on payment type, membership tier, order type, or any other criteria that matter to your business. This gives finance teams control over the process without building it from scratch.
Because refunds follow the same inbound processing pattern as payments, teams can build on Salesforce’s native capabilities to extend the process. That includes Approval workflows for refunds that require sign-off, Flow automations, and custom notifications, all configured inside Salesforce.
This approach keeps refund activity traceable and consistent with how payments are already managed in FinDock.
Availability
Refunds from Salesforce is currently in beta. Full and partial refunds are supported across all payment methods for the following processors:
- Stripe – added in the May ’26 release
- Authorize.net – added in the May ’26 release
- Paya – available since the January ’26 release
Support for additional processors is planned in future releases. If you are using a processor not yet on this list and want to be considered for early access, contact FinDock Support.
See refunds in action
The best way to understand how refunds from Salesforce work is to see them in action. The May ’26 release webinar includes a demo of the native component, showing a service agent initiating a refund from Salesforce, selecting the amount and reason, and receiving confirmation from the processor – all without leaving the customer record.
Watch the walkthrough in the May ’26 release webinar or reach out to the FinDock team to see how refunds could fit into your existing Salesforce setup.
For configuration details and setup guidance, see the refunds documentation in the FinDock Knowledge Base.
For configuration details and rollout updates, see the refunds documentation for Paya in the FinDock Knowledge Base.