Dev blog 17.02.2019
We have not done a devblog for a while now, but it’s not because we haven’t been working on new features.
Since our last devblog we have adopted a new way of developing GmodStore. We actively use GitLab as a means of sorting through issues and features that we want to implement/fix. We utilise the milestone system built in to GitLab to put together larger updates that we work towards.
Since the previous devblog we have released the following big updates:
These updates have yet to be covered in a dev blog. Alternatively you can view upcoming updates here, the current already released update here, and as they happen development here.
Currently we do not have a set date or a lot of features added to the next major release (V5.1) but we will talk about why later in this devblog. For now I want to go through useful features that were added lately and other interesting things.
V4.5
- The roadmap was added
- Alpha/Beta/Private updates were added to addon versions
- Support ticket quickreply variables
- Addons with DRM now must display a message saying they have DRM
- Added an Our Team page
- Blocks list
- Block reasons
- Various bug-fixes to knowledge-bases
The most notable for content creators here are the Alpha/Beta/Private updates that essentially allow you to create private versions for access by just a few people, let’s say you want to have a group of developers that will be the only ones with access to the development tools for you addon, you can do that. Or maybe you want to host a non DRM version of the addon for a few whitelisted people only? You can do that.
Support ticket quickreply variables are also very useful when utilising our ticket system’s quick-reply functionality, you can have a look at the variables here. This allows you to create better quick-replies for your addon’s support tickets.
V4.6
- Job reputation is back
- Addon’s now have a slug in the URL
- Team webhooks are here
- Reply and close for tickets
- WEBMs for addon media
- A whole bunch of bug-fixes
This update was focused on quality of life fixes, as well as a webhook system that we recommend all content creators who use external service with the API use.
Currently the webhooks support the following events that may be useful to you:
- Addon purchase
- Addon purchase revoke
- Addon purchase unrevoke
If you utilise a string replacement webhook as a replacement for “Addon purchase” but don’t actually return anything with the webhook we recommend switching to the webhooks system. Likewise if you use the API to grab purchases on a set amount of time or on a certain event.
V5.0
- V1 API is now deprecated
- Hide tickets until new activity
- About us page (GmodStore is now owned by Everyday AS)
- Block behaviour per team, content creators decide who gets to purchase their addons based on team members blocks
- Improve meta tags
- Sort active and disabled addons on profiles for a better overview
- GitLab integration for addon versions
Two interesting features I want to bring forward are the hide tickets until new activity functionality and the GitLab integration for addon versions. The former is a very useful feature for keeping your support ticket list clean if you’re a content creator. You can now reply to a ticket and immediately hit “hide until new activity” to remove it from the ticket list until a customer replies to it. This cleans up clutter.
The latter is a very useful feature we have implemented where an addon creator can link a GitLab repository to their addon, push a tag and enjoy the update being automatically deployed to GmodStore. This feature is currently missing a way to do a changelog and we are looking into that, but we think we need to bring back markdown partially for that to happen, as supplying us with a quill changelog is a big no no. You can read more about integrations here, we are also planning on bringing in GitHub integrations as well as Discord integrations.
Payment system change
One more thing we’ve changed in 5.0 that was not part of the milestone is something else we feel like we need to inform you about, both customers and content creators. This is a change we are not happy about and are actively looking into developing a solution for.
You may have noticed a change in how payments work. Previously payments worked like this:
Where the primary author of a team received the whole sum of the addon price + VAT and then automatically redistributed it to their co-creators and GmodStore (Everyday).
This was a pretty good solution for everyone, the primary author paid the PayPal fee and we got the full VAT to forward to the local governments without any issues. However, PayPal did not like this approach as it made the primary author a “fund aggregate” as they put it. This basically means that it made the primary author distribute the funds, and that is something that is against PayPal’s terms of service due to it breaking certain laws in certain areas.
We were unaware of this and we were forced to swap to this kind of a payment system:
Now the buyer sends money to several receivers, consisting of Everyday AS and all the creators of the addon you’re purchasing.
This brings in an issue for our part. We were then left with two options by PayPal:
- Buyer pays the PayPal fee
- Everyone in the parallel payment pays a part of the fee
Option 2. doesn't work for us in-case there is just two people in the parallel payment (Everyday, and one content creator) because the amount of money we receive from each transaction is very small, and it could mean that we receive only half of what we should receive, and even less if our part also contains VAT because it would mean we would have to cover the VAT out of our own pockets.
Therefore the easiest solution for that right now was to make the buyer pay the fee. We obviously don’t want our buyers to pay an additional fee on-top of VAT (if applicable) and we feel like this is unfair to customers. Therefore we have been forced to figure out a solution. And we have.
What does the future bring?
We are working on a wallet system that developers will be able to utilise. Customers will no longer pay the PayPal fee when this is implemented and the payflow will not be as confusing as there will not be several transactions for an addon, just one.
What benefits will this bring?
Positives
For the customers
- You no longer pay the PayPal fee
- We can now implement more payment options as we are not bound to using PayPal
- No more confusing multiple transactions that could give you a scare. Who is this scary Everyday AS that I’ve sent money to? (It’s us by the way, we’re not that scary. We don’t bite)
- A shopping cart. Yes you heard that right. The new system will allow us to finally implement a shopping cart. You will be able to purchase multiple addons at the same time! Hooray!
For the developers
- Way easier to do your taxes and accounting. You will now only need to file your accounting when you receive a payment from us. You will be able to choose the interval by the following parameters (or pay out whenever you hit the payout button):
- Weekly
- Bi-weekly
- Monthly
- Set date every month
- The more you have in your wallet, the less fees. Say you pay out with PayPal (which will be the only way of receiving payouts at first). Previously you would have a 3.4% + $0.3 because typically a creator doesn’t earn enough money to have lower rates. Since we would be the only receiver of money in this case we would be able to get a rate as low as 1.9% + $0.3 for each transaction. And the more you pay out at once, the less effect the $0.3 fee has.
- Of course there will now be two transactions. One when the customer buys something, and one when we pay you out. We’re sorry about that but it’s the only way we see this could work.
- We will automatically fight disputes and chargebacks for you. That’s right, automatically. We can automatically generate proof and upload it to PayPal when they ask for it.
- Any funds you pay out, will stay yours. Since you no longer have to fight chargebacks and disputes you can be sure the money we already paid out is yours to keep.
- Chargeback fees will be less for primary authors.
- A primary author will no longer take the full blow for a $20 chargeback fee if they have multiple co-authors. It will be split amongst all authors based on the amount they received in a payment. If both received $5 in a $10 payment, each of them will now get a $10 chargeback fee instead of $20 (as it stands with the current system).
- If the user bought several addons at once using the shopping cart system, the chargeback fee would be even less as it would be split amongst even more authors
Of course when we receive a dispute we will deduct the addon price from your wallet if we lost. We will only deduct whatever you received (reverse of what you were paid). You will also not be notified of a dispute or chargeback until it was already been lost or won. This is to avoid people panic withdrawing money.
Negatives
For customers
- A handling fee for a transaction may apply in certain situations (if the transaction is for a low amount and not utilising the cart system)
For the developers
- Due to there being two transactions (one when the customer purchases and one when you pay out) you will receive a tiny bit less per purchase, but with the added security of not having to fight chargebacks anymore, and being able to possibly accept multiple gateways without having to create multiple accounts for all the gateways.
- The payout fee is only 2% up to $20 (if you withdraw more than $1000 at a time you pay no more than $20)
- You will not be able to refund a purchase unless you have the sufficient funds available in your wallet. This is for a very good reason. Imagine someone just withdrew all their money from their wallet, and disabled all their addons. Then decided, hey, I’m gonna make all my addons free and then refund a bunch of people. Where do you think this money would come from? That’s right. It would come straight out of Everyday’s pocket without the author paying anything for the refunds at all. We can’t have that happen.
Keep in mind that certain parts of this plan may still be subject to change, as we have not ironed out the final details quite yet. It’s still very much in active development.
I hope we still have cleared up a lot of stuff for all of you, and we hope you will find our further development, especially about the wallet exciting!
As usual, keep replies and discussions civil.
If you want to keep up with development you may join our discord and keep an eye on the #commits channel.