Today, a discussion about if or how a full refund of a purchase could be achieved on an advanced version of TWM in the future emerged in the Discord.
Since a 5% fee is always immediately distributed to the locked SFT pool, a full refund of a product is not possible unless the seller pays the remaining 5% back from his own pocket.
A possibility would be that the ‘pool fee SFX’ can not be paid out immediately via the unlock SFT command but are reserved for the limited refund time of X blocks. In case of a refund, the pool fee could be paid back to the buyer of the product (the buyer could somehow claim back his shares of SFX out of the pool with his key, after the refund with the seller is settled). After the limited refund time is over, the reserved pool SFX would finally become available for the original SFT holders, who had their tokens locked in at the time of purchase, when unlocking their tokens - at the same time, the original buyer could not claim them back from the pool anymore. What does the community think about this idea?
First question is if anyone can think of a way to abuse this.
What sort of refund time did you think reasonable? Our laws allow for the basic time of the warranty period and in some cases the lifetime of the product.
Things like
lemon laws where if say a car breaks 3 times due to manufacturing fault then refund is possible. Obviously as time progresses it becomes exponentially more difficult to show manufacturing fault after the warranty period of 3-7 years.
Our laws allow for full refund if product is not as advertised and this too does not have a time limit but reasonable to assume that nigh on impossible to get after the warranty period
The key is the warranty period with some big ticket items having warranty periods of up to 10 years, thus any reserved period is too long.
I would like to suggest an alternative system that while might seem a little more complex should be able to handle the issues so sellers, buyers and locked in token holders are happy with it.
EDIT: I am referring to the refunding of fees only. Refunds of the rest is the seller’s responsibility
A portion of the fee is held in a pool that rolls over period to period.
refunds are paid out from pool
if pool does not have enough resources then the portion held from future purchases is increased
automatically would be good with appropriate damping so one very large refund does not cause a huge increase
refunds are delayed until pool has enough funds
Effectively the pool is handling all the refunds and since a refund is never owed to the locked in token holders they cannot really complain it is being held aside.
the issues arise if too much or too little is being held. Hopefully adjusted automatically (or if needed a manual adjustment by some governance system) will maintain a healthy pool for future refunds.
the sellers and buyers are not affected since it is only a portion of the fees being held back which they pay anyhow its no different to them
The locked in token holders have to realise that it is a necessary part to offer refunds or else people will not use the system as much. In other words it is an overall benefit to the whole system like insurance is to people.
Maybe sell or explain it as refund insurance being funded by say a %age of fees. If 2% of fees then 4.9% of transaction goes to locked in token holders and 0.1% to pool
Issues of the pool growing too much, the system collects less each month till pool reduces
optimal pool size could be based on an average of sales and refunds with later months influencing it more. Would expect the last 6 months of sales to have the most effect. Rather like a rolling average.
This allows the locked in token holders to be paid their portion at the end of the period without any delays, without any need to keep extra history on the locked in token holders.
Looking back this is a lot like insurance but a non-profit insurance plan funded from the fees themselves.
EDIT: to be sure I am only referring to the refunding of fees by the system, the seller is responsible for refunding the rest.
Very nice input, Rob! It may be harder to implement, but this “auto-adjusting side pool” for refunds is a really great idea. In case of an expired refund time, would the fees be paid out directly from this second pool or move to the original pool first?
No idea, I was thinking either there is one refund time for all products automatically, or every seller can adjust it individually for themselves. There may also be sellers then who do not offer the “full refund option” at all or pay the 5% from their own pocket if they are generous.
The refund time would be dictated by the law or the seller offering that period of time.
The side pool as you called it is one created from the fees. So the fees are split.
Sorry for not remembering this important point but aren’t the fees already split with a portion going to locked token holder each period and to the dev team for future developments? For this description I am assuming so.
The fees from the transaction is 5% from what i gather in your topic post. So in the following explanation I am only talking of the fees not the transaction
let X% be the planned %age of fees to dev team for future development
let Y% be the planned %age of the fees to the locked in token holders
let Z% be the %age of the fees charged to cover refunded fee amounts.
refund fees pool (your side pool)
There is no fee refunds from anywhere other than the refund fess pool.
Now X% and Y% is for the fee amounts left after Z% has been removed and placed in the refund fees pool
Thus if we let Z=2% to start things off then the fess left is 98% * fees taken and 2% * fees taken is stored in the refund fees pool.
Thus at end of the period
The devs get X% * (1-Z%) * fees taken
and locked in token holders get Y% * (1-Z%) * fees taken
If refund fees pool at the end of the period is below the desired amount then Z% is increased for the next period. The increase is determined using a formula that doesn’t cause massive jumps but enough to slowly increase the amount in the pool.
And the opposite if refund fees pool is too large
The desired size of the refund fees pool is a %age of the rolling average of transactions since there is less chance of older transactions attracting a refund.
This is most like an insurance system to pay fee refunds and effectively every transaction contributes a little bit to it.
Z% adjusts so that the refund fees pool is a percentage of the rolling average of total sales transactions.
I think it should be a 30 day refund window. So as soon as someone bought something, the 5% fee will go into a pool where it stays for 30 days.
In those 30 days, buyer and seller have time to complete the transaction. The seller can open a refund request during that time period but the seller has to accept it.
If the seller accepts it, than the buyer will get the 5% back.
If the seller doesnt accept it, than the buyer wont get it and can leave a feedback.
The laws in every country shouldn’t be the problem of safex. It should be the problem of the sellers. They have to be sure that they are doing nothing illegal and provide the law given refund times, even if they go beyond the 30 days safex window.
The 30 day pool would mean that divs from day 1 would be distributed on day 31, divs on day 60 on day 90, so basically divs from day x would be distributed on day x+30.
My suggestion does not require the network to know the laws nor any aspect of them. It only requires the seller to be refunding the transaction.
Yes the refund within the cycle/period used for rewarding locked in token holders can work and is a simpler way.
The only issue I can see with that is that either the seller has to return the 5% fee taken if the seller is required by law to refund. Or if seller nicely agrees to refund transaction then its up to the seller and purchaser to agree what happens with the 5% fee if done after the network refund time frame
It’s a very clever concept you’ve proposed @Rob, thank you for that.
Would be a bit more development time than some standard system; however, this really addresses the issue totally.
Something that came to mind as well regarding credit cards:
How Does the Provider Handle Customer Refunds?
You must know how the provider handles a credit refund transaction. This is especially important for ecommerce merchants since they typically initiate more refunds than brick-and-mortar businesses. When you credit your customer, the interchange fee — the largest part of the processing fee — is refunded back to the provider.
Some providers return the refunded interchange to the merchant and only charge a small fee to route the refund. Some providers keep the interchange and charge a transaction fee. And some not only keep the interchange but also charge the merchant an additional processing fee and transaction fee on the refund. The difference in these three ways of handling refunds can have a large impact on your cost. Say you had $10,000 in credit card refunds and each refund was for $100. The first refund method shouldn’t cost you more than $20. The second method would cost you around $250. The third method would cost you around $500. This cost is even more significant when you consider that you made $0 in actual sales.
-took from >https://www.practicalecommerce.com/Beware-Credit-Card-Processing-Fees-Especially-Refunds
The merchant can be on the line for refund charges to the card provider.
I think that we’ve discovered more than reasonable ways (and can continue to add) to fix this and make all people whole in most cases.
As far as I remember, this idea was ditched for the sake of decentralization. There will be no automated fee split to a development fund address (Dan correct me if I’m wrong) so we only need Y% and Z% in your approach.
What now comes into my mind: How will buyers/sellers agree on an amount of refunded SFX? If SFX price goes down during refund time window, the buyer might want to get back a higher SFX amount (fiat pegged) so the amount of fiat he paid is covered - but this is another topic…
But The 5% isn’t it taken from the sellers profit side of things, like it’s what is demanded for profiting from the market…
The sellers usually even (sometimes) bump up the price 5% to cover that cost.
In so doing transfers the burden on the buyers.
Just like when the Gov increases taxes on gas and we the buyer have to pay more.
Exp; a business has a store, and to run the store it needs to pay electricity.
Now that electricity bill is the store owner’s responsibility !
What does a customer who needs a refund have to do whit that ?
Now a price was determined by the seller, and paid by the buyer.
IMO it falls on the seller to payback.
Just my two cents.
That being said, it as noting to do with a time limit for a buyer to be able to ask for a refund.
I would think that the SFX is the base for value. So refund is the amount of SFX paid. In the future fiat maybe only for non digital purchases and compared to crypto or SFX
In my understanding then the refund API would then also return the correct amount of fees paid. Thus if the seller refunds 50% then the buyer receives 50% of what they paid. 47.5% comes from seller and 2.5% comes from the refund fees pool
I’d like to see refund timeline started on confirmed order receipt from both parties and not be an option before that. There’s too much fraud potential out the bat.
It’s going to be something that should require government id to prevent fraud, too. Otherwise I can coordinate with my friend on my 1m sfx purchase which I received but want a refund! Etc. There’s no way you can trust entirely with validation of the individual.
Having a pool to handle refunds is also ideal, but there needs to be a cap on pool % for a refund, like 10%.
We also need to consider feedback in the equation. If I sent a refund, usually it means something positive. The more I think of it, we could also consider the refund element as part of an escrow system.
To the point that someone will buy something, then issue a refund to save the fee doesn’t make much sense because in that case, you should simply contact your seller and settle off system.
Overall I think that with the combination sellers increasing their prices as a default reaction to any costs is usual like on amazon, or even in person shops (due to credit card processing fees)
And the clever idea of a refund pool, which would give us a window of opportunity to enable returns.
We still need to take into account feedback and how that would fit in. Normally you give a positive reply to a merchant who gave you a refund. Perhaps monitoring for if a refund was given to give less weight to the rating when displaying information about merchants’ ratings.
After thinking about this for a second time, it makes much sense that this would not only be the easiest way to solve this “problem” but also would come with an advantage for the sellers.
Imagine a seller wants to fund the 5% fee refund on top of the basis refund out of his own pockets. If he expects at most 10% refunds, he only has to increase the product prices by 0.5% to cover the costs. In addition, he will set himself apart from other sellers, when he actually offers this “full-refund” option and also has got ratings to prove this. Sellers could also put in their product- or account-description, whether they offer the regular 95% refund or the full 100% refund (5% funded by themselves).
In that way, each seller could decide for himself what options he wants to offer and each buyer can decide for the offer that fits him best (partly refund option at a discounted price or full refund option at a slightly higher price, depending on the seller). The safex ecosystem would probably benefit from this solution, because it takes away code complexity from the revenue stake and payout system. It would also go more hand in hand with the free-market-idea of Safex (sellers and buyers decide and agree for themselves on refund options -> rating system manifests those agreements).
I was going to suggest this earlier, but reading the comments above it seemed too simple. After all we are supplying a service to sell a product not producing the product, dose the packaging company or courier, return funds. I don’t think so