Refunds when a dispute cancels a milestone
When RekberPay settles a dispute by cancelling a funded milestone, the money it holds for that milestone goes back to the paying workspace. This guide shows what the payer gets, where the refund appears, how it moves from queued to sent and what to do if something looks wrong.
It covers workspace deals. Refunds on consumer escrows work differently and are in Handling disputes. For how a dispute is opened and decided, see Disputes on a workspace deal.
What the payer gets
The payer gets back the milestone amount plus the share of the platform fee it funded on top of it. Nothing is held back.
- The partner's fee share was never funded by the payer, so it is not part of the refund. A partner workspace is not refunded anything.
- The fee of the payment method (bank transfer, QRIS or a gateway) is not part of the refund. The payment provider kept it, so RekberPay cannot send it back.
Example. A milestone of Rp 40.000.000 on a deal where the payer carries 60% of the fee, as in Agree who pays the fee. The payer funded Rp 40.480.000, which is the milestone plus Rp 480.000 of fee share.
| Part | Amount |
|---|---|
| Milestone amount | Rp 40.000.000 |
| Payer's fee share | Rp 480.000 |
| Refund to the payer | Rp 40.480.000 |
1. The decision
A RekberPay arbitrator chooses Cancelled when it resolves the dispute. In the same step:
- The milestone becomes
cancelledand the deal's status is recalculated. - One refund is created for that milestone. There is never more than one refund per milestone, so a repeated decision cannot pay twice.
- The paying workspace gets a Dispute resolved notice. For a live deal it says RekberPay refunds the amount, "the milestone amount plus your fee share", to your verified bank account and tells you when it is sent. When the workspace has no approved bank account on file, it says RekberPay will contact you to confirm the refund account first. The partner's notice says the payer gets the amount back.
For a large amount, RekberPay's own rules require a second approver before a release or a cancellation takes effect. While that second approval is pending, nothing changes in your workspace: the milestone still reads In arbitration, the dispute SLA countdown keeps running, and no notice is sent. See Disputes on a workspace deal. The refund is created when the decision is applied.
2. Where the refund shows
In the dashboard
- On the deal, the milestone row shows Refund queued with the amount. Hover it to see the milestone amount and your fee share separately.
- The deal's side card has a Refunded line with what was already sent. While a refund is still to send, it adds that amount as pending.
- The next step line reads "Next, RekberPay refunds ... to your verified bank account".
- While any refund is open on a deal whose milestones are all closed, the deal pill reads Refund pending instead of Completed or Cancelled. The Deals list shows the same pill, so you can find these deals without opening them.
- Activity records each step. The Refund queued and Refund sent filters list them.
With the API
GET /v1/enterprise/deals/:id carries the refund on its milestone, and the totals on the deal:
{
"success": true,
"data": {
"deal": {
"status": "cancelled",
"refunded_amount": 0,
"refund_pending_amount": 40480000
},
"milestones": [
{
"id": "11111115-1111-4111-8111-111111111111",
"status": "cancelled",
"refund": {
"id": "22222221-2222-4222-8222-222222222222",
"amount": 40480000,
"principal_amount": 40000000,
"fee_amount": 480000,
"status": "queued",
"is_test": false,
"created_at": "2026-10-19T08:15:00.000Z",
"settled_at": null
}
}
]
}
}The other fields of the deal and the milestone are left out here.
refund is null on a milestone that has none. GET /v1/enterprise/deals marks each deal with refund_pending: true while a refund is still owed, which is what the Refund pending pill reads. Field details are in the deals reference.
3. Statuses
| Status | Dashboard text | Meaning |
|---|---|---|
queued | Refund queued | Created and waiting for RekberPay operations |
processing | Refund being sent | Operations are sending the bank transfer |
settled | Refunded | Sent. settled_at is set |
failed | Refund failed, retrying | The transfer did not go through. Operations send it again |
A refund moves queued, processing, settled. A failed refund goes back to queued when operations retry it. You do not need to do anything.
4. How and when it is sent
RekberPay operations send the refund by hand, as a bank transfer to the bank account on your workspace's latest approved business verification. When it is sent, they mark it settled and the bank name and the last 4 digits of the account are recorded on the refund and its event. If you change your bank account later, the record still says where this refund went.
Timing. RekberPay operations process each refund after the decision is applied, and your workspace is notified when it is sent (Refund sent) or if the transfer fails (Refund failed). A refund that stays open is followed up in RekberPay's operations queue until it is sent. Your bank may need a little longer to show the credit once it is sent.
For a large refund, RekberPay's own rules can ask a second RekberPay approver to confirm that it was sent. That step is internal and happens before the refund is marked sent.
If the bank account on your business verification is not the one that should be paid, tell your account manager before the refund is sent, as soon as you see Refund queued. See Verify your business.
5. Notifications
| Moment | Notice | Who gets it |
|---|---|---|
| Decision applied | Dispute resolved, with the refund amount | The paying workspace and, on a shared deal, the partner |
| Refund sent | Refund sent | The paying workspace |
| Refund failed | Refund failed, with the reason. It says RekberPay will send it again | The paying workspace |
Refund notices go to the deal owner and the workspace owners and admins, in the bell and, if the member turned on Email me as well, by email. Viewers never get money notices. Each member can switch Money movements off in Settings, Notifications, which also silences refund notices for them.
Events
Each step writes an event to the paying workspace's activity feed and sends it to its webhooks, in the Refunds group:
| Event | When |
|---|---|
refund.queued | The refund was created for a live milestone |
refund.processing | Operations started sending it |
refund.settled | It was sent. The sandbox writes this one straight away |
refund.failed | The transfer failed. The reason is in the event |
refund.requeued | A failed refund was queued again |
Read them with GET /v1/enterprise/events or receive them as webhooks. See Receiving webhooks and the events reference.
In the sandbox
A refund on a test deal (made in Sandbox), or on a milestone that was funded with sandbox money, never reaches RekberPay's accounts. It is created settled at once and marked as test data (is_test: true). The dashboard shows Refunded (test money), the notice says the sandbox test money is marked refunded, and operations never see it.
If something looks wrong
| You see | What to do |
|---|---|
| Refund pending longer than you can wait | Write to your account manager with the deal reference |
| Refund failed, retrying for more than a day | The notice gave a reason. Write to your account manager, and mention your bank account if the reason points to it |
| The amount is lower than the amount you paid | The payment method fee is never refunded, and the partner's fee share was never yours. Check the Refunded line against the milestone and your fee share |
| No refund on a cancelled milestone | A refund exists only when the milestone was funded. Cancelling a deal that nobody paid into moves no money |