do_refund: true creates the refund for you and leaves the customer with a document explaining why. Create a refund directly only when no credit note is needed. See How Alguna Works for how payments, invoices, and corrections relate.
Statuses
Settlement to the customer’s card or account takes as long as the provider and rail need — typically several business days for cards. The
refund.updated webhook fires on each status change.
What happens to a paid invoice
Nothing. Refunding does not change the invoice’s status, and there is norefunded invoice status — an invoice is draft, upcoming, pending_approval, scheduled, processing, issued, paid, overdue, void or canceled, and one that was paid and then refunded stays paid. This is deliberate: the invoice is the record of what was billed and that it was settled at the time, and reversing it later does not make that untrue.
The reversal is recorded elsewhere, and which record you create decides what the books show:
A duplicate charge or a payment taken in error is the first row. A wrong price, an overcharge or a cancelled service is the second — reach for the credit note, because a bare refund leaves the invoice claiming revenue you have given back. Voiding is not an option once the invoice is paid:
POST /invoices/{id}/void returns 400 for any status other than issued or overdue. Issue a credit note against it instead.
Because the invoice stays
paid, “which of my paid invoices have been refunded?” is a question about refunds, not invoices: list refunds and match them to invoices through their payments. See Read refunds.Refund through a credit note
Credit the invoice, then apply the credit note with a refund. The refund amount is the credit note total, and the credit note recordslast_refund_id. Full walkthrough on Credit Notes.
refund_destination can also be wallet (with wallet_id) to return the money to a prepaid wallet instead of the card.
Create a refund directly
POST /refunds refunds part or all of a payment. payment_id and amount are required; reason is stored on the refund, and statement_descriptor is the text the customer sees on their statement. See Create a refund.
GET /payments?invoice_id=… or ?customer_id=…; each payment reports amount_received and amount_refunded, so amount_received - amount_refunded is what is still refundable. See Invoicing Customers.
Partial refunds
Several partial refunds can be made against the same payment, up to the amount received:Read refunds
GET /refunds filters on customer_id, payment_id, status (comma-separated), and currency; GET /refunds/{id} returns one. Each refund carries payment_id, customer_id, amount, currency, reason, failure_reason, and the provider references external_id, external_url, and processor_id.
Failed refunds
A refund fails when the provider cannot return the money — the original card is closed, the account no longer exists, or the provider reports an error. The refund staysfailed with the provider’s failure_reason; it is not retried automatically. Your options are to create a new refund once the underlying problem is fixed, or to apply the credit note to a wallet so the customer can use the balance against future invoices.
In the dashboard
- Payments lists every payment and, in its Refunds tab, every refund with its status. Open a payment and choose Refund to refund it directly, entering an amount and a reason.
- On an invoice, Create Credit Note starts the credit-note route; when you apply the credit note to a paid invoice you pick Refund to payment method, Refund offline, or a wallet.
- Refunds can be exported from the Payments page; see Data Exports.
Webhooks
Payloads are camelCase. See Webhooks.
Next steps
Credit Notes
The document that should accompany most refunds.
Invoicing Customers
Payments, AutoPay, and payment methods.
Surcharges
How a surcharge collected with a payment is reversed on refund.