{% extends "konami.html" %} {% block title %}cardmng{% endblock %} {% block body %}

# `cardmng`

As the name might imply, this service is responsible for handling interactions with physical e-Amusement cards. e-Amusement currently has two different types of cards in circulation. There are classic e-Amusement cards making use of a magnetic stripe, and the newer RFID cards using FeliCa (these are probably what you have). They are identified in requests using the `cardtype` attribute as in the below table.

e-Amusement cards have a "card number" and a "card id". Confusingly, neither is a number. The card number is the one printed on your card. The card ID is your KONAMI ID. You can (and should) read about the algorithm used for these IDs on the Card IDs page.

In the interest of not wasting space, `cardid` and `cardtype` will be omitted from individual breakdowns where their meaning is obvious.

#### Card types:

`cardtype` | Meaning
`1` | Old style grey cards
`2` | FeliCa RFID card
`3` | Unknown
`4` | Virtual card

- `cardmng.inquire`
- `cardmng.getrefid`
- `cardmng.bindmodel`
- `cardmng.bindcard`
- `cardmng.authpass`
- `cardmng.getkeepspan`
- `cardmng.getkeepremain`
- `cardmng.getdatalist`

#### dataid? refid?

Some requests use `refid`, some use `dataid`, and some use both. What exactly you use these values for is largely left up to the server implementer, as the game will echo them back verbatim, however here are three suggestions:

`refid` | An ID that references the user
`data` | An ID that references the game specific data for this user/game combination

`refid` | A session token issued during card auth
`data` | An ID that references the game specific data for this user/game combination

`refid` | An ID that references the user
`data` | The same as refid; we can use database joins for accessing game data

## `cardmng.inquire`

Request information about a card that has been inserted or touched against a reader.

### Request:

    {% highlight "cxml" %}<call ...>

    </call>{% endhighlight %}

`update` | Should the tracked last play time be updated by this inquiry? (Just a guess)

### Response:

    {% highlight "cxml" %}<response>

    </response>{% endhighlight %}

To handle this request, we first must lookup if this `cardid` has ever been seen by our servers before. If not, we abort with a `112` status. Otherwise, we proceeed to check if this card has been seen for this specific game. If we have never seen this card used on this game, it is possible this card was used with an older version of this game, and migration is supported, in which case we report as if we had found a profile for this game.

`refid` | See section about refid and dataid
`dataid` | See section about refid and dataid
`newflag` | Inverse of `binded`
`binded` | Has a profile ever been created for this game (or an older version, requiring a migration) (`1` or `0`)
`expired` | ? Just set it to `0`.
`newflag` | ? Just set it to `0`.

## `cardmng.getrefid`

Register a new card to this server. In the process, we're also going to create a game profile.

### Request:

    {% highlight "cxml" %}<call ...>

    </call>{% endhighlight %}

`newflag` | ?
`passwd` | The pin for this new user. Should always be a four digit number (and that's worth validating), but it's passed as a string so could feasibly be anything desired.

### Response:

    {% highlight "cxml" %}<response>

    </response>{% endhighlight %}

`refid` | See section about refid and dataid
`dataid` | See section about refid and dataid
`pcode` | ? Just omit this

## `cardmng.bindmodel`

Create a data profile for this card on the current game. Request and response should be fairly self-explanatory.

### Request:

    {% highlight "cxml" %}<call ...>

    </call>{% endhighlight %}

### Response:

    {% highlight "cxml" %}<response>

    </response>{% endhighlight %}

## `cardmng.bindcard`

### Request:

    {% highlight "cxml" %}<call ...>

    </call>{% endhighlight %}

### Response:

    {% highlight "cxml" %}<response>

    </response>{% endhighlight %}

## `cardmng.authpass`

Test a pin for a card. This request notably uses the `refid`, so required a `cardmng.inquire` call to be made first.

### Request:

    {% highlight "cxml" %}<call ...>

    </call>{% endhighlight %}

`refid` | The reference we received either during `cardmng.inquire` or `cardmng.getrefid` (the latter for new cards)
`pass` | The pin to test. See `cardmng.getrefid`.

### Response:

    {% highlight "cxml" %}<response>

    </response>{% endhighlight %}

If the pin is valid, status should be `0`. Otherwise, `116`.

## `cardmng.getkeepspan`

### Request:

    {% highlight "cxml" %}<call ...>

    </call>{% endhighlight %}

### Response:

    {% highlight "cxml" %}<response>

    </response>{% endhighlight %}

## `cardmng.getkeepremain`

### Request:

    {% highlight "cxml" %}<call ...>

    </call>{% endhighlight %}

### Response:

    {% highlight "cxml" %}<response>

    </response>{% endhighlight %}

## `cardmng.getdatalist`

### Request:

    {% highlight "cxml" %}<call ...>

    </call>{% endhighlight %}

### Response:

    {% highlight "cxml" %}<response>

            <item[]>

            </item[]>

    </response>{% endhighlight %}

{% endblock %}