> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcuserp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Refund Routing

> How refunds are allocated across the payment sources that paid an invoice, including multi-source splits.

## The operator picks the source

When an invoice was paid with a single payment method, a refund routes back to that method automatically. When an invoice was paid with **multiple payment sources** (for example $100 on a card plus $100 by check), Arcus does not guess which source to refund. The operator decides how to split the refund across the original sources.

This matches the industry standard. Stripe's partial-refund guidance and NetSuite's customer-return refund flow both have the merchant explicitly choose which charge or payment a refund draws from. There is no automatic proportional routing.

## Multi-source refund allocations

To split a refund across payment sources, supply an `allocations` array on the refund request. Each allocation names an `order_payments.id` from the invoice's original order and the dollar amount to refund against it.

```bash theme={null}
curl -X POST https://api.arcuserp.com/v1/entities/$ARCUS_ENTITY_ID/returns/$RMA_ID/refund \
  -H "Authorization: Bearer $ARCUS_API_KEY" \
  -H "Idempotency-Key: 7f3b2c4d-1e5a-4f9b-8c2d-0a1b3c5d7e9f" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 150.00,
    "allocations": [
      { "payment_id": "11111111-1111-1111-1111-111111111111", "amount": 100.00 },
      { "payment_id": "22222222-2222-2222-2222-222222222222", "amount": 50.00 }
    ]
  }'
```

### Rules

* Every `payment_id` must belong to the same order as the RMA's original invoice.
* `SUM(allocations[].amount)` must equal the total refund (`amount`) within one cent.
* Each allocation must not exceed that source's remaining refundable amount (`payment.amount - payment.refund_amount`).
* All allocations are processed inside a single transaction. If any allocation fails, the entire refund is rolled back. Nothing partial is ever recorded.

### What you get back

A multi-source refund returns `payment_method_type: "multi_source"`, a single GL `batch_id` that groups every per-allocation journal entry, and an `allocations[]` array with the per-source result rows.

```json theme={null}
{
  "data": {
    "return_id": "...",
    "amount": 150.00,
    "payment_method_type": "multi_source",
    "batch_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
    "allocations": [
      { "payment_id": "1111...", "source_method": "credit_card", "amount": 100.00, "order_refund_id": "..." },
      { "payment_id": "2222...", "source_method": "check", "amount": 50.00, "order_refund_id": "..." }
    ],
    "status": "succeeded"
  }
}
```

## Card processing fees are not refunded

When a refund allocation draws from a card source, the customer receives the allocated amount, but the original card-processing fee charged at sale time is not recovered. This is the standard behavior for card networks and Stripe: the processing fee on the original charge is non-refundable. Arcus surfaces a non-returnable-processing-fee disclaimer in the refund UI whenever a card source is part of the split.

## Single-source refunds

If you do not supply `allocations`, the refund routes to a single source using the `payment_method` field (`original`, `store_credit`, `check`, or `cash`). This is the simplest path for invoices paid by one method.

## Related

* [Idempotency](/concepts/idempotency) - safely retry a refund without double-refunding.
* [General Ledger Fundamentals](/guides/general-ledger-fundamentals) - how refund journal entries post.