opencollective
Who should pay for payment processor fees lost in refunds?
Today, when we refund a transaction but the payment processor fees do not get refunded there can be two approaches based on the context:
-
The host covers the lost fees. That's the most common situation. Basically, we refund the full amount, and any processor fees lost in the process are marked as a DEBIT to the host.
-
The collective covers the lost fees. This is only used for expenses when fees are put on the payee.
| Type | Fees payer | Example | Who "pays" for the lost fees | Collective balance (after the refund) | Host balance (after the refund) |
|---|---|---|---|---|---|
| Contribution | - | Babel refunds a $100 contribution that included $10 fees (not refunded).
Amount paid by the contributor: $100 Net amount initially received by Babel: $90 Net amount refunded by Stripe: $90 Amount lost in fees: $10 | The Host (OSC) | $0 | -$10 (because the host contributes from their own budget to Babel to cover the fees for them) |
| Expense | Collective | The payment for a $100 expense on Babel that included $10 fees gets refunded.
Amount received by the payee: $100 Net amount paid by Babel: $110 Net amount refunded by Transferwise: $100 Amount lost in fees: $10 |
The Host (OSC) | $110 | -$10 (because the host contributes from their own budget to Babel to cover the fees for them) |
| Expense | Payee | The payment for a $100 expense on Babel that included $10 fees that were paid by the payee gets refunded.
Amount received by the payee: $90 Net amount paid by Babel: $100 Net amount refunded by Transferwise: $90 Amount lost in fees: $10 |
The Collective (Babel) | $90 | $0 |
Questions
- Are we happy with these?
- Should we try to make things more consistent?
- Do we want to make this customizable, i.e. add a select on the refund modal like
Who should assume the lost fees?- The contributor / Payee
- The collective
- The fiscal host
@Betree : Thanks much for summarizing this. Still trying to get around all the details here. Now one thing I am thinking (if my understanding is correct) is that in the ledger we only use the PAYMENT_PROCESSOR_COVER when the host covers the fee right? When the collective covers the fee the "cover" is implicit. I feel that it's nicer if we could make this explicit for both cases. This probably makes things more consistent. 🤔
@SudharakaP This issue is not about the technical implementation, it's about discussing the responsibility of who should pay the fee in general. Happy to discuss this topic with you, but here's not the right place to do it.
To me it makes very little sense that the fiscal host would cover the fee. The host's job is to handle the funds, it is not to get otherwise involved in the economy of the collective it hosts.
To put it differently, why does the fiscal host cover the fee in case of refunds but not cover the fee when the transaction is kept? This is inconsistent.
As such I would expect default behaviour to be that when a transaction comes in via for example Stripe, the transaction fee is deducted. This is current behaviour. Likewise, when that transaction is reversed or refunded (depends on the timing) I would expect the collective to be handed over exactly as much as what Stripe hands back to the fiscal host. No more, no less. If Stripe returns the fee, so should the fiscal host. If Stripe keeps the fee, so should the fiscal host. Keeping the fiscal host at zero difference.
Why? Because the cost of doing business belongs with the collective doing the business.
It seems arbitrary to me that the fiscal host would cover this particular fee. There are many other transactions with fees involved that do not get covered whether they are reversed/refunded or not. This just comes up because Stripe specifies it separately.
As for behaviour going forward I would prefer this to be default behaviour but I can see the value in making it customisable in an options menu somewhere. If it were customisable I would still default it to what I have suggested here, for the reasons I give here.
As for which Kind, I believe it should be consistent so that the transaction is a PAYMENT_PROCESSOR_FEE regardless of direction. Marking it as a REFUND is sufficient to tell us what happened. Just like a CONTRIBUTION is that regardless if it is incoming or being refunded. In other words I think PAYMENT_PROCESSOR_COVER is a redundant Kind and can be removed.
@relicarious Thank you for the feedback.
cc @iamronen, you may be interested in this discussion about inconsistent payment processor fees/refund policies.
@relicarious thank you indeed for the feedback.
- You are making some assertions about what is fiscal hosting and the nature of the relationship with collectives. There is no hard truth here. Different hosts have different views on this. I understand your position.
- The choice to cover refund fees is therefore an opinionated preference that was established by the hosts that contributed most to the shaping of the platform.
- The term and implications of fiscal hosting are not obvious to many (perhaps even most) people. Many users arrive at the platform and establish collectives without an understanding of what fiscal hosting means, what payment processors are and what fees are involved. They go through a learning curve. Host admins (especially of smaller hosts) also go through a similar and even more complex learning curve. Refunds and disputes are advanced concepts (even fiscal host admins may not initially be familiar with them until they first encounter them) and collectives may never want/need to understand these concepts (and the accounting implications).
- Hosts choosing to cover these fees is therefore both a pragmatic and gracious (generous) choice they made.
- There is an edge-case which likely also contributed to this decision. If a collective has a zero balance and a $10 contribution is made, of which $1 was a payment processor fee. The collective only receives $9. If that contribution is refunded and the collective would carry the fee it would end up in a negative balance. This is something we do not allow (which is another explicit choice). Hosts covering the fees bypasses this potential problem.
@iamronen thank you for this explanation. I see that I was unaware of these perspectives.
I agree that the assertions are mine and not hard truth. It is simply how I expect a fiscal host to conceptually make sense. I find it arbitrary that it would cover some fees while others it would not. When we gather membership payments for our event we will be purchasing a number of things that can be partially used and the remains returned for a refund. All handling fees of these items would very naturally be paid by the event as they are tied to the execution of said event. Same as the card fees.
I think you hit the nail on the head with your description of learning curves and complexity. I came to this platform having already interfaced with card transactions systems a good 15 years ago. :-)
As such I am blind to the distinction that of course a collective may not be as tech savvy and will rely on the fiscal host to make things easy for them. I fully agree with your point 4 that covering the fee is a gracious and generous choice to make. One that I obviously disagree with though I now can see more clearly the case for making it a choice. <3
I do wonder about the edge case you mention. As I do not know the original reason for disallowing negative collective balances I can only speculate from how I would have expected it to work.
If we want to enforce a non-negative balance then I would expect that refunds can only be approved if there is cover for them in the balance. This would force a collective to add funds in order to process the edge case. Unless of course the fiscal host generously decides to cover the difference. This easily makes sense for hosts that charge fees for their services and thus have an income with which to cover such things and makes less sense in my own scenario where we run a collaborative volunteer organisation with no profit involved and no base economy to absorb small change transactions like this. Then again, if I find myself in a situation where we would have to refund all our members I would probably find a way to even the fee costs across everyone and batch run a reimbursement process via Wise. Case closed. :-)
What would happen if it was a choice on the part of the fiscal host to allow negative balance to a certain amount? I can see how this could become a question of who is liable for covering if something breaks down between collective and host. But how often would this be an actual issue worth enough money to be bothered by it? On the other hand I do not find it fruitful to design for imagined conflict when a trust-based approach could establish a culture that opens new possibilities.
So I think my proposal would be that a fiscal host has a choice of whether it covers the edge case fee or blocks the refund. And a choice of whether it allows a negative balance and to what amount.
Though I really have no horse in that particular edge case race, I am just spitballing here.
Is there a summary somewhere that explains the reasoning behind enforcing non-negative balances?
And hey, thank you for your time and attention on this, it is very much appreciated. My immediate problem has been solved via manual reimbursement so my engagement here is because I love it when things are consistent and sense-making, so thank you again for explaining.