Originally, it started off as Aditya and I throwing ideas off each other till we arrived at Discord bots. Aditya noticed specifically that there was a, questionably, lucrative market in the sale and exchange of gaming accounts for games like League of Legends, Overwatch, Smite etc. We looked into this and concluded that the service and accountability aspect was very lacking - the architecture was primative and literally based on strangers agreeing to pay and provide goods/services through "word-of-chat". Aditya and Tony designed a system to counteract this problem and provide stable central functionality that is widespread on other popular platforms. We know that the large percentage of the Discord user-base is comprised of "gamers" and introducing a method for Server owners to leverage their member-base whilst allowing members to stay on their platform of choice aids both sides. They will most likely use Discord for chatting in the first place, so working on a Discord bot, by extension seemed like the best option.
What it does
Our bot is an E-Commerce Point Of Sale Chat Bot. It provides functionality for the Discord "servers" (guilds) to securely transfer payments from one user (role = member) to another user (role = vendor) via PayPal. We act as a middleman for this transaction in order to provide a guaranteed, risk-averse payment solution for both parties. In this manner, the payment will first be collected by us, confirmed, processed and approved with receipt. Then the password associated with the Account is released to the buyer by matching the buyer's desired account username with the string values in our collection.
How we built it
We first used DV8FromTheWorld's JDA Version 3.8.3 from GitHub as a major dependency to write our project in. It started as a basic bot with only a "!hello" command that was later refactored to fit our purposes. We added 2 utility classes, Account and LeagueOfLegendsAccount (These two are for demo purposes, adding different games or reducing functionality simply requires one to change names and variable in limited cases (about 10 second fix)), that would serve as our examples. The bot parses user data into those objects and stores them in a Collection. Later, we use Integromat for directives, a service that provides a secondary bot user that can respond to webhooks. Our bot is able to solely communicate with the other bots and force triggers (demoed via Integromat), allowing us to tailor specific message triggers we wanted ("%order" was used for the demo). Upon successful triggers, the Integromat bot sends a PayPal payment link where the user can login to their PayPal and approve transaction (we can't take it without verification) thereby it could allow us to handle PayPal payment confirmations.
Challenges we ran into
Our ideas pivoted a lot before we reached this point so that was the first major challenge: just deciding what we would do. Nearing the end, we couldn't find a good way to implement the payment system. PayPal seemed like the best option, but their API was difficult to learn (for us) and it would have taken way too long for us to write it in manually. Also, sponsor APIs like NCR's were simply incompatible because lacked digital payment infrastructure which is the important market with our target customer base so we couldn't do anything about that.
Accomplishments that we're proud of
At around 11:30 PM on Saturday, Tony managed to get our outside service's bot user to connect to a PayPal Sandbox application and configure our project's bot to trigger it, in this manner we essentially showed that our project can serve as a proof of concept.
What we learned
36 hours is not enough time to develop full-applications, especially with our approach to create a robust Enterprise Level Solution on a platform that has 250+ million users. Additionally we learnt how to iterate commands to call triggers in webhooks to chain trigger other functionality. We were also able to collaborate using GitHub and increase our output. Also learnt good programming style and syntax with concrete descriptive code.
What's next for PayCord
We plan on implementing a database that the bot can read and write from/to so that we can scale it more than just list (even though it is unneccesary). We would also like to research on the optimal commission percent/price ratios (basically like the Xcents + Y% model) so that it is actually a revenue-viable business model infrastructure. PayCord can be used for any purposes that involve Member - to - Vendor transactions on link and our system, even though it currently is targeted towards League of Legends account trades is scalable to any game with minor modifications for sorting purposes (ie. rank might just be level or there is no rank/level system etc.) and can be further scaled for any account marketplace activity on discord (doesn't even have to be accounts, could simply be keys if we pass defaults in the constructor). Basically someone could use our project [github repo] to create a Discord service where there users could buy/sell anything from E-Commerce Seller Accounts to Steam Keys.
Log in or sign up for Devpost to join the conversation.