Processing final payment

This is the first activity entailed in delivering a product and its accomplishment turns upon the collaborative effort of the clients and the contractors, as well as the participation of the intermediaries that facilitate the payment process. Upon its successful conduct, the agreed amount of money is transferred to the contractor, which occasions the finalisation of the delivery. The fieldwork revealed two particular methods of managing the payment: by using PayPal or by using the services of community-led organisations that act as an escrow system.

6.1.1.1 Managing payments via PayPal

PayPal became the main method for managing all the transactions in Minecraft’s commissioning market. The reason behind this was the need for both involved parties (contractors and clients) to have a safety net for scamming; PayPal offers the reassurance to all their customers that if a transaction does not meet the agreed expectations, then they can ask for their money back (a service that is named “charge-back”)53_{. Whilst instances of}

clients being scammed by contractors did not emerge during the fieldwork, all of the contractors and builders who participated in this project elaborated on the fact that they were scammed at least once during their career in this commissioning business. The predominant way of this happening was by the clients opening up a dispute in PayPal, where they accused the contractors of not delivering the builds they were commissioned to do. Due to this, a number of precautionary measures were put in place, with the down-payment (see section 4.2) being one of them. The exact ways in which contractors protected themselves against scamming are going to be discussed in subsequent sections (keeping proof of delivery and updating blacklist).

Max: “I did get scammed a few times and I have made some

money. So I do have some experience with it. It's a learning

153

thing. You're learning how to deal with clients.” [Interview material: The participant, who was a contractor, was explaining how common scamming is in this community by reflecting on his own experiences of getting scammed.]

Spence: “Pretty much everyone does their business through

PayPal. PayPal, they've got this system called charging back, which gives the like buyer 180 days I believe it is to charge back the PayPal saying... and they come up with a complain saying like ‘We didn't receive the project [...].’” [Interview material: Similarly to the quote above, the participant, who was a contractor and belonged to a different team, was elaborating on scamming, by also providing an account on one of the counter-measures that were appropriated by the community.]

The following vignette (Vignette 14) demonstrates what precedes the transaction between a client and a contractor. It constitutes the continuation of a case that was already covered in previous sections (see sections 4.2 and 5.5) and it takes place right after the client expressed his satisfaction over the final result of their commission.

Vignette 14 Exchanging payment details

Paul: “Do you wish to proceed with the transfer now?” Dan: “Yes”

Paul: “Alright. [I] will need to invoice your address again. Can I get

that PayPal email?”

Dan: [Censored]

Paul: “Sent, sorry about the wait.” Dan: “Paid.”

Paul: “Confirmed. Thanks for another successful business transaction.

:) Do you think we can request for a few minutes of your time to get a survey from you? If you are open to doing so here's the link: [censored]. This would help us know how we're doing and allow us to collect statements regarding our services. :)”

154

Paul: “Oh and you should paste that spawn to exactly y=152. Any higher

or lower it would cut off some parts of the build.”

Dan: “Tomorrow morning I compile the survey. And in the next few days

I will ask you new orders. :)”

Paul: “Sounds awesome thanks!”

What is of interest in this extract is the exchange of information that is necessary for paying the contractor. Initially, the contractor (Paul) asks the client (Dan) whether he “wish[es] to proceed with the transfer,” letting the latter decide when to do so. Upon replying positively, Paul clarifies that in order to send an invoice, he needs the client’s PayPal email (which is necessary for any type of transaction via PayPal). This particular exchange reveals that PayPal transactions are done in a formal way, with the contractors (the ones that provide the services the clients pay for) invoicing the clients about their work. On top of that, there is another resource at play here: the unique PayPal email of the client, which is essential for the accomplishment of the task at hand.

The actual exchange of the necessary details for managing the payment unfolds like so: (1) the client sends his email to the contractor; (2) the contractor sends the invoice to the email address he received; (3) the client pays according to the invoice he received; (4) the contractor finishes the exchange by providing an optional survey for the services provided. Interestingly, each of these turns is followed by the recipient accounting on their actions. For instance, Paul informs Dan that he sent the invoice, which occasions the latter’s action of paying (which Dan makes available to Paul by replying: “Paid”). Similarly, Paul acknowledges receiving the payment (“confirmed”), which puts the critical point of managing payment – transferring the money to the contractor – to an end.

Besides this exchange, there are a couple of other matters that emerge from this transaction, with the first of them being Paul’s enquiry as to whether Dan could fill in a survey that “would help us know how we’re doing and allow us to collect statements regarding our services.” This is a matter that is discussed later on, under evaluating the transaction. On top of that, Paul informs Dan that the spawn should be placed “exactly y=152.” This is a very crucial piece of

155

information, which aligns with Minecraft’s own limitations in terms of the world’s maximum height and how that could affect the placement of the build. As was mentioned in the terraforming section of crafting content (see chapter 5), each Minecraft map has a maximum height of 256. By placing a build in a position where some of its parts would be above this limit, the end result would be these parts being excluded from the pasting and as such the build will not look and play as expected. In this particular situation, the contractor makes it available to the client that the build was constructed in such a way as to function properly only when it is placed exactly at the height 152. Sharing this information is part of delivering the build, as it reassures that Dan will be happy with the product he receives and will face no problems integrating it in his server.

Lastly, the client makes it available to the contractor that he “will ask you new orders.” What is of interest in this statement is not only declaring his willingness to commission new builds, but rather the fact that he makes the time window for doing so explicit to the contractor (“in the next few days”). It has already been uncovered that this client is working on opening up a new server (see section 4.2.3.1), which explains the need to commission not only one but many new builds in a short period of time.

6.1.1.2 Managing payments via an escrow system

Whilst PayPal constitutes a solution that does provide a safety net to both contractors and clients, the predominant belief in the community is that its “policy tends to side with the buyer rather than the seller” (Nick). This means that when a client (the buyer) argues that the services they paid for were not delivered or were not up to the expected standards, PayPal will side with them unless the contractors (sellers) have “stone cool evidence and proof that [we]’ve sent and they agreed [with] it” (Spence). As is the case with most aspects of this market, a solution to this potential issue came from a particular sector in Minecraft’s community that only started to emerge during the course of doing this fieldwork; that of independent companies that were acting as an “escrow system54.” The role of these companies was to provide legally-binding contracts

156

to both parties, ensuring that both the clients’ and the contractors’ needs would be met with no risk involved in them. More precisely, they were the ones who were receiving both the payment (from the clients’ side) and the product (from the contractors’ side), and when they confirmed that both of them aligned with the established requirements (see section 4.2), they would transfer them to their corresponding recipients. It needs to be noted that they were using PayPal too as the means for managing the payment. However the transfers were only made when both parties delivered what they agreed upon. Furthermore, they addressed another issue that plagued the community; that of explaining to PayPal the nature of the business and trying to convince them that a scam took place. Given that these intermediaries hold legally binding contracts that apply to both parties, it is easier for them to convince PayPal of the legitimacy of the business of commissioning the creation of Minecraft maps and the need to get money back in case of scamming.

Nick: “Obviously, in terms of gaming and in terms of online

services in relation to Minecraft, it's a very hard to explain idea for a moderator on PayPal to understand. We are a registered company and we also have legally binding contracts that the buyer has to agree to, otherwise they can't do anything. And that way we can simply give PayPal that legal agreement, which is something that they understand more than just the actual Minecraft services as it were.” [Interview material: The participant, who ran an escrow system service, was explaining the reasons behind his business.]