Refunds
A refund goes back the way the money came. Plirin looks at how the invoice was paid and offers only the routes that exist for that payment:
| The invoice was paid | The refund goes back | What Plirin does |
|---|---|---|
| By card (through Stripe) | To the card, through Stripe. Usually 5 to 10 days to reach the customer | Sends the refund to Stripe once it is approved |
| In USDC on-chain | On-chain, to the customer’s wallet | Opens the refund workflow: the request is approved, then you send the transfer and mark it complete |
| By bank transfer, cash or check (an offline payment you recorded) | Recorded as refunded. No money moves through Plirin | Records that you paid the customer back yourself, and settles a credit note for it |
Open a paid invoice and choose Refund. The refund window lists each payment on the invoice with what is left to refund of it, and you pick the one to return. A payment that is already refunded in full, or a card payment under dispute, is shown but cannot be chosen. A partly refunded payment can be refunded again, up to what is left.
Every refund asks for a reason. A refund of invoice value also produces a credit note against the invoice, so the invoice, its PDF and your records agree about what was returned. An overpayment refund returns money the invoice never owned, so it has no credit note. The credit note reverses the invoice’s lines and VAT in proportion, and a full refund reverses every line exactly.
Card refunds
Section titled “Card refunds”A card refund is sent to Stripe when it is approved. Stripe returns the money to the customer’s card, which usually takes 5 to 10 days to show on their statement. The date on the customer’s side is up to their bank, not Plirin.
- You can refund part of a card payment, as many times as you like, up to what is left of it. The amount cannot have more decimal places than the currency allows, because Stripe refunds in the currency’s smallest unit.
- Plirin returns its own platform fee on the refunded part with the refund. Stripe’s own fees follow Stripe’s rules for refunds.
- When Stripe confirms the refund, the credit note is settled and emailed to the customer as a PDF, with your business as the reply address. The invoice’s balance moves at the same moment, and not earlier.
- If Stripe cannot complete the refund, the refund shows Failed with the reason, its credit note is voided, the invoice’s balance goes back to what it was, and you are emailed. The customer has not received that money, so refund it again or pay them another way.
Statuses
Section titled “Statuses”The dashboard shows a refund’s status in the same words on the invoice’s payment history and on the Refunds page.
| Status | What it means |
|---|---|
| Awaiting approval | The refund was requested and nobody with approval rights has approved it yet. Nothing has been sent |
| Processing at Stripe | Plirin sent the refund and Stripe accepted it. Stripe is returning the money |
| Sent to Stripe, outcome not confirmed yet | Plirin sent the refund but no answer came back, for example because Stripe could not be reached at that moment. Do not refund it again. Plirin checks with Stripe on its own, within minutes, and either finds the refund or sends it again safely. It cannot be refunded twice |
| Refunded | Stripe confirmed a card refund. The credit note is settled |
| Recorded | A refund you paid outside Plirin and recorded. It is complete as soon as it is recorded |
| Approved | An on-chain refund that was approved. You still send the transfer |
| Completed | An on-chain refund whose transfer is confirmed |
| Failed | The refund did not happen. The reason is shown next to it. The credit note is void and the balance is restored |
| Rejected | A manager or owner declined the request. Its credit note is void |
| Voided | A recorded refund that was entered by mistake and taken back (see below) |
A failed card refund shows one of these reasons:
| Reason shown | Why |
|---|---|
| The card was reported lost or stolen, or has expired or was canceled | The card issuer cannot take the money back |
| The card issuer declined the refund | The issuer refused it |
| The payment is under dispute | Stripe does not refund a payment that was charged back |
| Your Stripe balance could not cover the refund | Stripe needs funds to send a refund |
| The payment had already been refunded in Stripe | The same money was refunded directly in Stripe first |
| Stripe holds less of this payment than the refund | The amount is more than Stripe can still return |
| The refund was canceled in Stripe | Someone canceled it in the Stripe dashboard |
| The same money was already refunded in Stripe, so Plirin did not send it again | See “Refunds made directly in Stripe” below |
| Stripe refused or could not complete the refund | Any other Stripe refusal |
On-chain refunds
Section titled “On-chain refunds”A stablecoin payment is returned by the existing on-chain workflow: the refund is requested and approved, then you send the USDC from your wallet and mark the refund complete on the Refunds page with the transaction hash. Stablecoin transfers are irreversible, which is why this path keeps its approval step and its balance checks.
Plirin does not return the platform fee when you refund an on-chain payment. Plirin is non-custodial: your customer pays your wallet directly and the platform fee is split on-chain when the payment settles. There is no held balance to take it back from, so returning it would mean a separate transfer rather than an accounting entry. Refunding a payment never creates a new fee either: you are charged once, on the original payment.
Plan an expected refund rate into your pricing the same way you would with any other processor. A card refund differs here, and returns the platform fee on the refunded part (see above).
A payer’s wallet is needed to refund on-chain. If Plirin has no wallet on record for the payer, it says so and nothing is written.
Recorded refunds
Section titled “Recorded refunds”When a customer paid by bank transfer, cash or check, and you pay them back the same way, record the refund in Plirin. No money moves through Plirin. The record keeps your invoice, credit note and books in step with what you did outside.
Choose Refund, pick the offline payment, and enter:
- the amount (up to what is left of that payment),
- the method you used to pay it back (bank transfer, cash, card, check or other),
- the date, which is today unless you say otherwise, and cannot be in the future,
- an optional reference, such as a bank transfer ID, up to 100 characters,
- the reason.
The refund is Recorded at once. It needs no approval, because you have already paid the money. Plirin settles a credit note for it and emails the credit note to the customer, if the invoice has an email address, because the money has already reached them.
Only the owner and managers can record a refund (it needs permission to manage invoices). A recorded refund is allowed on a paid invoice.
Voiding a recorded refund. If you recorded one by mistake, void it from the invoice’s payment history with a reason. The credit note is voided with it and the balance is restored. The customer, who was emailed that credit note when you recorded the refund, is emailed once that it no longer applies (your reason is not included). Plirin refuses the void if it would leave the paid invoice owing money. A recorded refund is the only kind that can be voided: a card refund that went to Stripe cannot be taken back here, and an on-chain one is a transfer that already happened.
A payment that has a recorded refund against it cannot be removed. Void the recorded refund first.
Overpayments
Section titled “Overpayments”An invoice can receive more than its total, for example when a customer pays by card while an on-chain payment is still processing, or two payments land together. The excess is not invoice value, so returning it does not create a credit note and does not reduce the invoice. It is a refund of money you should not be holding.
When an invoice is overpaid, Refund opens on Refund overpayment, with the excess filled in. The amount is capped at the smaller of the excess still to return and what is left of the chosen payment, and refunds of the excess that are already on their way count against it. The refund then follows the payment’s own rail:
- A card overpayment refund is created awaiting approval and goes to Stripe when approved, exactly like any card refund.
- An offline overpayment is recorded at once.
- An on-chain overpayment follows the on-chain workflow.
If the invoice is not overpaid, Plirin says so rather than refunding. A card payment that arrived after an invoice was voided is a different case: the money is in your Stripe account and Plirin records that it needs refunding (an audit entry says so), but it is not an overpayment of a live invoice.
Request, then approve
Section titled “Request, then approve”Not everyone can send money back. Plirin separates asking from approving, and the roles work like this:
| Role | Request a refund | Approve a refund | Record an offline refund |
|---|---|---|---|
| Owner | Yes | Yes, any amount | Yes |
| Manager | Yes | Yes, up to the manager approval limit | Yes |
| Cashier | Card and on-chain refunds | No | No |
- A cashier requests a refund, and it waits as Awaiting approval with its credit note. Nothing is sent to Stripe until someone with approval rights approves it.
- For a card refund, an owner, or a manager within the limit, gets Refund now. It requests and approves in one step, and the refund goes straight to Stripe. An on-chain refund is always a request: even an owner sees Request refund, and approves it from the Refunds page before sending the transfer.
- A manager is subject to an approval limit per currency, currently 100.00 in USD and in EUR, and the same 100.00 for any other currency. Above it, Plirin tells the manager so and the button becomes Request refund, to wait for an owner.
- Approve and Reject are on the refund’s details on the Refunds page. Approving a card refund sends it to Stripe and shows the outcome. Rejecting voids its credit note and leaves the invoice paid.
If Stripe is unreachable at the moment of approval and Plirin knows the request never left, the refund goes back to Awaiting approval and can be approved again. Plirin never sends the same refund to Stripe twice.
Refunds made directly in Stripe
Section titled “Refunds made directly in Stripe”You can also refund a card payment from your own Stripe dashboard. Plirin picks it up automatically from Stripe’s notification, with no action from you:
- The refund appears on the invoice and on the Refunds page, marked as a card refund. Its status is Processing at Stripe until Stripe confirms it, and Refunded after.
- When it returns invoice value, Plirin creates the credit note itself and, once the refund is confirmed, emails it to the customer, the same as a refund made in Plirin.
- If part of what you refunded was an overpayment, only the rest becomes a credit note.
If credit notes already claim the room, you are told. Suppose you drafted a credit note, or have a refund request waiting, for the same money, and then refunded it in Stripe. Stripe’s refund is money that has really moved, so Plirin records it in full and credits as much as the invoice still allows. The invoice’s balance stays right, and a paid invoice does not suddenly owe money for a refund your customer received. Plirin emails you what happened: how much was credited, how much is left to pay, and that the draft or the pending request describing the same refund should be voided or rejected, or it can no longer be issued. Until you do, Plirin refuses to approve that pending request, so the money cannot go back twice.
Partial refunds and the refundable balance
Section titled “Partial refunds and the refundable balance”A payment can be refunded more than once, up to the amount originally paid. Plirin tracks a running total of what has been returned against each payment, and the refundable amount is the original amount minus that total, minus any refund still in flight.
A refund for more than what is left is rejected, and the message says what is actually available. A payment can be refunded to exactly zero remaining, but never past it.
The check is made when the refund is requested and again when it completes, against a locked row. Two refunds submitted at the same time cannot both consume the same balance: one completes and the other is rejected with the updated figure. For an on-chain payment, the database itself enforces this, because a transfer cannot be undone.
Disputes
Section titled “Disputes”A card payment can be charged back. A stablecoin payment cannot. For what happens when a customer disputes a card payment, including why refunds are blocked while one is open, see Disputes.