Skip to main content

​
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 100onacardplus100 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. 
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. 
{
  "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.