When a customer gets a full refund, they get their full purchase price back. But due to non-refundable payment processing fees, your business often loses money on the transaction, receiving less than zero net revenue.

You Hit ‘Full Refund’. So Why Are You Losing Money?

I remember the call. 2 AM. A junior engineer, bless his heart, had just pushed a “simple” change to our refund module. By morning, our finance team was seeing red—literally. For every $100 refund we processed, our bank account was dropping by about $103. A tiny logic bomb, detonated a thousand times an hour. We were hemorrhaging cash because of a fundamental misunderstanding of how money moves on the internet. It’s a rite of passage, I guess, but one that can cost you dearly if you’re not prepared.

The “Why”: You Never Had the Full Amount in the First Place

This whole mess boils down to one simple, often overlooked, truth: the amount a customer pays is not the amount you receive. In between sits the payment processor (think Stripe, PayPal, Adyen), and they take their cut before the money ever hits your account.

Let’s break down a typical $100 transaction:

• Customer pays: $100.00
• Stripe’s fee (e.g., 2.9% + $0.30): $3.20
• Money deposited into your account: $96.80

Now, the customer requests a “full refund.” Your system, in its innocent brilliance, sees the original transaction amount—$100.00—and dutifully sends that back to the customer. But here’s the kicker: most payment processors do not refund their original processing fee. So, you’re sending back $100.00 from your account, which only ever received $96.80 for that transaction. You’ve just lost $3.20. Some processors even charge an additional small fee for the refund transaction itself!

Pro Tip from the Trenches: This is a finance and accounting problem masquerading as a simple engineering task. Your code needs to reflect the reality of your cash flow, not just the customer-facing price tag. And for the love of all that is holy, NEVER store monetary values as floating-point numbers. Use integers and store cents, or use a dedicated Decimal type.

Fixing the Ledger: Three Levels of Response

Depending on how bad the fire is, you have a few ways to tackle this. I’ve used all three at various points in my career, from panicked late-night hotfixes to long-term architectural overhauls.

1. The Quick & Dirty Fix: Manual DB Intervention

It’s 3 AM, the finance department is breathing down your neck, and you just need to stop the bleeding. This is not the time for elegant code. This is the time for a direct, surgical database patch. You need to manually adjust the ledger for a specific, problematic refund.

Let’s say a refund with `transaction_id = ‘txn_123abc’` was processed incorrectly. You need to create a manual adjustment in your ledger to account for the lost fee.

-- WARNING: This is a last resort! Always back up data before manual changes.
-- Goal: Add a manual adjustment to account for the non-refundable processor fee.

INSERT INTO financial_adjustments (reason, amount_cents, associated_transaction_id, notes)
VALUES ('COST_OF_REFUND', -320, 'txn_123abc', 'Manual entry by D. Vance on 2023-10-27 to correct for non-refundable Stripe fee on full refund.');

Is it hacky? Absolutely. Is it logged and auditable? Yes. Does it stop the immediate financial panic? Yes. Use it to buy yourself time to implement a real solution.

2. The Permanent Fix: Architecting for Reality

The real, long-term solution is to make your application’s data model reflect financial reality. Stop thinking of a transaction as a single number. It’s a collection of movements.

Your `transactions` table needs more context. Instead of just `amount`, you should be storing the gross, the fees, and the net.

When you build your refund logic, it should be clear what’s happening. The customer is refunded the `gross_amount_cents`, but your internal accounting records the `net_amount_cents` plus the `fee_amount_cents` as the total cost of the refund transaction.

Here’s some pseudo-code for what that looks like in the application layer:

function processRefund(originalTransaction) {
    // 1. Initiate refund with the payment processor for the full gross amount
    let refundResult = PaymentProcessor.refund(originalTransaction.processor_id, originalTransaction.gross_amount_cents);

    if (refundResult.isSuccessful) {
        // 2. The customer gets their full money back. This is non-negotiable.
        let customerRefundAmount = originalTransaction.gross_amount_cents;

        // 3. Record the true cost to the business in our own ledger
        let costToBusiness = originalTransaction.fee_amount_cents; // The fee we lost
        
        // Some processors might add a refund fee, add that here if applicable
        // costToBusiness += refundResult.refund_fee;

        // 4. Update our internal records
        db.transactions.update(originalTransaction.id, { status: 'refunded' });
        db.ledger.createEntry({
            type: 'refund',
            amount: -customerRefundAmount, // Money out to customer
            notes: 'Full refund to customer.'
        });
        db.ledger.createEntry({
            type: 'cost_of_goods_sold',
            amount: -costToBusiness, // The fee is a business expense
            notes: 'Non-refundable processor fee.'
        });
    }
}

This approach correctly separates the customer experience (getting a full refund) from the business reality (incurring a small loss).

3. The ‘Nuclear’ Option: Offload to a Ledger Service

Sometimes, this problem is a symptom of a much larger disease: you’re trying to build a complex financial system from scratch. After a certain scale, rolling your own ledger is a recipe for pain. The regulations, edge cases, and reporting requirements become a full-time job.

This is when you bring in the heavy hitters. You either build a dedicated internal microservice whose only job is to be an immutable ledger, or you use a third-party service. This service becomes the “source of truth” for all monetary transactions.

Your e-commerce app tells the Ledger Service, “A sale of $100 happened.” The Ledger Service records the sale, the fees, and the net. When a refund happens, your app tells the service, “Refund transaction X.” The service handles the double-entry bookkeeping to mark the refund to the customer and the loss of the fee internally.

This is the most complex option, but it’s the one that scales. It ensures that no matter how many services you have touching transactions, there is one, and only one, source of financial truth. It separates the “money” concern from your “product” concerns.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions