King’s Failed Purchase Selector

Purchase failure is the third most common reason for a player to contact Player Support, meaning they either couldn’t fulfil a purchase or didn’t receive some or all the items.

Since it was the one most directly related to revenue, we decided to find a solution for it.

My role

I was the UX designer of the team, in charge of all the flows, designs and conversations about what information will be displayed to the players.

For this project the whole team worked really closely, as the solution proposal required a deep understanding of King’s systems and context around payments. I personally grew a lot from my collaboration with Backend devs and Player Support agents, providing me with the necessary information to articulate my design proposals.


We wanted to add value to our 2 main stakeholders:

  • Players, providing a space on the Help Center to claim a failed purchase.
  • Player Support agents, optimising their workflow by solving this type of issue faster. This would be done simply adding the transaction ID to these tickets in Zendesk so they can access the failed purchase right away instead of guessing on the right one based on the player’s words.

This solution was planned in 2 iterations, the last one not being developed.

Iteration 1

The player could access this flow clicking on the Contact us of any article within the Purchase section or the section itself.

Once there, they’ll have the option to claim:

  • Hard currency purchases ($): using real life currency to buy gold bars or bundles.
    Players have a list of the most recent purchases from the last 7 days to select the problematic one. The listed purchases were ordered with the most recent on top.There’s a fallback option in case the list of purchases fails to load or the user doesn’t have any, from which she would be taken to a form.
  • Soft currency purchases: using in-game money such as gold bars to buy boosters. The system does not display what boosters were bought on the transaction, therefore we would need the player to tell us about it so agents could check and compensate.

Iteration 2

The main differences were:

  1. Players can choose the type of compensation they want to receive:
    • Monetary refund
    • Compensation of the missing items
  2. If the player has not recent purchases or the list couldn’t be loaded, the form would let players choose the platform, in case they were claiming from a different device.
Flow of how to self manage a lost purchase request

Technical difficulties vs design

Sometimes ideal design solutions enter in conflict with the technical reality and possibilities.

Some games use different systems to deal with transactions. The team’s decision was to go for the one the biggest games were using so the solution could potentially impact to most players. Unfortunately, we couldn’t map exactly the content of certain packages so the granularity didn’t allow for a more detailed solution to the player.

And for iOS, all refunds must go through iTunes so, unfortunately, our only option iwas to direct the player to the purchase section of her iOS device.

Still, even if it wasn’t the ideal solution, it fullfilled the goal of helped more players and support agents.