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. Refund actions can be embedded into Salesforce Flows or Lightning components, so teams decide where refunds belong in their processes, whether that’s from a case, an installment, or another record.
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.
Because refunds follow the same inbound processing pattern as payments, teams can extend the process with their own automation, notifications, or approval steps where needed.
This approach keeps refund activity traceable and consistent with how payments are already managed in FinDock.
Availability
FinDock extends Salesforce with the ability to initiate refunds against payments. This is supported with Paya today, with additional PSP coverage planned over time.
See refunds in action
The best way to understand how refunds from Salesforce work is to see them in action.
In the demo below, a service agent initiates a refund from Salesforce, receives confirmation from the payment processor, and sees the refund linked back to the original payment.
If you want to understand how refunds could fit into your existing Salesforce setup, watch the walkthrough in our release webinar or reach out to the FinDock team.
For configuration details and rollout updates, see the refunds documentation for Paya in the FinDock Knowledge Base.